Bug 142055 - Which whitebalance is used
Summary: Which whitebalance is used
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-RAW (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-22 14:42 UTC by p
Modified: 2016-07-09 11:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description p 2007-02-22 14:42:45 UTC
Version:           0.9.0 (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs
OS:                Linux

Somehow I don't trust the whitebalance dialog in digikam. First of all it displays a value different from other program - I shoot in raw using a Canon 300D. If I change the value to the value other programs show (e.g. bibble) the picture is too warm. Secondly what confuses me is that you can change the white balance of a jpeg  picture and not only raw.

What is behind your white balance function?

Somehow I have the feeling that you transform the raw picture to a jpeg and then do some changes to the jpeg. Changes like white balance, saturation, etc. Here you calculate the change but they are not as good as if you would do it to the raw picture. What do you do actually?
Comment 1 caulier.gilles 2007-02-22 14:53:20 UTC
>Somehow I have the feeling that you transform the raw picture to a jpeg and >then do some changes to the jpeg

Certainly not. All pixels value are store in memory in 16 bits. the algorithm process WB change with this color depth. 

The difference are duing to different algorithm used by other programs. In digiKam this algorithm come from the old RawPhoto gimp plugin (initialy only 8 bits support)

http://wolf.ifj.edu.pl/~jochym/soft.php

Gilles Caulier
Comment 2 p 2007-02-22 15:10:26 UTC
Two more questions:

1. How do you change the white balance of a jpeg?

2. 5000K is 5000K, why should I see "different" pictures using different programs? (on the same LCD of course)
Comment 3 Guillaume Castagnino 2007-08-25 19:33:31 UTC
Hi

Peter, I think you are confusing RAW white balance and RGB white balance.
Currently, the digiKam "White Balance" acts on the RGB space, so AFTER raw conversion.
So in fact, temperature provided within the WB tool is relative to the original WB of the picture (which is not necessary neutral). So there is a biais in temperature interpretation in this tool.

Currently, white balance during RAW conversion is only handeled for automatic and camera embeded white balance (in dcraw setup in digiKam configuration box).

By the way, I agree that the values are quite strange. Having a "Neutral" WB (that provides RGB multipliers = (1, 1, 1)) at 4750K and 1.2 green multiplier sounds quite strange to me.
IMHO it would be far less strange to have the neutral point at standard CIE D65 with 1.0 green multiplier...

To change that, here[1] is a proposal to change the way of calculating the RGB multipliers from the pair (temperature, green multiplier). I have ported the algorithm from ufraw, that set the neutral white point at D65 illumination. That sounds to me far much logical since it's a widely spread standard.
Moreover, it does not need anymore the enormous blackbody.h matrix.
At your appreciation, but I think it could be a good thing to apply to digiKam ;)

[1] http://casta.nerim.net/digiKam/digikam-kde3-WB-ufraw-multiplier.patch

Regards
Comment 4 caulier.gilles 2007-08-26 13:04:28 UTC
Guillaume,

Thanks for the patch. I will test it.

What's about to adjust automaticly the dcraw WB settings during RAW decoding, especially in 16 bits mode ?

To digiKam users : Please test this patch against KDE3 branch of digiKam svn repository, and give me if all is fine for you to adjust WB of your pictures.

Gilles
Comment 5 Guillaume Castagnino 2007-08-26 13:24:41 UTC
> What's about to adjust automaticly the dcraw WB settings during RAW decoding, especially in 16 bits mode ? 

I have a working solution about a more flexible WB adjustment during raw decoding (in fact, the current version is here[1], based on ufraw WB to RGB multipliers conversion : ) ;)
Especially within kipi-plugin rawconverter, it makes WB correction very handy, the only missing feature is the color picker to automaticaly neutralize...

But before sending it "officially", I must know if you want to keep the current digiKam algorithm or if you will apply my patch to use ufraw way of converting temperature to RGB multipliers : the WB computation of the RGB multipliers should be the same on both side to be more coherent :)

[1] http://casta.nerim.net/digiKam/libkdcraw-kde3-dcraw-WB.patch
http://casta.nerim.net/digiKam/digikam-kde3-dcraw-WB.patch
http://casta.nerim.net/digiKam/kipi-plugins-kde3-dcraw-WB.patch

Regards

PS: sorry for not providing also the kde4 branch patch : my kde4 digiKam version compiles but does not currently starts, so I cannot test anything...
Comment 6 Guillaume Castagnino 2007-09-02 21:21:18 UTC
Here is the same patch for the kde4 branch (I finally set up a correct kde4 env to test it) :
http://casta.nerim.net/digiKam/digikam-kde4-WB-ufraw-multiplier.patch

Guillaume
Comment 7 caulier.gilles 2007-09-03 14:15:10 UTC
Guillaume,

KDE3 patches sound good for me. I will apply it on svn later than libkdcraw 0.1.2 will be release to not broke release plan planed by Angelo.

Your KDE4 patch is completely different. Its about white balance image editor plugin... Why ?

Gilles
Comment 8 caulier.gilles 2007-09-03 14:20:12 UTC
*** Bug 148561 has been marked as a duplicate of this bug. ***
Comment 9 Guillaume Castagnino 2007-09-03 19:16:05 UTC
the kde4 patch at comment #6 is relative to the same patch for kde3 branch at comment #3 ;)

The patches for kde4 branch of libkdcraw I spoke about at #5 comment are here :
http://casta.nerim.net/digiKam/digikam-kde4-dcraw-WB.patch
http://casta.nerim.net/digiKam/libkdcraw-kde4-dcraw-WB.patch
Comment 10 Arnd Baecker 2008-02-22 18:54:28 UTC
SVN commit 778164 by abaecker:

More flexible WB adjustment during raw decoding
(many thanks to Guillaume Castagnino for the patch).
Note that a current libkdcraw is needed as this had to be changed.

CCBUGS: 142055
TODO:KDE4PORT



 M  +2 -1      NEWS  
 M  +12 -11    imageplugins/whitebalance/imageeffect_whitebalance.cpp  
 M  +2 -2      imageplugins/whitebalance/imageeffect_whitebalance.h  
 M  +87 -47    libs/whitebalance/whitebalance.cpp  
 M  +4 -2      libs/whitebalance/whitebalance.h  
 M  +5 -3      utilities/imageeditor/editor/editorwindow.cpp  
 M  +9 -5      utilities/setup/setupdcraw.cpp  
 M  +1 -1      utilities/setup/setupdcraw.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=778164
Comment 11 Marcel Wiesweg 2008-02-23 15:58:57 UTC
SVN commit 778390 by mwiesweg:

Commit white balance patch by Guillaume Castagnino

CCBUG: 142055
CCMAIL: caulier.gilles@gmail.com


 M  +149 -180  dcrawsettingswidget.cpp  
 M  +10 -15    dcrawsettingswidget.h  
 M  +86 -15    kdcraw.cpp  
 M  +3 -2      kdcraw.h  
 M  +40 -65    rawdecodingsettings.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=778390
Comment 12 Marcel Wiesweg 2008-02-24 22:47:15 UTC
SVN commit 778921 by mwiesweg:

Commit whitebalance patch by Guillaume Castagnino
(which I forget yesterday)

CCBUG: 142055
CCMAIL: caulier.gilles@gmail.com


 M  +13 -12    imageplugins/whitebalance/imageeffect_whitebalance.cpp  
 M  +2 -1      imageplugins/whitebalance/imageeffect_whitebalance.h  
 M  +88 -48    libs/whitebalance/whitebalance.cpp  
 M  +4 -2      libs/whitebalance/whitebalance.h  
 M  +9 -6      utilities/imageeditor/editor/editorwindow.cpp  
 M  +9 -5      utilities/setup/setupdcraw.cpp  
 M  +1 -1      utilities/setup/setupdcraw.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=778921
Comment 13 caulier.gilles 2008-02-24 22:49:09 UTC
All patches from Guillaume are now applied to svn. I close this file now.

Gilles Caulier