On Wed, May 4, 2016 at 4:34 PM, J. Liles <malnour...@gmail.com> wrote:
> > > 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...) > > Also, I'm at a loss for how to tell if the lines appear in the undemosaiced data. The x-trans pattern is too strong to see through and no amount of staring at it has proven useful. I do notice that it seems like most of the time the luminance of the two bottom green pixels in the 2x2 blocks is swapping positions in the demosaiced version. That is, if the left pixel is brighter in the raw data, then the right one will be brighter in the demosaiced data. This goes along with what happens when switching the demosaicing mode from VNG to Markestein: Where VNG shows a single pixel spec on these problematic 12th rows, Markesteijn will show a two pixel dash, extended to the right. > > >> >> 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
