Bug #11872

local contrast (local laplacian) display bug when changing image

Added by Matthieu Moy over 1 year ago. Updated 8 months ago.

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


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 - first image displayed, everything works as expected. (99.7 KB) Matthieu Moy, 12/21/2017 07:52 PM

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. (91.7 KB) Matthieu Moy, 12/21/2017 07:52 PM

image-1-ko.jpg - Switching back to the original image: now, we get the shadow of the second image. (101 KB) Matthieu Moy, 12/21/2017 07:52 PM

Associated revisions

Revision bfe9911a
Added by Matthieu Moy 9 months 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 12 months 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 12 months 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 9 months ago

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

#4 Updated by Roman Lebedev 8 months ago

  • Target version set to 2.6.0

Also available in: Atom PDF