Darktable should read embedded color profiles from JPGs
Darktable messes up images with custom color profiles, see
(color names are in German, the top should be red)
(tested on 1.0.5 from Pascals PPA).
#1 Updated by Tobias Ellinghaus almost 8 years ago
- % Done changed from 0 to 20
- Target version set to Future
- Status changed from New to Triaged
- Category set to Darkroom
- Tracker changed from Bug to Feature
darktable doesn't read embedded color profiles on purpose. I changed this to a feature request, maybe someone is interested in writing code for this.
#2 Updated by Pascal de Bruijn almost 8 years ago
- % Done changed from 20 to 0
- Target version deleted (
- Status changed from Triaged to New
- Category deleted (
- Subject changed from JPGs with embedded color profiles are not rendered correctly to Darktable should read embedded color profiles from JPGs
Darktable is very RAW oriented.
Our JPEG (and other formats) reading implementation have some known limitations. Not reading embedded color profiles is one of them.
We supply our owns version of sRGB and AdobeRGB which can be selected from the 'input color profile' plugin, to compensate for this (to an extent).
If you're using more exotic profiles, you can put whatever profile you need in ~/.config/darktable/color/in (and restart darktable) after which it becomes available for selection in the 'input color profile' plugin.
#6 Updated by Tobias Ellinghaus almost 8 years ago
Since darktable's primary focus are RAW files and reading JPEGs is just a convenience feature this is not a bug. And I guess hardly any developer opens JPEG files in darktable, so it could take quite some time until this ticket can be closed. Sorry for that.
#7 Updated by Andreas Siegert over 7 years ago
Why bother with rendered files at all?
The current implementation is basically useless and shows that they guys who implemented it did not really think it through. Taking the profile from the rendered file would have been trivial.
Better block the rendered files instead of giving the user false hopes.
And yes, there are plenty of reasons why one would want to use one tool for both raw and rendered files. workflow consistency and ease of use for example.