I've finally located the issue, which is that ArchLinux switched to GCC 4.8 recently. Building LibRaw with GCC 4.8 causes raw-identify to no longer load the camera multipliers. Since the libraw package was built before the switch and the darktable package after it explains why raw-identify found the camera WB while darktable did not.
So I've submitted a bug report to LibRaw here: https://github.com/LibRaw/LibRaw/issues/21 . Since I'm usually using darktable-git anyway I've solved the issue for myself by simply building the package with Clang instead. Regards, Per On 2013-05-15 21:13, Per Östlund wrote: > I've made some more attempts at figuring out what my issue might be, > but I still haven't found a solution. I updated my system again in the > hope that the issue would be automagically fixed, but no luck. I also > installed darktable on my laptop, same issue there. I've looked at > which packages I've updated lately, but haven't found anything > suspicious. > > raw-identify from libraw 0.14.7 gives daylight multipliers 2.753 0.922 > 1.151, which when normalized is the same that darktable uses (tint > 1.001, temp 6405K). raw-identify also gives camera multipliers 2684 > 1024 1504 1024 (tint 0.967, temp 5028K) for the photo I've uploaded, > which seems to be about the same as "dcraw_emu -w" uses (i.e. > "correct" WB). I should perhaps say that I'm using darktable-git at > the moment, which only uses one temperature slider. > > I also looked a bit into the source code for darktable, and looked at > the reload_defaults functions for the temperature module. After the > RAW is loaded with libraw_open_file I noticed that raw->color.cam_mul > is {0, 1, 0}, which leads darktable to use raw->color.pre_mul instead, > which is the same as the daylight multipliers that raw-identify > reports (i.e. 6405K). I then tried to find where these numbers came > from, but libraw isn't exactly straight-forward to understand :) > > Regards, > Per > > On 2013-05-13 20:12, Per Östlund wrote: >> Hi! >> >> Darktable has suddenly decided that all my photos were taken with a >> white balance of 6504K, which makes photos taken in daylight appear >> yellow. RawTherapee also shares this delusion, so I suspect it's not >> actually darktable's fault but some library that darktable uses >> that's been updated recently. It's not a camera issue, since old >> photos are also affected. >> >> Setting the white balance manually works fine, so it appears as if >> darktable just can't read the white balance from the camera. >> "dcraw_emu -w" from libraw also gives the correct white balance. The >> same issue occurs with both darktable 1.2 and darktable from git. My >> camera is a Sony NEX-7, and the same issue occurs with older photos >> taken with a NEX-5. I put up a RAW on my google drive if anyone wants >> to take a look. The preview that google shows is a bit colder than >> "dcraw_emu -w" gives, but it's reasonably accurate. I also put up a >> downsized JPEG from darktable without any settings changed to show >> what darktable gives. The photo was taken with a manual lens, so the >> EXIF for aperture and such is wrong in case you wonder about that. >> >> RAW: >> https://docs.google.com/file/d/0B14SELFLwaQ1UTNkYVRQVXI2MzA/edit?usp=sharing >> JPEG: >> https://docs.google.com/file/d/0B14SELFLwaQ1ZzE3Z1MtX2p6VU0/edit?usp=sharing >> >> Anyone know what the issue might be? >> >> Best regards, >> Per Östlund > ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
