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 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
