Martin Nordholts wrote: > "4) When an image with an explicit profile is exported > c) If the file format has no way to embed color profile information, > (FIXME!)" > > In terms of a problem, this is pretty similar to "when an image has > several layers and we export to an image format that does not support > layers, what do we do?". If the image doesn't support any kind of layer, > we simply merge or flatten the image, no questions asked. If the image > supports both layers and non-layers (such as animated GIF), we let the > user choose. I think we should do the same in this case: if the target > image format does not support color management whatsoever, we should > just write the RGB values verbatim, i.e. do the best of the situation > without becoming annoying and asking questions. If the written RGB > values are important than the user needs to do a color space conversion > before exporting into that format. While this is certainly a good point and in contrast to what i've proposed elsewhere [1], i'm a lot less shure that this the best solution. The counter-arguments are just too striking: a) *Not* converting to sRGB by default fosters the accidental release of unmanaged non-sRGB files, i.e. files, which cannot be interpreted correctly without external information. b) A cycle of export and re-import should preserve as much of the image data as possible to comply with the principle of least surprise. From assuming sRGB on import follows conversion to sRGB on export here. c) The layers analogy applies, but can be used with a slight twist: File formats that don't support profiles can be regarded as formats which don't support other color spaces than sRGB. So export should silently auto-convert by default. regards, yahvuu [1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-February/024222.html _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
