On 02/07/2010 04:55 AM, Omari Stephens wrote: > Hi, all > > I wrote up a quick spec for how GIMP should deal with color profiles > associated with files and images. The spec is attached, and is also > attached to bug 608961. If you have any general thoughts/comments, I > would love to hear them, but please note the scope of the document. Hi Omari, Comments on the spec: "1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space." I don't think we should assume that, do you have an example use case where that is a good idea? Speaking of use cases, we should document somewhere what uses cases the solution must support. If we don't document this then there will be use case regressions when the system is adjusted later. I think we should rather assume the image is in the working space color space. My thinking is that it is the same working space color profile that is used for the GIMP color picker and also for images without a color profile attached. So when you pick RGB 128,128,128 in the GIMP color picker and open an image with no color profile, RGB 128, 128, 128 in the image will be displayed the same as RGB 128,128,128 in the GIMP color picker. "2) When an image is opened _with_ an associated color profile, the user will have the following options:" I don't think I follow completely, why would we ask the user what to do here? If the image has a color profile attached, we should definitly use it. If the user wants to convert to some other color space for some reason, he can do that when he pleases "3) When a PNG is opened that is tagged with the sRGB chunk a) This is as-yet undecided. See the later discussion about sRGB chunk vs. sRGB profile." If the image is specified as in sRGB, why should we not treat it as such? "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. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Multi-column dock windows and 2.8 schedule" _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
