Re: Minimal color management strategy for GIMP 2.8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday 24 January 2010 01:35:20 am Omari Stephens wrote:
> On 01/24/2010 09:03 AM, Omari Stephens wrote:
> > On 01/24/2010 08:31 AM, Martin Nordholts wrote:
> >> Omari Stephens wrote:
> >>>> I had naively signed up for the "work on color management" job. That
> >>>> said, do you happen to know where the sRGB thingie is added by
> >>>> default? (if not, I can probably find it, but if you know offhand, I'm
> >>>> not beyond laziness ;o)
> >>>
> >>> It was actually trivial to find. Right now, I'm just considering the
> >>> consequences before I nuke that 4 lines of code.
> >>
> >> You are talking about
> >> http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456
> >> right?
> >>
> >> Nuking those four lines is not enough, a way to embedd an sRGB profile
> >> must also be added. Unfortunately, assagning an sRGB profile to an image
> >> in current GIMP does not "stick" since sRGB is the default color space.
> >> We need to change this. Changing this is likely to cause problems in
> >> other parts of the color managed code which needs to be taken care of.
> >
> > Any licensing folks about?  Debian's "icc-profiles" package ships an
> > sRGB profile that has license [1].  The ICC itself also provides sRGB v2
> > and v4 ICC profiles for use with licenses [2] and [3], respectively.
> > Can we ship one of these with GIMP?  At the very least, the PNG spec
> > calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though
> > both the BPC-enabled and BPC-disabled versions seem to count as
> > 61966-2-1.
> >
> > Also, from a practical standpoint, are there important situations where
> > someone would want to tag a PNG as sRGB, but where simply applying the
> > actual sRGB color profile wouldn't be a reasonable substitute to the
> > sRGB PNG chunk?
> >
> ::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.    

> 
> 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.

> 
> 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.

> 
> 3) If the user tags the image with some color profile from her
> filesystem, then we cache that profile in the icc-profile parasite.  We
> use the parasite to tag the image when we export it.
> 
> 4) If the user opens an image that is already tagged with some profile,
> the profile is already in the icc-profile parasite.  We use the parasite
> to tag the image when we next export it.
> 
> --xsdg
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
> 
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux