I've been debugging various codepaths but nothing definitive -- it happens every few parameter changes, with no apparent pattern to occurrences. I don't have a deep understanding of the pixelpipe. Could it be the piece->pipe->xtrans for some mosaic-dependent iop after rawprepare gets initialized to the non-shifted CFA and never catches the shift done in rawprepare? Could there be a race condition with pipe/iop initializations which could cause this?
This definitely is in a083e4c and successive commits including 5590478. Roman Lebedev <lebedev...@gmail.com> writes: > On Wed, May 18, 2016 at 6:20 PM, Dan Torop <d...@pnym.net> wrote: >> From here a bisect suggests >> https://github.com/darktable-org/darktable/commit/a083e4c0f9ffc0423613f3a75e5e3457aa11430c >> as the troublemaking commit. > Not surprising. Thanks for bisecting it though. > (but does it still happen with the next commit > https://github.com/darktable-org/darktable/commit/5590478c7bede4061ab06b013d8d227135d08005 > i guess it does) > >> Fiddling with color balance seems a good way to cause this. I've also seen >> it when fiddling with white balance. > >>The preview in the navigation panel shows correct color, while the full image >>view shows the weird colors. > Yep, because preview is demosaiced way before any pipe runs on it. > >> I can see this when the view is "fit to screen" or 100%. > >>In the later case, the image looks suspiciously like a CFA problem.See >>https://i.imgur.com/NG4G1y6.jpg. > It definitely is. > Either i forgot to change something to use piece->pipe->xtrans > instead of xtrans field in dt_image_t, > or missed some codepath that leads to it being set to wrong values. > >> >> This is with OpenCL disabled and an X-Trans image. Will keep looking into >> this. > No opencl here, and so far i have not seen this on bayer images. > >> Dan > Roman. > >> Ulrich Pegelow <ulrich.pege...@tongareva.de> writes: >> >>> Am 17.05.2016 um 20:21 schrieb Roman Lebedev: >>>> On Tue, May 17, 2016 at 9:13 PM, Ulrich Pegelow >>>> <ulrich.pege...@tongareva.de> wrote: >>>>> Hi, >>>>> >>>>> I can confirm your issue. You are running with OpenCL enabled? It looks >>>>> like >>>> >>>>> I have introduced an issue when porting xtrans demosaicing to OpenCL. >>>> >>>> Are you really sure? >>> >>> No, not sure. You are probably right, the issue has been introduced >>> lately. If I go back in time a few days (commit >>> 1b955380447ac717674ce05f3e9c6e6f0a3b8cc6) all seems good. >>> >>> Unfortunately I cannot bisect as my gcc 4.8.3 has issues compiling >>> in-between commits. >>> >>> Maybe you can try to do that. At least here the problem can be quickly >>> reproduced when quickly wheel-scrolling a few times over the exposure >>> slider in the exposure module. >>> >>> Best wishes >>> >>> Ulrich >>> >>> >>>> I'm somewhat expecting this to be due to >>>> https://github.com/darktable-org/darktable/commit/a083e4c0f9ffc0423613f3a75e5e3457aa11430c >>>> and >>>> https://github.com/darktable-org/darktable/commit/5590478c7bede4061ab06b013d8d227135d08005 >>>> >>>> but i do not understand what is missing... >>>> >>>> FWIW i was able to reproduce the issue without opencl, and only rarely, >>>> when loading image in darkroom and just only changing colorzones once. >>>> >>>>> What I >>>>> see are spurious color distortions (typically towards magenta) when >>>>> quickly >>>>> changing some slider value like the exposure compensation. At the moment I >>>>> cannot really say why we have these intermittent errors. This needs some >>>>> in >>>>> depth investigations. >>>>> >>>>> Ulrich >>>> Roman. >>> >>> ___________________________________________________________________________ >>> 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
