Project

General

Profile

Bug #11509

Exported image is completely black when no clipping is applied

Added by Alexander Blinne about 1 month ago. Updated about 1 month ago.

Status:
Fixed
Priority:
Low
Category:
Darkroom
Target version:
-
Start date:
02/15/2017
Due date:
% Done:

100%

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

Description

I have a number of raw images from my Panasonic DMC-FZ1000 with ISO 800. Some of them (~ 10%) are exported completely black. An earlier bug report (that is supposed to be fixed) #10738 suggests a connection to the clipping module. I managed to get a good export after applying some clipping. A raw image and some xmp files are attached to this report.

I was using the current git master version (5fc55124f98b027b293ea4370b9280bc6aa1a214) compiled using the PKGBUILD from the Arch User Repository (AUR, https://aur.archlinux.org/packages/darktable-git/)

Other bugs that may or may not be connected to this:

#11101
#10619

20170208_192219_P1250124.RW2_black.xmp - XMP file resulting in black image (clipping disabled) (7.24 KB) Alexander Blinne, 02/15/2017 03:49 PM

20170208_192219_P1250124.RW2_black2.xmp - XMP file resulting in black image (clipping enabled, but without actual clipping)) (7.24 KB) Alexander Blinne, 02/15/2017 03:49 PM

20170208_192219_P1250124.RW2_ok.xmp - XMP file resulting in good image (clipping enabled, clipping some pixels on all sides) (7.71 KB) Alexander Blinne, 02/15/2017 03:49 PM

20170208_192219_P1250124.RW2 - Raw image source (22.5 MB) Alexander Blinne, 02/15/2017 03:49 PM

darktable-cli-debug.txt Magnifier - debug output from exporting with 20170208_192219_P1250124.RW2_black.xmp (195 KB) Alexander Blinne, 02/15/2017 03:49 PM

debug-perf-dev.log Magnifier - Debug log of 20170208_192219_P1250124.RW2_black.xmp with -d perf and -d dev (3.46 KB) Alexander Blinne, 02/15/2017 06:48 PM

debug-perf-dev-opencl.log Magnifier - Debug log of 20170208_192219_P1250124.RW2_black.xmp with -d perf -d dev and -d opencl (28.2 KB) Alexander Blinne, 02/15/2017 06:48 PM

debug-perf-dev-increased-tiling-limit.log Magnifier (2.41 KB) Alexander Blinne, 02/15/2017 07:22 PM

P1250124.RW2_black_no_equalizer.xmp (7.24 KB) Alexander Blinne, 02/16/2017 09:37 AM

P1250124.RW2_black_no_equalizer.xmp.log Magnifier (2.47 KB) Alexander Blinne, 02/16/2017 09:37 AM

P1250124.RW2_black_no_denoise.xmp (7.6 KB) Alexander Blinne, 02/16/2017 09:44 AM

P1250124.RW2_black_no_denoise.xmp.log Magnifier (2.84 KB) Alexander Blinne, 02/16/2017 09:44 AM

P1250124.RW2_black_no_both.xmp (7.24 KB) Alexander Blinne, 02/16/2017 09:44 AM

P1250124.RW2_black_no_both.xmp.log Magnifier (1.85 KB) Alexander Blinne, 02/16/2017 09:44 AM

Associated revisions

Revision 012392ea
Added by Roman Lebedev about 1 month ago

dt_configure_defaults(): host_memory_limit: if 8Gb+, half the total size

Refs #11509

Revision 7a6529f9
Added by Ulrich Pegelow about 1 month ago

tiling: do not process uselessly small end tiles; fix for bug #11509

End tiles with a dimension smaller than the overlap area are not processed. Previously
we would set the limit to 1 times the overlap size. However, in fact the limit
should be 2*overlap. Some modules like profiled denoise produce garbage (NANs) if
called on a tile below that limit.

Revision da84da8d
Added by Ulrich Pegelow about 1 month ago

tiling: do not process uselessly small end tiles; fix for bug #11509

End tiles with a dimension smaller than the overlap area are not processed. Previously
we would set the limit to 1 times the overlap size. However, in fact the limit
should be 2*overlap. Some modules like profiled denoise produce garbage (NANs) if
called on a tile below that limit.

(cherry picked from commit 7a6529f9f7fa1fef0633b4d83c573675912c2df6)

History

#1 Updated by Alexander Blinne about 1 month ago

Additionally I have tested this against the packaged version 2.2.3 from the Arch linux community repository and it produces the same results.

#2 Updated by Tobias Ellinghaus about 1 month ago

Are you using OpenCL?

#3 Updated by Alexander Blinne about 1 month ago

No. I have a Quadro NVS 310 and after I installed the OpenCL libs, darktable automatically disabled OpenCL because the GPU is too slow (gui message when starting darktable for the first time after installing the opencl libs). This is reflected also in the attached debug log (2nd to last line: [opencl_summary_statistics] device 'NVS 310': NOT utilized).

#4 Updated by Roman Lebedev about 1 month ago

Can not reproduce here
the log file shows that there is big amount of tiling going on

please try running with -d perf -d opencl -d dev
export that image which results in completely black export, and show the log

BTW: -d all is never useful.

#5 Updated by Alexander Blinne about 1 month ago

Sorry for the -d all, I have seen it in another report.

OpenCL is disabled here, so I provide the log once with and once without -d opencl. CPU is a Xeon E5-1620 v4 @ 3.50GHz.

#6 Updated by Roman Lebedev about 1 month ago

How much memory does your system has?
Is there any messages in gui when you export?
Also, which system is that?

#7 Updated by Alexander Blinne about 1 month ago

The System has 16 GB of RAM, it is a Dell Precision 5810 running a freshly installed Arch Linux. package darktable-git installed from the AUR.

Unfortunately there are no GUI messages on export other then "Exporting 1 Image...". Darktable uses all cores (incl. Hyperthreading) and takes about 12 seconds for both _black.xmp and _ok.xmp.

#8 Updated by Roman Lebedev about 1 month ago

Alexander Blinne wrote:

The System has 16 GB of RAM

Well, then it is strange.
Try increasing "host memory limit (in MB) for tiling"
https://www.darktable.org/usermanual/ch08s02.html.php

#9 Updated by Alexander Blinne about 1 month ago

I doubled the "host memory limit (in MB) for tiling" to 3000 and now the image exports fine using all of the above *.xmp files... Seems there may be a bug sumewhere in the tiling code? Anyhow, thanks a lot for helping!

#10 Updated by Roman Lebedev about 1 month ago

  • Assignee set to Ulrich Pegelow

@Ulrich: perhaps the defaults should be adjusted?
It's 2017 now, default of 1500 for host_memory_limit is a little bit ridiculous.
If there is more than 8Gb, the default should be half of the total memory size i'd say.

Or just close it.

#11 Updated by Ulrich Pegelow about 1 month ago

The tiling code should happily run with whatever small settings we have in host memory limit (more precisely anything above 500 should be fine). If it doesn't work we have an issue somewhere which must be resolved.

@The TO: there are two modules which involve tiling in case of the example image: profiled denoise and equalizer. Could you please try disabling one or the other and both to see if this leads to correct results? All with host_memory_limit 1500, of course.

#12 Updated by Alexander Blinne about 1 month ago

After reverting to "host memory limit (in MB) for tiling" = 1500:

  • Disabled equalizer: export completely black
  • Disabled profiled denoise: export ok
  • Disabled both: export ok

#13 Updated by Ulrich Pegelow about 1 month ago

Thanks, I can confirm here. The problem starts in the profiled denoise module which produces NANs.

The issue is tricky as it depends on details of the tile size, which in turn depends on the overall image dimensions and the tiling requirements. Already a change in clipping or (in this case) enabling or disabling lens correction makes or breaks the image.

In more detail:

  • with the given settings (host_memory_limit=1500) tiling wants to process the image like this:
    [default_process_tiling_ptp] use tiling on module 'denoiseprofile' for image with full size 5474 x 3662
    [default_process_tiling_ptp] (4 x 1) tiles with max dimensions 1870 x 3662 and overlap 32
    [default_process_tiling_ptp] tile (0, 0) with 1870 x 3662 at origin [0, 0]
    [default_process_tiling_ptp] tile (1, 0) with 1870 x 3662 at origin [1806, 0]
    [default_process_tiling_ptp] tile (2, 0) with 1862 x 3662 at origin [3612, 0]
    [default_process_tiling_ptp] tile (3, 0) with 56 x 3662 at origin [5418, 0]
    [dev_pixelpipe] module `Entrauschen (Profil)' outputs NaNs! [export]
    

    Four tiles in total with three wider ones and one final small tile.
  • at closer inspection one finds that the first three tiles are processed correctly, but the last narrow one with 56pixel width produces all NANs (all pixels all three channels).
  • in the wavelet code of denoise profiled all tiles are processed to the same 'scale' depth, which is 4 in this case. All is OK for the first three tiles but the last one shows the following number of NANs in the scale buffer:
    scale 0: hasnan 0, hasinf 0
    scale 1: hasnan 0, hasinf 0
    scale 2: hasnan 0, hasinf 0
    scale 3: hasnan 0, hasinf 0
    scale 4: hasnan 306, hasinf 0
    

Speculation: the maximum scale depth is calculated on the basis of the full input buffer, taking piece->buf_in.height and piece->buf_in.width into account. That's the same for all tiles as we do not tamper with piece in tiling code. Could it be that we cannot process to that deep level if the image dimensions are so small as in the last tile?

Putting hanatos in copy as he has most knowledge about the wavelet denoise.

#14 Updated by Ulrich Pegelow about 1 month ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

#15 Updated by Ulrich Pegelow about 1 month ago

  • Status changed from Confirmed to Fixed
  • % Done changed from 10 to 100

Also available in: Atom PDF