Re: [Gimp-developer] GIMP color-management spec and further discussion
On 2/10/10, yahvuu wrote: > Among garden-variety photo labs, it's pretty much standard to discard any > color profile information and just assume sRGB. It's pretty much standard where you live maybe, but not where *I* live :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
I had composed a response, and then shortly before sending, WIFI on my laptop conked out. I think yahvuu covered most of what I was going to say, though. I'll send it anyway when I pull the laptop out again. --xsdg On 02/10/2010 07:09 PM, yahvuu wrote: > Martin Nordholts wrote: >> On 02/07/2010 04:55 AM, Omari Stephens wrote: >> "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? > > I think the best guess is sRGB, assuming a file that was produced by a legacy > device. > Which were (back then) to be viewed on monitors with a profile similar to > sRGB. > > Another source for images of these kind are web developers who want to > achieve consistent colors cross a web page -- the rationale beeing: > if the browser has no color profile information, the colors may be wrong, > but at least consistent. > > Among garden-variety photo labs, it's pretty much standard to discard any > color profile information and just assume sRGB. > > >> I think we should rather assume the image is in the working space color >> space. > > The user's choice of a working space does not reveal any information about > an unknown image. I don't think the chosen working space should be > used as input for import heuristics. > >> 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. > > OK, the color picker's colors must match, of course. Probably that means > that the color picker can't show any numbers as long it's not yet clear > which color space it will be assigned to. > Or, perhaps better: the color picker gets disabled when no image is open. > > But the same problem still occurs when switching between images with > different working color spaces. The very same color may have different > RGB values in different color spaces. Assuming a calibrated monitor, > the color picker displays absolute colors, so i think the RGB values > should change, not the colors. > > > regards, > yahvuu > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Martin Nordholts wrote: > On 02/07/2010 04:55 AM, Omari Stephens wrote: > "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? I think the best guess is sRGB, assuming a file that was produced by a legacy device. Which were (back then) to be viewed on monitors with a profile similar to sRGB. Another source for images of these kind are web developers who want to achieve consistent colors cross a web page -- the rationale beeing: if the browser has no color profile information, the colors may be wrong, but at least consistent. Among garden-variety photo labs, it's pretty much standard to discard any color profile information and just assume sRGB. > I think we should rather assume the image is in the working space color > space. The user's choice of a working space does not reveal any information about an unknown image. I don't think the chosen working space should be used as input for import heuristics. > 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. OK, the color picker's colors must match, of course. Probably that means that the color picker can't show any numbers as long it's not yet clear which color space it will be assigned to. Or, perhaps better: the color picker gets disabled when no image is open. But the same problem still occurs when switching between images with different working color spaces. The very same color may have different RGB values in different color spaces. Assuming a calibrated monitor, the color picker displays absolute colors, so i think the RGB values should change, not the colors. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Omari Stephens wrote:"). > What does "compatible with AdobeRGB" actually mean? It means that it was written to conform to Adobe's published specification of AdobeRGB. > How does > "compatible with AdobeRGB" differ from "AdobeRGB"? (Note: I assume that > you know what you're talking about here much more than I do.) It differs from the AdobeRGB profile in that it was created completely independently from it, and was not authored by Adobe, does not come from Adobe, nor is it endorsed or certified or approved by Adobe. > Beyond that, if someone has the "real" AdobeRGB profile, it would be > nice if they could swap it in somehow. Of course, the importance of > this depends on your answers to my questions above. Any "real" or "actual" AdobeRGB profile is (of course) Copyright by Adobe. How is that useful to you ? (Why don't you simply look at them side by side first ?) Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
On 02/08/2010 07:41 PM, Graeme Gill wrote:
>
> Omari Stephens wrote:
>> For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
>> This means that even if we know it _should_ be AdobeRGB, the user will
>> need to take some action either to make that profile available or to tag
>> it manually.
>
> Why can't you apply a profile compatible with AdobeRGB ? I've
> certainly made one available under the public domain ("ClayRGB1998.icm").
What does "compatible with AdobeRGB" actually mean? How does
"compatible with AdobeRGB" differ from "AdobeRGB"? (Note: I assume that
you know what you're talking about here much more than I do.)
Beyond that, if someone has the "real" AdobeRGB profile, it would be
nice if they could swap it in somehow. Of course, the importance of
this depends on your answers to my questions above.
Either way, though, I think the EXIF problem is definitely important but
is also mostly decoupled from what I'm trying to fix right now.
--xsdg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Omari Stephens wrote:
> For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
> This means that even if we know it _should_ be AdobeRGB, the user will
> need to take some action either to make that profile available or to tag
> it manually.
Why can't you apply a profile compatible with AdobeRGB ? I've
certainly made one available under the public domain ("ClayRGB1998.icm").
Graeme Gill.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Omari Stephens wrote: > For one, as Sven pointed out, we can't ship the AdobeRGB color profile. > This means that even if we know it _should_ be AdobeRGB, the user will > need to take some action either to make that profile available or to tag > it manually. i think that is a special case of 'invalid profile detected', with some extra help to show how to install the profile. > Secondly, we currently use libexif for parsing EXIF in JPEG. We need to > switch to exiv2, but since the latter is C++, we'll need a C/C++ > compatibility layer as well. A further problem is that we don't > currently support EXIF in PNG, which we should (and would be able to > with exiv2). thank you, i see. The scope is the 2.8 release. Proper EXIF handling may even be beyond 2.10 as bug #56443 suggests. (The introduction "probably i'm just missing the point, but ..." was in my head but didn't make it into the posting) regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
On 02/08/2010 01:39 AM, Graeme Gill wrote: > Omari Stephens wrote: >> Obviously, options for both of these things are "prompt the user." It seems >> like there >> should be better alternatives, but I'm not sure what they might be. >> guiguru? others? > > You're better having a set of defaults that the user can configure, > so they aren't constantly hassled by prompts. The configuration can > have options such as "prompt me" for certain combinations. Yes. By "prompt the user" I meant something similar to the current behavior when an image is tagged with a color profile other than the working space profile; the options are: 1) Do nothing 2) Convert to working space profile 3) Prompt the user I was hoping someone would come up with a better convention, but since that doesn't seem to be happening, I will rev the spec and mention this UX paradigm explicitly, with the hope that it will be improved upon in a later revision. >> Author: Omari Stephens Version: 1 Date:3 February 2010 > >> 1) When an image is opened with no associated color profile, we assume that >> it is >> encoded in sRGB space. > >> c) Convert the image from >> the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, >> etc.) > > Not a good idea. There are losses in every color conversion. Ideally you want > to > keep an image in its original format, unless the user explicitly decides to > convert to another colorspace. Input is not the place to do this. > > So the application (GIMP) should have a transformation step available to: > > 1) Convert from one colorspace to another. If an image has no tag, >then both profiles would need to be specified. > > 2) Assign a profile to the image. This would set or override a tag. > > One idea to consider is the possibility of a "weak color tag". This > is for a image that is to be considered un-tagged, but has a profile > to specify the source colorspace for the purposes of display, and conversion. Your "weak color tag" is exactly what I meant by an "implicit sRGB profile". My judgment was that it wouldn't be useful to have a "weak" tag that wasn't sRGB — anything else should be explicit and embedded. > There should be a "color tag" status somewhere for an image. Because the only implicit color tag is sRGB, the absence of an icc-profile parasite (or an empty one) can be considered equivalent to the implicit sRGB tag. >> 4) When an image with an explicit profile is exported >> a) It will be tagged with that >> profile in whatever way is appropriate for the file format. >> b) If this is an sRGB PNG, >> we need to decide between an sRGB chunk and sRGB profile. See later >> discussion. >> c) If the file format has no way to embed color profile information, (FIXME!) > > For c), have the option to covert to a particular colorspace (ie. sRGB). Cool. Any thoughts from other people? > d) Have an option to write the file without an embedded profile. This is an > important > option in regard to dealing with other applications, for instance sending > calibration > or profiling files to a particular device. I was thinking a tiny bit about this, but hadn't come up with anything conclusive. I'll probably implement something trivial where you can select a menu item to dump the icc-profile. >> 5) When an image with an implicit profile is exported a) The image is saved >> with no >> color profile information. For PNG, this means no sRGB chunk and also no >> iCCP chunk. > > You could really have the same options as 4, although you might default them > differently. Hmm; good point. Will think about that. > There are many possible ways of dealing with this issue. The important things > as > I see them are 1) Allow defaulting to logical and useful workflows 2) Allow > flexibility to accommodate particular needs. Yup. Thanks for thinking about this. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Omari Stephens wrote: > Obviously, options for both of these things are "prompt the user." It seems > like there > should be better alternatives, but I'm not sure what they might be. > guiguru? others? You're better having a set of defaults that the user can configure, so they aren't constantly hassled by prompts. The configuration can have options such as "prompt me" for certain combinations. > Author: Omari Stephens Version: 1 Date:3 February 2010 > 1) When an image is opened with no associated color profile, we assume that > it is > encoded in sRGB space. > c) Convert the image from > the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, > etc.) Not a good idea. There are losses in every color conversion. Ideally you want to keep an image in its original format, unless the user explicitly decides to convert to another colorspace. Input is not the place to do this. So the application (GIMP) should have a transformation step available to: 1) Convert from one colorspace to another. If an image has no tag, then both profiles would need to be specified. 2) Assign a profile to the image. This would set or override a tag. One idea to consider is the possibility of a "weak color tag". This is for a image that is to be considered un-tagged, but has a profile to specify the source colorspace for the purposes of display, and conversion. There should be a "color tag" status somewhere for an image. > 2) When an image is opened _with_ an associated color profile, the user will > have the > following options: > b) Convert the image to some other explicit profile Same comment as above. > 4) When an image with an explicit profile is exported > a) It will be tagged with that > profile in whatever way is appropriate for the file format. > b) If this is an sRGB PNG, > we need to decide between an sRGB chunk and sRGB profile. See later > discussion. > c) If the file format has no way to embed color profile information, (FIXME!) For c), have the option to covert to a particular colorspace (ie. sRGB). d) Have an option to write the file without an embedded profile. This is an important option in regard to dealing with other applications, for instance sending calibration or profiling files to a particular device. > 5) When an image with an implicit profile is exported a) The image is saved > with no > color profile information. For PNG, this means no sRGB chunk and also no > iCCP chunk. You could really have the same options as 4, although you might default them differently. There are many possible ways of dealing with this issue. The important things as I see them are 1) Allow defaulting to logical and useful workflows 2) Allow flexibility to accommodate particular needs. Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
NOTE: if someone wants to think about the UI/UX involved in the color
management spec, I would really appreciate it. Right now, I have no
time for thinking outside the box — it's all I can do to find 30 minutes
here and there to do some GIMP hacking as it is. So if you don't want
to see more options at the bottom of the "Color Management"
configuration pane, your help would be appreciated.
(more comments inline)
On 02/07/2010 12:36 PM, yahvuu wrote:
> Hi all,
>
> 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.
>
> Please don't forget to incorporate EXIF data into the show:
> https://bugzilla.gnome.org/show_bug.cgi?id=492048
>
> For quite some time, users will have to deal with incompatible and
> especially simply incomplete implementations of color management.
> Possibly that pain [1] can be eased if users are supported to specify
> workarounds, like: 'camera xy' + 'filename starts with _' => AdobeRGB.
> Sort of heuristic device drivers.
I specifically chose to ignore that problem for now, as I think it's
more difficult to deal with than the generic "has embedded ICC profile
or not?" problem. I should probably have mentioned that in the spec
("what is out of the scope of this spec" or somesuch).
For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
This means that even if we know it _should_ be AdobeRGB, the user will
need to take some action either to make that profile available or to tag
it manually.
Secondly, we currently use libexif for parsing EXIF in JPEG. We need to
switch to exiv2, but since the latter is C++, we'll need a C/C++
compatibility layer as well. A further problem is that we don't
currently support EXIF in PNG, which we should (and would be able to
with exiv2).
In short, I would consider "make EXIF work right" a mostly-orthogonal
problem to "make color management work right". They're both important,
but the color management problem is the one that I'm focusing on right now.
> PS: I think the scope of your questions is actually more of UX. As you said,
> the pure technical solution is to popup when inference fails.
True. Unfortunately, guiguru doesn't seem to have been around in any
real capacity of late, so I think I'm going to have to start off by
adding functionality in ways that work but are non-ideal, and then we
can refine it later on.
> [1] an example of how it took 5 days to track down the
> import problems for some Pentax cameras:
> https://lists.xcf.berkeley.edu/lists/gimp-user/2010-January/016415.html
Hmm. matching the filename against /_...[0-9]{4}\.jpg/i is one
potential heuristic to suggest (this image should be AdobeRGB), but I'm
not sure it would be worth the effort — if someone has a bunch of
untagged (as opposed to EXIF-tagged) AdobeRGB images, then they've got a
problem in their workflow.
--xsdg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Hi all, 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. Please don't forget to incorporate EXIF data into the show: https://bugzilla.gnome.org/show_bug.cgi?id=492048 For quite some time, users will have to deal with incompatible and especially simply incomplete implementations of color management. Possibly that pain [1] can be eased if users are supported to specify workarounds, like: 'camera xy' + 'filename starts with _' => AdobeRGB. Sort of heuristic device drivers. regards, yahvuu PS: I think the scope of your questions is actually more of UX. As you said, the pure technical solution is to popup when inference fails. [1] an example of how it took 5 days to track down the import problems for some Pentax cameras: https://lists.xcf.berkeley.edu/lists/gimp-user/2010-January/016415.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
