Bug #11872

local contrast (local laplacian) display bug when changing image

Added by Matthieu Moy about 2 years ago. Updated about 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git master branch
hardware architecture:


In darkroom, with the local contrast tool (new default mode: local laplacian), when switching from an image to another, I get a strange display bug: it seems darktable computes a mask for an image, and re-uses the mask when displaying the next image.

See example attached. Screenshots done with two images (image 1 and image 2), switching back and forth between the images.

The display bug disappears as soon as I move or zoom the image (i.e. when a new computation is triggered).

Thanks in advance,

image-1-ok.jpg (99.7 KB) image-1-ok.jpg first image displayed, everything works as expected. Matthieu Moy, 12/21/2017 07:52 PM
image-2-ko.jpg (91.7 KB) image-2-ko.jpg After switching to another image, without moving the image: we still get the shadow at the position of the former image. Matthieu Moy, 12/21/2017 07:52 PM
image-1-ko.jpg (101 KB) image-1-ko.jpg Switching back to the original image: now, we get the shadow of the second image. Matthieu Moy, 12/21/2017 07:52 PM

Associated revisions

Revision bfe9911a (diff)
Added by Matthieu Moy about 1 year ago

bilat: don't grab data from preview pipe if hash==0, fixes #11872

When changing image in darkroom, and when both the previous and the new
image have local laplacian activated, the optimization grabing data from
the preview pixelpipe introduced in 911133c (local laplacian: make roi
aware in darkroom mode, 2017-10-15) was actually grabing data from the
previously selected image.

The guilty line was:

if(hash != 0 && !dt_dev_sync_...)

in case hash == 0, the sync is not done, but the else branch still
does the grabbing. Change this to exhibit 3 cases: 1) don't try to
sync and grab, 2) sync failure, 3) sync success.


#1 Updated by Matthieu Moy over 1 year ago

Note: this happens only when OpenCL is disabled.

(An expensive workaround is therefore to buy a good GPU and activate OpenCL ;-) )

#2 Updated by Matthieu Moy over 1 year ago

I found the guilty code:

Introduced by:

If I replace the if (... < 0.9) by if (... < 0.0) (always false), then the issue disappears. What happens is that the full pipeline steals data from the preview pipeline, and apparently it steals it from the previously computed image.

According to gdb, the visual bug happens when hash is 0, i.e. when the if (hash != 0 && dt_dev_sync...) condition is false because of the left hand side of the &&. Then, the pipeline sync is not done, but the stealing from the preview pipeline still happens (else branch).

I don't fully understand the logic here, but I'll try a naive fix (at least it should be simpler for a core dev to finish debugging/fixing with this initial attempt).

#3 Updated by Anonymous about 1 year ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

#4 Updated by Roman Lebedev about 1 year ago

  • Target version set to 2.6.0

Also available in: Atom PDF

Go to top