On Wed, May 4, 2016 at 2:26 PM, johannes hanika <hana...@gmail.com> wrote:
> hi, > > i would agree that this looks like a bug in the markesteijn algorithm. > another thing to try is probably the green equilibration thing that > some bayer sensors suffered from. that there was some spill from blue > -> one green and red-> the other green (same line of the sensor, maybe > during readout?). > > the rawtherapee guys found that the horizontal lines i got in some > images already have this line artifact in the original, undebayered > green channels of the xtrans layout. i couldn't find them in > flat-field images (for vignetting correction). so maybe it is another > instance of colour spill during readout and would require a special > kind of green-eq.. > > -jo > Do you think you could explain the bayer green equilibration to me or point me to a resource on it? Based on my current understanding it doesn't seem like this problem would apply to X-Trans, since each row contains a mix of R G and B. Or do you think it's something like the green pixels directly to the left of blue pixels have a different response from those directly to the left of red pixels? Looking at the Markesteijn algorithm, it seems that the greens (and reds and blues) are getting spread around enough already to wash out any such effect. And also, again, this artifact is appearing only every 12th row (which should be the same as every 6th row in so far as any CFA related artifacts go...) > > On Thu, May 5, 2016 at 8:36 AM, J. Liles <malnour...@gmail.com> wrote: > > Group, > > > > I've been trying to figure out the source of these horizontal line > artifacts > > in x-trans demosaicing, but without much luck. > > > > The artifact also appears with VNG, but Markesteijn seems to amplify it > in > > two ways: 1) by reducing the number of other artifacts but not this one > and > > 2) by increasing the horizontal extent of the artifacts by one or two > > pixels. > > > > I know the party line is just that "x-trans demosaicing will always > produce > > artifacts", but I don't think that's what's going on here. > > > > X-Trans has a periodicity of 6x6. This artifact occurs at a period of 12 > > pixels, and seems to only repeat vertically. > > > > Aside from this issue, the Markesteijn algorithm does quite well. > > > > I've been poring over the code looking for something that could > introduce an > > error at this period and have so far come up empty handed. > > > > Because VNG also exhibits this error, I think maybe the issue could lie > in > > the common rawspeed code or some other shared part of the pipeline (in > DT, > > dcraw and rawtherapee). Although most of that code seems to concentrate > on > > the 6x6 matrix, so it's hard to imagine how it could introduce this > error. > > > > I think better end results could probably be achieved by simply ignoring > > those two green pixels in every 12th row and just fully interpolating > them, > > but that's probably not the right thing to do. > > > > I do wonder if images from the 1st generation X-Trans sensors also > exhibit > > this artifact... Perhaps someone with one of these cameras could > photograph > > a bird or a puppy with it in the interest of science? > > > > I have been unable to find any information on whether the PDAF pixel > > information from X-Trans II is included in the raw data or if the camera > > interpolates it out, or even where these pixels are located on the sensor > > (e.g. perhaps in rows separated by 12 pixels and always in the lower two > > pixels of the 2x2 green blocks which is where the artifact appears...) > > > > Frankly, considering that Fuji doesn't even bother to adjust the > exposure of > > the high ISO RAW data themselves, it seems plausible that they just pass > the > > PDAF pixel data through untouched. > > > > Also, I don't know if this is a known issue or not, but playing with the > raw > > black/white levels produces some very weird looking results with X-Trans > > files. > > > > Another thing of note: There is a tag in the exif data: > > > > Fuji Layout : 12 12 12 12 > > > > I have no idea what it may mean, but it does mention the number 12... > > > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________________________ > > darktable developer mailing list to unsubscribe send a mail to > > darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
