Version: 2.0.0 (using KDE 4.7.0) OS: Linux If one issues dcaw on a RW2 picture with the "-w" option it shows the values for white balance the camera set. If digikam is set to "camera" for the "white balance method" it should use those exact values. However digikam's output shows that it uses different values. dcraw: Scaling with darkness 15, saturation 4095, and multipliers 1.901141 1.000000 1.745247 1.000000 digikam: Scaling with darkness 0, saturation 4080, and multipliers 1,000000 0,526000 0,918000 0,526000 dcraw_emu from libkdcraw: Scaling with darkness 0, saturation 4080, and multipliers 1.901141 1.000000 1.745247 1.000000 As you can see digikam as well as dcraw_emu use the wrong values for darkness and saturation. dcraw_emu uses the correct values for the multipliers while digikam does not use those absolute values, i.e. strictly speaking does not use the camera's white balance but only its ratio. Since this does make a difference it should only be used if the user enabled it! In case the absolute white balance values blow a channel it might make sense to have a darker image but no blown channels – but only as option, e.g. "use value ratio". Reproducible: Didn't try Steps to Reproduce: Isse dcaw -w, digikam and dcraw_emu on a RAW picture (RW2 in this case) and compare the values. Actual Results: different values Expected Results: same values.
digiKam version 2.1.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.20 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.7.00 (4.7.0) LibKExiv2: 2.0.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.0.0 LibLCMS: 119 LibPGF: 6.11.24 - internal library LibPNG: 1.2.44 LibQt: 4.7.3 LibRaw: 0.13.7 LibTIFF: LIBTIFF, Version 3.9.4 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.11.95 (0.12 RC 2) Parallelized demosaicing: Yes Database backend: QSQLITE LibGphoto2: 2.4.10 LibKface: 2.0.0 LibKipi: 1.2.0 LibOpenCV: 2.2.0 Libface: 0.2
The difference is because dark value has been (shoul be :) subtracted at the earlier stages. Also, white balance settings should not affect the black/max values. Anyway, if you see real problems with your images (the 15-unit difference should affect shadows and dark tones), please provide your RW2 sample for download (use Mediafire or Dropbox or other file sharing service if needed).
I can send you the RW2 I used for the screenshot by email. The PPM on the left was done as mentioned above, i.e. only dcraw -w, not sure if it does anything else by default digikam does not. The PGF on the right was created via digikam, no post-processing, no highlight rebuilding (set to solid white), just demosaicing and exporting as lossless PGF. Applying rebuilding for highlights makes it even darker. As you can see the pictures do differ quite a bit.
My email is lexa@lexa.ru Generally, dcraw -w and dcraw_emu -c 0 -w should provide the same results bitwise. The -c 0 is to turn off auto-maximum feature missing in dcraw.
Created attachment 62603 [details] comparison digikam with libraw against dcraw
Created attachment 62604 [details] comparison dcraw against darktable On the left dcraw with only -w and on the right darktable with white balance set to camera, no colour management or base curve applied.
Created attachment 62607 [details] comparison dcraw against libdcraw_emu On the left dcraw -w -v on the right dcraw_emu -w -c 0 -v
With (latest) stable LibRaw 0.13.7, the dcraw -w and dcraw_emu -c 0 -w produces bitwise same result from sample image you sent to me. Checked with md5sum against .ppm files produced.
I'm at this issue again with today's git checkout. digiKam version 2.8.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.22 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.8.4 (4.8.4) "release 513" LibKExiv2: 2.1.1 LibKGeoMap: 2.0.0 LibKdcraw: 2.0.1 LibLCMS: 119 LibLensFun: 0.2.6-0 - internal library LibLqr: internal library LibPGF: 6.12.27 - internal library LibPNG: 1.2.49 LibQt: 4.8.2 LibRaw: 0.14.4 LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.13.3 (stable release) Parallelized PGF codec: No Parallelized demosaicing: Yes Database backend: QSQLITE LibGphoto2: 2.4.11 LibKface: 2.0.0 LibKipi: 1.4.0 LibOpenCV: 2.3.1 Libface: 0.2 digikam uses: Scaling with darkness 0, saturation 4095, and multipliers 1,897338 1,000000 1,726236 1,000000 dcraw uses: Scaling with darkness 15, saturation 4095, and multipliers 1.897338 1.000000 1.726236 1.000000 As you can see in the earlier posts digikam used to subtract the darkness from the saturation, i.e. 4095 in dcraw became 4080 and the darkness was set to 0. However, now it still sets the darkness to 0 but does not subtract it from the saturation. Further: Digikam (the RAW tool within the editor) is set to use amaze to decode yet digikam's output shows: AHD interpolation...
Created attachment 72711 [details] Comparison: jpg, digikam, dcraw -w The picture shows a comparison of the same picture: from left to right: 1. JPG 2. RAW from digikam, WB set to camera, no post-processing 3. RAW from dcraw -w (use camera's WB) 2 and 3 should look the same – yet they do not.
I compiled the current git libkdcraw to use dcraw_emu and it shows: Scaling with darkness 0, saturation 4080, and multipliers 1.897338 1.000000 1.726236 1.000000
Created attachment 72718 [details] comparison: dcraw, digikam, dcraw_emu a comparison of the same image: from left to right: 1. dcraw -w 2. digikam with "use camera's WB" 3. dcraw_emu -w -c 0 As you can see 1 and 2 look the same while digikam fails to use the correct settings.
Installed libkdcraw from current git, i.e. the one that I used for the dcraw_emu test (which works as expected), but digikam does still use darkness 0 and saturation 4095.
I get it that for correct camera white balance, with dcraw_emu, "-w" is not enough, but "-c 0" is also required. Alex: In the libraw_output_params_t struct, we set use_camera_wb which is equivalent to the "-w" option. What is to be set to achieve "-c 0"?
-c in dcraw_emu sets params.adjust_maximum_thr value. 0 - disables automated maximum adjustment.
From Libraw docs: float adjust_maximum_thr; This parameters controls auto-adjusting of maximum value based on channel_maximum[] data, calculated from real frame data. If calculated maximum is greater than adjust_maximum_thr*maximum, than maximum is set to calculated_maximum. Default: 0.75. If you set this value above 0.99999, than default value will be used. If you set this value below 0.00001, than no maximum adjustment will be performed. Adjusting maximum should not damage any picture (esp. if you use default value) and is very useful for correcting channel overflow problems (magenta clouds on landscape shots, green-blue highlights for indoor shots).
Sven: In the UI, the relevant option is called "Correct false colors in highlights". Please check that unchecking this option, and using camera wb gives the desired results. For me, these two options seem to be independent and their relation in this bug report is coincidental, so assuming you get the bit-identical results, we can close.
BTW, auto-maximum does not affects 'darknes'. This option auto-corrects 'maximum' only.
Created attachment 74120 [details] dcraw settings
Created attachment 74121 [details] raw settings 2
According to comment 4 using "-w" for dcraw and "-w -c 0" should give the same values. This is not the case with Correct false colors in highlights disabled. (see screenshots) According to comment 2 if a darkness of 15 is set to 0 the value has to be subtracted form the saturation. Digikam does not do so. Hence to close this report digikam/"libs it uses" has to decide whether it wants to use a darkness of 0 if it is actually 15 or not. If it wants to use 0 it should subtract 15 from the saturation, as it did previously.
The first sentence of my previous comment refers to digikam vs. dcraw. not dcraw emu.
I think I understood now what you meant. This report is about white balance and using wrong darkness and saturation values has nothing to do with white balance but needs a new report. The report that deals with subtracting darkness from saturation is bug 307313.
Sven, This file still valid ? Gilles Caulier
Sven, We need a fresh feedback here, using last digiKam 4.2.0, and Libraw 0.16. Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier
digiKam 4.12.0 is out : https://www.digikam.org/node/741 We need a fresh feedback using this release please... Thanks in advance.
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier