On 01/24/2010 08:29 PM, Hal V. Engel wrote: > On Sunday 24 January 2010 01:35:20 am Omari Stephens wrote: ::snip? SNIP!:: >> After a bit more thinking, it occurs to me that it makes no sense for us >> to not have a a copy of the working-space color profile, if we want to >> consider the image tagged with that profile. Consider the following: >> >> 1) Suppose we consider the image not to be associated with _any_ >> profile. We use our default working-space profile because that's why >> it's there. When we export an image, it should not be tagged as >> associated with any color profile. > > This does not seem correct to me. How do you know that the working space > profile is correct for this image? If you are assuming that all users will > have sRGB as their working space this assumption will fail for at least some > subset of users. For example it is common for photographers to use wider > gamut color spaces such as ProPhotoRGB or BetaRGB as their working color > space. Using one of these color spaces for viewing untagged images is > definitely not correct. > > The general guidance from CM experts is that if you are going to make > assumptions about what color space should be used with an untagged RGB image > then it should be sRGB. But for the general case you should also allow the > user to specify how they want this to be handled. Most users will just let > you do the default handling of untagged images (IE. use sRGB) but other users > may want to be asked what should be done for each image or to setup some other > default behavior like always using some other (IE. not sRGB) profile. Good catch. Your suggestion is indeed what I had intended. It means that every image is tagged with a profile. It seems the easy way to implement this would be to just assume that "empty icc-profile parasite" == "image implicitly tagged with sRGB".
An image with only an implicit sRGB tag is exported without any color profile or tag attached. If it's PNG, it is exported with neither an sRGB chunk nor an iCCP chunk. As always, the user may assert (aka "apply") some color profile for the image, or may convert the image to some color profile, in which case the starting profile will be whatever lives in icc-profile, be it the implicit sRGB profile or some explicit thing. Furthermore, the user may chose to have GIMP prompt them as to what to do, with options being (1) assert some color profile (2) leave untagged, in which case we implicitly use sRGB, (3) convert from an implicit sRGB to some explicit profile, like AdobeRGB or ProPhotoRGB. >> 2) Suppose we consider the image to be associated with our working-space >> profile. When we export an image, it should be tagged with our >> working-space profile. If what we export is a JPG or a TIFF, they have >> no equivalent to PNG's "sRGB chunk" — we need to have a copy of the >> actual sRGB profile on hand so that we can apply it to the exported file. > > Again it appears that you are assuming that sRGB will always be the users > working space profile. This is not a valid assumption. This was more an argument for "we need to have sRGB profiles on-hand" than anything. If our working space is anything other than sRGB v2, we're guaranteed to have a file somewhere. We've only been lazy with sRGB v2 because lcms has the profile built in somewhere. >> For exporting to PNG here, if our working-space is sRGB v2, we have the >> option of applying the color profile or adding the PNG sRGB chunk. >> According to the standard, these should be equivalent. Whether this is >> the case in practice is something I'm unsure about. > > PNG appears to be a special case where the specification states that any > untagged image is sRGB by default. So it appears the PNG needs to be handled > in a different way than JPG, TIF .. files. Since the specification is clear > about this there is not need to assume how this should be handled. If the PNG > image is not tagged it is sRGB. From the reading I've done, there is a practical difference between PNG-with-sRGB-chunk and untagged-PNG: """ According to the CSS2 specification, the CSS color values refer to the sRGB color space. In practice, however, all browsers except Mac IE 5 with ColorSync enabled (disabled by default) seem to just treat the CSS color values as values in whatever color space the system color space happens to be. Still, it would be reasonable to expect the colors of an sRGB-labeled PNG image to be treated consistently with CSS colors. """ (from http://hsivonen.iki.fi/png-gamma/) We need to enable the practical use of GIMP, and as such, we need to differentiate between untagged and tagged-with-sRGB-chunk. This is why GIMP's current behavior of always-tagging, while correct in theory, is incorrect in practice. My question was essentially whether we _also_ need to differentiate between PNG-tagged-with-sRGB-chunk and PNG-with-sRGBv2-color-profile. In theory, the two options are equivalent. In practice, though, this may not actually be the case. --xsdg _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
