GNOME Bugzilla – Bug 532637
PPM files are assumed to be in working color space.
Last modified: 2015-10-21 21:54:02 UTC
Please describe the problem: The PPM format specifies that pixel values should be encoded according to the BT.709 standard, which has the same R, G, and B primaries as sRGB but a different gamma curve. See http://netpbm.sourceforge.net/doc/ppm.html. There are many PPMs in circulation that do not follow this standard. GIMP however seems to treat all PPMs as being in the working RGB space, and does not prompt for how to treat the image data, despite "Ask what to do" being set as the file open behaviour in the colour management options. Steps to reproduce: 1. In the Colour Management options, set File Open behaviour to "Ask what to do". 2. Open a PPM file. Actual results: The image is loaded with no questions asked, and appears to be treated as being in the working RGB space already. Expected results: I would expect to be prompted for how to convert the image data to my working space, either assuming it to be BT.709 encoded data (since BT.709 is implicitly embedded by the format being PPM), or in the working space (no conversion), or perhaps by specifiying an input profile. Does this happen every time? Yes. Other information: The BT.709 encoding and decoding functions can be found on this page: http://msdn.microsoft.com/en-us/library/bb970392(VS.85).aspx The PPM files written by dcraw follow this standard.
Not surprising. In order to fix this the PPM loader would have to generate the proper ICC profile. The lcms library provides this functionality, so it should be easy to implement. Someone just needs to write the code.
Looking at the link you gave, I have the impression that BT.709 is very close to sRGB and that the authors of the PPM format would have used sRGB if it would have been available at that point. The spec even states: "A common variation on PPM is to substitute this color space for the one specified." I suggest that we follow this common variation and treat PPM as sRGB instead of annoying the user with a color conversion that will for most images not even make a visible difference. Closing as WONTFIX.
I disagree. The difference is very visible. Loading a BT.709 image as sRGB makes it appear washed out. I will attach some samples.
Created attachment 110894 [details] Sample PPM image in BT.709 encoding
Created attachment 110895 [details] Sample PPM image in sRGB encoding
Created attachment 110896 [details] Plot of sRGB and BT.709 encoding curves.
Also, I don't see how it is "annoying" to the user to be prompted about a colour conversion when they have explicitly requested in the preferences to be asked.
Simple because I doubt that many users are using PPM and actually rely on the color space not being sRGB. I might be completely mistaken here, but as far as I can see, PPM is a niche format mainly used for embedding graphics in applications. And even that is so very uncommon these days. We might even want to drop PPM support at some point because it is so very unimportant these days. I don't think we would be doing our users a favor if GIMP suddenly started to interpret the colors in PPM files differently. Anyway, if someone wrote the code for it, then we could perhaps make this an option.
I only think it matters because it's what dcraw outputs, and that's basically the only open source tool for decoding raw photos - everything else wraps it. For many years the author insisted it would only write PPM. TIFF has now been added as an option but the output is still in BT.709 encoding. Since this is the standard tool for raw photos it seems crazy that it is impossible to open the output accurately in GIMP. I'm willing to try to write the code.
Note that it is also crazy to export a raw photo as 8bit and not doing that in sRGB. Doing the conversion from BT.709 to sRGB on 8bit data is going to introduce errors that could be avoided by doing the conversion in dcraw. Anyway, if you want to work on this, there's a code example at http://littlecms.com/pngchrm.c which can probably give you an idea on how to create a color profile using lcms.
> Note that it is also crazy to export a raw photo as 8bit and not doing that in > sRGB. Doing the conversion from BT.709 to sRGB on 8bit data is going to > introduce errors that could be avoided by doing the conversion in dcraw. This is also true. You can compile dcraw with -DSRGB_GAMMA to get it to do this, but this is totally undocumented. I will email the author and see if this can made a command line option, or at least documented on the web page.
It seems to me that whenever a user opens any image file (not just a ppm file) that doesn't have an embedded ICC profile, it ought to be up to the user to supply the profile they want to use, as Gimp simply can't know what the right profile really is. You can assign and convert a ppm file to any color space you want, but you can't embed the ICC profile, and you can't just assume that it's always BT709. Even dcraw lets the user output ppm files in color spaces other than BT709, and the desired gamma and linear portion can be modified at the command line. I don't know what the situation was in 2008, but at this point dcraw allows for tiff and ppm output with a user choice of output color spaces. Also, in 2013 none of the open source raw processors that I'm familiar with (UFRaw, Photivo, RawTherapee, RawStudio, darkTable, the digiKam raw processor) are simple wrappers for dcraw. Rather they all implement their own interpolation routines and color conversion code. They use dcraw for decoding but not for actually processing the raw files.
I gussed we close this bug as OBSOLETE, the tool chains are a bit more sophisticated these days, and doing this sort of profile conversion on 8 bit data feels very odd to me.
I *suggest* ...
Following my own suggestion which has been sitting here uncommented for two and a half years... Git master opens the file as sRGB, there is no "working space profile" any longer.