Version: digikam-0.9.2 beta3 (using KDE KDE 3.5.6) Installed from: Ubuntu Packages OS: Linux when opening a raw image (tested with NEF) directly in the image editor gamma adjustment is neither done automatically nor is it provided in the import dialog. I would rather expect the result of opening a raw to be the same like the raw converter plugin. But I also understand that there might be cases, where one wants to yield the original linear curve of the raw image. Therefor I'd suggest to add a lightness/contrast/gamma control to the raw import dialog. Default value for gamm shoud be sth. typical between 1.8 and 2.2.
Am Tuesday 05 June 2007 schrieb Martin Schmettow: [bugs.kde.org quoted mail] :-) This feature is already implemented, look at the last tab in the RAW import dialog, there is a lightness curve setting. Gerhard
I've seen this. But I think it is not very user-friendly, because manipulating curves is a very advanced skill. And I haven't seen any other raw converter requiring the user to set the lightning curve manually. In order to serve all users this dialog should present (in this order): * a reasonable default or auto correction for beginners or users in hurry (the raw converter plugin already does a good job here) * lightning/contrast/gamma sliders for advanced users * the lightning curve for profis Martin.
Yes, I think that what Marin proposed is a very good solution. The lightning curve is sometimes to heavy to use, where gamma correction should be a more simpler way to work the picture.
Also there should be some place, where the settings for the raw image will be saved (like bibblepro uses filename.nef.bib), to be able to start next time with same settings, which I have already done for the image. Or if I make .jpg from nef, in database should be link between the two images, which will allow to switch between both versions and also show how was the .jpg made. Currently If I click save on converted image, it is expected to stay in same directory as the nef is. It is not bad to have all the photos together, but browsing thru this directory is extremly slow. Extracting thumbails from nef takes many time. And You see only half of the photos, if every is shown twice. Probably the nef should be in some other directory or the UI should have button to show/hide raw versions of photos while browsing.
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... BUG: 146393 CCBUGS: 124814 CCBUGS: 150457 CCBUGS: 155074 M +1 -0 Makefile.am M +76 -0 rawloader.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=784222
SVN commit 784400 by cgilles: Kipi-plugins from trunk (KDE4) : Raw Converter : use auto-gamma and auto-white balance in 16 bits color depth mode. CCBUGS: 146393 M +88 -15 rawdecodingiface.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=784400
Also until this fix I have used instead of kdcraw wrapper like this: /usr/bin/dcraw.bin $* | pnmgamma -cieramp and the result seems be better, than from current svn version.
Dan, I have also tried pnmgamma especially with -cieramp. but there not gamma adjustement done automatically. Also white balance is not set in this case. The current implementation backport all auto-adjustements performed by dcraw in 8 bits color depth. Gilles Caulier
Dan, maybe you could send Gilles off-list your specific example (original raw, corresponding jpg if you have it, pnmgamma converted and the new digikam result) - something like "the result seems to be better" is hard debug/improve without additional information ;-) Best, Arnd