Version: 0.9.0-svn (using KDE KDE 3.5.1)
Installed from: Slackware Packages
Compiler: gcc version 3.3.6
Digikam does not get the color temperature information from RAW files.
Howver, this is very very important for a more professional work.
With this information (e.g. ExifTool by Phil Harvey can extract this value) digikam should set this value on the white balance pane (supposing dcraw was set during the conversion to use the "color temperature set by the camera"!)
After the white balance adjustments, digikam should remember this value _until_ we save it to jpg or whatever (the color temp information for jpg is not important, since it is not really adjustable any more)...so I guess It should not be stored in a database or so...simply in the memory during the workflow.
I'm agree with you than digiKam must get color temperature value sey by camera, but not directly.
Exiv2 library is used to handle metadata from RAW file and especially the makernote data where all camera makers store this value.
I think than a new method must be done in Exiv2 library to get color temperature. The code can be based on ExifTool method backported in C++.
Please, make a wish in Exiv2 bugzilla about this subject. Thanks in advance.
Wish is posted to Exiv2 site!
Hopefully they can improve the library...
What is the status about this issue?
(Also noote that this sounds related to
~1 year ago I have posted the issue to Exiv2 bugzilla as it was suggested by Gilles. I haven't received any reply from the Exiv bugzilla since then. I don't know if they improved the library or not, but I can try with the latest version of digiKam if the problem still exists.
Something can be done in Exiv2 to extract Color Temperature from RAW files like ExifTool do ?
Is the Color Temperature that you're looking for a part of the Exif data? Can you provide some samples of the information you're looking for? When I run exiftool over different RAW files, it seems like possibly part of the makernotes.
Yes, Color Temperature come from Makernote. Minolta provide this value directly in °K, but others maker provide this value using encyption as Nikon for ex.
SVN commit 784222 by cgilles:
digiKam from KDE3 branch : RAW image loader : backport 8 bits color depth auto-gamma and auto-white balance adjustements from dcraw with 16 bits color depth.
These auto adjustements are performed only if Color Management is not used with image editor.
The color rendering in 16 bits is exactly the same than in 8 bits.
This is want mean than you can process speedly your RAW exactly as JPEG. Just set your usual settings in RAW dedoding and open your RAW pictures as well in editor.
This is the same way used by LightZone pro software to process RAW file without color management !
This way simplify the task in Raw workflow... and will be suitable in 90% of case. Color Management must be used in others cases...
M +1 -0 Makefile.am
M +76 -0 rawloader.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=784222
SVN commit 784238 by cgilles:
backport commit #784222 from KDE3 branch
M +77 -3 rawloader.cpp
M +2 -2 rawloader.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=784238
Please try current implementation from svn and look if loading RAW picture in 16 bits color depth without to use Color Management is fine for you.
Note: RAW autogamma code is not in 0.9.4-beta1, but in future 0.9.4-beta2
Thanks in advance
I will try to check it during this weekend, but I don't know for sure if I will have time.
I will post here the result as soon as possible...
Thanks in advance
I have compiled the latest svn version of digiKam yesterday.
I have selected 16bit mode and decoded raw images. I had no problem with gamma correction and neither with the color temperature.
The only thing is that, when I opened the "White balance..." window, the temperature settings was always standing in 6500K, however, I am sure that lots of my images was not shot with this value.
To summarize, the conversion was fine (it seems that the tool calculated with the embedded temperature information), but it looks that the "White balance" adjustment doesn't care about this value.
Your request in #13 is relevant of bug #236304.
The original problem of this file is solved. I close it.