Project

General

Profile

Bug #11872

local contrast (local laplacian) display bug when changing image

Added by Matthieu Moy 11 months ago. Updated 14 days ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
-
Start date:
12/21/2017
Due date:
% Done:

100%

Affected Version:
git master branch
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

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 14 days 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.

History

#1 Updated by Matthieu Moy 3 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 3 months ago

I found the guilty code:

https://github.com/darktable-org/darktable/blob/1ddd9bde8aa65ef321b7e7882b5e345b8d2cb694/src/iop/bilat.c#L296-L315

Introduced by: https://github.com/darktable-org/darktable/commit/911133c87b45be22251cf7252ed729d1632a27b2

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 14 days ago

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

Also available in: Atom PDF