https://bugs.kde.org/show_bug.cgi?id=410796
--- Comment #7 from vikto...@gmail.com --- 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". -- You are receiving this mail because: You are watching all bug changes.
