SUMMARY After moving from DigiKam 5.9 to DigiKam 6.1 and now 6.2, converting from CR2 to PNG fails when using the same Batch settings. It seems to fail to write to NAS. STEPS TO REPRODUCE 1. In Thumbnails, add one CR2 file to Current Queue (#1) 2. In Batch Mananger, adjust Queue Settings - Target -- Create new Album under existing album and select that album as destination. - Behavior -- Wrok on all processor cores = check - Raw Decoding -- 16 bits color depth = Check -- Quality = AHD -- Correct false colors in highlights = check - Assigned Tools = Convert to PNG 3. Press Run All OBSERVED RESULT History shows 4 items "Failed to process item..." <blank message> "Failed to process item..." "Failed to create file..." EXPECTED RESULT PNG version of CR2 file should be added to the Newly created album. SOFTWARE/OS VERSIONS macOS: 10.14.6 Digikam 6.2.0 - build date Jul 31 2019 KDE Frameworks Version: 5.59.0 Qt Version: 5.11.3 (vuilt against 5.11.3) The cocoa windowing system ADDITIONAL INFORMATION
Convert to JPEG works.
I will test it afterwards, but probably a problem of the color profile. Libpng now has a very strict color profile check and refuses to save invalid color profiles for libpng. Add a color profile conversion before converting to PNG and choose e.g. an sRGB profile. Maik
Yes, tested. With these RAW settings, the conversion to PNG fails because of the color profile. I will add a note to the PNG tool. Maik
Git commit 2ddf14f092fcbd8722a5c2f1b01227ee7b851038 by Maik Qualmann. Committed on 10/08/2019 at 20:53. Pushed by mqualmann into branch 'master'. add a note to the BQM-PNG tool to convert the color profile beforehand Related: bug 388898 FIXED-IN: 6.3.0 M +3 -1 NEWS M +15 -3 core/dplugins/bqm/convert/converttopng/converttopng.cpp https://invent.kde.org/kde/digikam/commit/2ddf14f092fcbd8722a5c2f1b01227ee7b851038
Once I changed the working color space in Digikam Settings to normal sRGB, the conversion to PNG worked. I guess this brings up a question - why is this special version of sRGB 2.1 available in Digikam Settings, but not in the Batch Queue Settings? Digikam Settings - Color Management -- Enabled - Working Color Space = sRGB IEC61966-2.1 (sRGB Profile.icc) - When the profile of an image does not match the working color space = convert - When an image has no color profile information = assume it is sRGB, convert to working color space = check When loading a RAW file with uncalibrated colors = Automatic color correction Batch Queue Settings - Color Management -- Camera Profile = None (camera saves RAW as sRGB) -- Workspace = sRGB
The problem is a little deeper. The RAW Loader checks the color profile used by the digiKam setup. He trusts only the digiKam color profiles when the RAW file is loaded with 16bit, otherwise the ProPhoto color profile is used. The ProPhoto color profile is rejected by Libpng. So if you use the srgb-d65 in the digiKam color profile settings, there are no problems. If you use an external srgb profile, ProPhoto will be used, resulting in an error. This is the note in the source code: --------------------------------------------------------- // Specifying a custom output is broken somewhere. We use the extremely // wide gamut pro photo profile for 16bit (sRGB for 8bit) and convert afterwards. --------------------------------------------------------- I tend to use the AdobeRGB profile as a relapse instead of ProPhoto. Or would it be better to accept the user selection, even if the user-selected profiles may be broken? Maik
OK, so when a RAW file is loaded with 16-bit, it defaults to Pro Photo. And when a RAW file is loaded with 8-bit, it defaults to sRGB. Would it be better to accept the user selection - you mean, ignore the defaults and just use the DigiKam setup? First may I point out that sRGB suits my task just fine. My purpose with trying sRGB 2.1 was to try something else when some prints I ordered came back a bit too red. However, in the interest of making Color Management less confusing, I think there are three points of discussion here? 1. Since the Color Management Settings inside the Queue Settings were ignored when I tried to export to PNG, when are they not ignored? Is it necessary for these settings to be there after the Color Management section was moved from the RAW settings to its own section in DigiKam 6.0? I have not been able to find any documentation on when these settings apply. 2. Should DigiKam use default Color Space Profiles when it encounters external Profiles? If it is broken, then it seems that the solution is to fix it. However, my limited experience with Color Management tells me that the ability to customize the working color space is not as important as the ability to customize the final color space. It would be nice if there was a way to notify the user of such a behavior. In the Editor, the Working color space can be shown in the Status bar. In the Batch Process, the working color space (or soon to be forced working color space) can be shown in a separate Color Management tab (like in DigiKam Preferences) in the Queue Settings. 3. What to do when a LibPNG does not support a color space profile? It would have been nice if one of the 4 messages I received was "unsupported color profile".