On Wed, May 4, 2016 at 4:50 PM, J. Liles <malnour...@gmail.com> wrote:
> > > 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. > After having spent some more time on this, I've been able to make a small improvement to the Markesteijn interpolation which, although not curing the alternating horizontal lines of dots, does prevent the dots from being extended horizontally into dashes (and reduces overall horizontal smearing). The improvement is extremely subtle, and unlikely to be noticed on any images outside of my torture test. Interestingly, this small change brings the DT result closer to the in camera processing as far as the shape of specular highlights and color artifacts. I'm still struggling to understand the algorithm though. Does anyone know what the rgb[0..3] layers are for exactly? I've noted that the interpolation of red and blue values for the 2x2 green blocks only occurs in rgb[0] and rgb[1]. rgb[2] and rgb[3] are missing this step, but appear to have fully interpolated values for the other pixels in the matrix. This is masked out in the output by the homogeneity map step at the end (but then again, perhaps not in some cases and this could be the source of some of the green artifacts around fine lines), but I can't tell if this is intentional or an oversight. It seems to me that the 2x2 green blocks are not benefiting from the homogeneity mapping as much as the other pixels in the matrix for this reason, but my attempts to fix this resulted in some new artifacts. > > >> >> >>> >>> 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
