Version: 0.9.2b2 (using KDE KDE 3.5.6) Installed from: Ubuntu Packages OS: Linux The single or batch raw converter won't produce 16bit PNG. This is crucial, because this is the only way to get 16bit AND metadata (in contrast to Tiff). Opening a raw image (tested with NEF) directly in the editor yields 16bit by default, so I guess it's not a principal problem.
This problem still appears in beta 3
Martin, The reason that i have not yet provided 16 bits color depth in Batch RAW converter is relevant of dcraw program used to decode RAW image data. This one generate a linear 16 bits picture without an auto-gamma/White balance correction (witch exist in 8 bits color depth!) The picture result will be too black and require manual fix in editor later batch process. See in dcraw project page about 16 bits linear conversion... It's a generic problem. If i provide 16 bits color depth support with RAW batch converter, i'm sure to a another bug report about black all pictures. Of course, my point of view is than users must always have the choose to apply auto gamma corrections in 16 bits mode... But it's a dcraw problem... Gilles Caulier
Hi Gilles, I fully understand that you hesitate to frighten unexperienced users. But is there really a problem to add 16bit as an option (not default). Consider that users who don't know about gamma and histograms won't have any use of 16bit either. On the other hand advanced user who insist on optimizing each image individually definitely require 16bit. --Martin. P.S. Would it help if I investigated on possible design alternatives and come up with some concrete suggestions?
SVN commit 715867 by cgilles: kipi-plugins from trunk (KDE4) : RAWConverter plugin : support 16 bits color depth conversion. BUG: 146259 M +14 -16 rawdecodingiface.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=715867
Martin, Kipi-plugins for KDE4 is able to convert RAW to PNG in 16 bits color depth. Do not claim than you have a black hole image in this case because the target pictures is not corrected using a Color Management (like digiKam image editor do). dcraw produce a decoded linear image. It's different than 8 bits mode where gamma is automatically corrected. You need to fix color/gamma by hand later using your prefered program witch support 16 bits color depth and color management : digiKam, cinepaint, or Krita. Important : Gimp only support 8 bits color depth ! Guillaume, Marcel, TIFF file format is supposed work properlly with 16 bits batch conversion. The code to write tiff image in 16 bits is very similar than digiKam DImg::TiffLoader... But it doesn't work. The image is completly broken on my computer. Of course, if i use digiKam image editor to save tiff in 16 bits all work fine! After few investigations, i can said : - In 8 bits color depth all work fine with TIFF. - If i disable LZW tiff compression, all work fine. Code from digiKam is in digikam/libs/dimg/loaders/tiffloader.cpp on method save(). Code of TIFF writer used by plugin is in kipi-plugins/common/libkipiplugins/kpwriteimage.cpp on method write2TIFF(). To have a propers tiff image with the plugin, just comments these lines in kpwriteimage.cpp : TIFFSetField(tif, TIFFTAG_COMPRESSION, COMPRESSION_ADOBE_DEFLATE); TIFFSetField(tif, TIFFTAG_ZIPQUALITY, 9); // NOTE : this tag values aren't defined in libtiff 3.6.1. '2' is PREDICTOR_HORIZONTAL. // Use horizontal differencing for images which are // likely to be continuous tone. The TIFF spec says that this // usually leads to better compression. // See this url for more details: // http://www.awaresystems.be/imaging/tiff/tifftags/predictor.html TIFFSetField(tif, TIFFTAG_PREDICTOR, 2); ... of course in this case the tiff file is huge (non-compressed). This is weird. I don't know where is the difference between digiKam and kipi-plugins implementation. I suspect a problem with zlib witch is used to commpress image data. Perhaps something is wrong to link libkipiplugin shared library ? Can you reproduce this problem on your computer ? Gilles Caulier
Hi, I confirm I can reproduce the same problem when TIFF compression is enabled on 16bits pictures. For now I'm trying to review the TIFF saving code :) Guillaume
SVN commit 715970 by cgilles: Marcel, libtiff is very sensible to data type to store in tiff tags. This is why 16 bits color depth is broken in kipi-plugin tiff writer implementation. I have found this difference with digiKam Dimg::TiffLoader implementation: the width and height value need to be casted from int to uint32 to have a fine tiff encoding. This is really a weird side effect from libtiff... So now, kipi-plugins RawConverter is able to export RAW to TIFF in 16 bits color depth. CCMAIL: marcel.wiesweg@gmx.de CCBUGS: 146259 M +12 -14 kpwriteimage.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=715970
Guillaume, Checkout svn and try again. I have found the problem (:=))) Other subject about RAWCOnverter and 16 bits color depth: what do you think to have something to adjust automatically Gamma/WhiteBalance like with 8 bits color depth without to use color management ? Perhaps your last patch from libkdcraw to set White Balance (not yet tested) can be used as well if we extract the WB values set by camera in Exif... Gilles
I confirm this solves the problem ! About adjusting Gamma/WhiteBalance on 16bits pictures in rawconverter : the up to date kde4 White Balance patch is here [1], to allow to use camera/auto/standard D65/custom white balance. But for auto gamma adjustement, I think the only good way should be to work directly into dcraw porting the gamma_lut function to 16bits to achieve a good enough result... But this is not very easy, and problematic when upgrading dcraw... [1] http://casta.nerim.net/digiKam/libkdcraw-kde4-dcraw-WB.patch http://casta.nerim.net/digiKam/kipi-plugins-kde4-dcraw-WB.patch
Gilles, Guillaume, would it make sense to ask the dcraw author whether he would be interested/willing to add such support into dcraw? Best, Arnd
Arnd, Yes, of course, but this will not be a simple task to convince him to have a new option to adjust automatically gamma in 16 bits mode like in 8bits. Look into dcraw web project page : http://cybercom.net/~dcoffin/dcraw/ "Why is 16-bit output dark / unreadable? If you want pretty pictures straight out of dcraw, stay with 8-bit output. 16-bit linear output is the best raw material for professional image editors such as Photoshop and CinePaint, but it's no good for most image viewers." I have not yet talking with him about this subject, but why not to start a new thread about... If you want to do it, let's go, this is the email to use : dcoffin@cybercom.net. Just CC me and guillaume, we will to follow and add comments in the thread... Gilles
Hi, glad to hear from 16bit output into PNG, because may primary problem was to have 16bit AND full exif, which is now achieved. I have doubts, that automatically adjusting Gamma for 16bit makes sense from the perspective of pro workflow. People using 16bit usually do so because they want full control on the tonemapping, which means bringing the 12 bit from their camera sensor to printable 8bit (or so). In this case a auto conversion is counterproductive, obviously. On the other hand, it'll be nice for viewing 16bit photos to have digikam offer or choose a sensible correction. This has to happen without modifying the image and can be based on quite simple Gamme adustment. Please have a look how this is solved in a simple but efficient way by the emerging HDR tool qtpfsgui.sourceforge.net : In the viewer dialogue the user can adjust the image display by selecting a gamma curve and by selecting a range in the histogram. This would be great to have for digikams editor. For the catalog and viewer I'd prefer a auto gamma adjustment. Anyways, this would not affect dcraw, because from these arguments the author of dcraw is 100% correct in not offering 16bit other than linear. Hope that helps. Martin.
Not reproducible with digiKam 7.0.0-beta1.