Re: Documenting Gimp Color Management

[Leonard Evens <len@xxxxxxxxxxxxxxxxxxxxx>]

On Sat, 2008-02-09 at 03:06 +0100, Axel Wernicke wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I just wanted to let you know that there is already "something" about  
> the new color management features in the documentation. Feel free to  
> read this
> 
> - - http://docs.gimp.org/en/gimp-imaging-color-management.html
> - - http://docs.gimp.org/en/gimp-pimping.html#gimp-prefs-color-management
> - - http://docs.gimp.org/en/glossary.html#glossary-rendering-intent
> - - http://docs.gimp.org/en/gimp-imaging-color-management.html
> 
> and please, don't hesitate to correct what's written or fill the gaps.  
> Everything in there is to my best knowledge but I'm sure it is neither  
> completely correct nor are all necessary topics in there yet.
> 
> 
> Greetings, lexA

I am attaching a second installment of comments as a text file below.
I'm afraid the comments come across just as criticisms, so let me
emphasize how much I appreciate what you've already done.  Ideally,
rather than just complaining about this or that,  I should suggest how I
would phrase it instead.  Unfortunately, I don't feel comfortable about
writing documentation of this kind yet, so I would rather just raise
points and hope you can figure out what I'm saying and include it in the
documentation if it seems appropriate.  I'm sure you will do a better
job of it than I would at this stage.  When I feel more comfortable,  I
will suggest appropriate wording.

Also, remember that there are several color management issues and, more
important, issues about exactly what gimp does that I find mysterious.
So some of my comments might just indicate ignorance or
misunderstanding.   Even so, I am a relatively experienced gimp user who
is Linux savvy and knows something about color management.  So if I am
confused by something, there is good chance that an average user will
also be confused.

I would find it easier to understand what gimp is actually doing if I
could get at its guts. Instead, I have to do experiments and the results
can sometimes be misleading. I've tried several times to look at code,
but I've been defeated each time, not by the code, but by the complex
structure of the source tree.  Any suggestions about how to learn about
that without making it my life's work would be appreciated.  

> 
> P.S: as Julien already mentioned - if you feel not comfortable writing  
> docbook xml, just give us plain text to incorporate.
> 
> - --
> Remember: There are only two tools in life. WD-40, for when something  
> doesn't move, and should, and Duct Tape, for when something is moving  
> and it shouldn't.
> So does the universe explode if you spray duct tape with WD-40?
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> 
> iD8DBQFHrQqeR9mXLVsAbiQRAntfAJ9FdQqHCMANjDzybGlMrY0tCMq9FACgsXAx
> AW7MEb5dkf7chKksvIUTc5o=
> =zTgP
> -----END PGP SIGNATURE-----
> _______________________________________________
> 
> Gimp-user@xxxxxxxxxxxxxxxxxxxxxx
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Gimp color management documentation.

Here are some suggestions about the current color management documentation.  The general import is that one must be very careful about what you say about what types of profiles may be present and about how they are used.  There are many possible variations, and, as best I can tell from experimentation, there is little consistency.

1. In 1.2. Color Managed Workflow,  under Input

you say :

 'Most digital cameras embed a color profile to individual photo files without user interaction.'

My Nikon D80 most certainly doesn't embed any profile in normal use.  A good guess would be that it has sRGB as a default profile, but I don't know. 

If I shoot raw using the nef format, then with ufraw I can specify input and output color profiles.  I haven't myself figured out exactly what ufraw does with these profiles.  I presume it uses the input profile somehow in converting from the raw data to RGB values.  It could do different things with respect to the output profile.  It could change the RGB values according to the profile and write those out without embedding the profile in the file.  Or it could not change the RGB values but embed the profile in the output file.  From some experimentation, my guess is the former.  I couldn't find any profile in a ufraw output file.  (I use iccdump.)

I don't argue that what you say may not be true for some digital cameras, but I think it is a stretch to say that most digital cameras do that.

2. You also say

 'Digital scanners usually come with a color profile, which they also attach to the scanned images.'

I don't know about most digital scanners.  I only know what happens with my Epson 3200 which I have used under Linux both with xsane and vuescan.  These are the only choices for scanning software that I know of that are available under Linux.  Of course, under Windows XP or MacOS, the vendor supplied software may be used in addition to some other choices. 

xsane requires you to build your own scanner profile, presumably using argyll or lprof with an IT8 target.  vuescan has a built-in mechanism for building a scanner profile using an IT8 target.  (It can also produce film profiles in a similar manner.)  So I think the statement is misleading for Linux  users, who I think consitute the majority of gimp users. 

xsane give you the choice about what to do.  If I remember correctly, it can change the RGB values according to the scanner profile and then write the file out with no embedded profile, or it can leave the RGB values alone and write the file out with the scanner profile embedded.  In both cases, gimp behaves as you say it does in the documentation.   

vuescan behaves somewhat differently.  You specify an output color space as well as a scanner profile, and you specify whether or not vuescan embeds the output color space profile in the output file.  I haven't figured out exactly what happens to the RGB values.

So my experience would not tend to bear out what you say.  I think you should be very careful about such statements because there are a variety of possibilities in the work flow, and one of the  most confusing things is trying to figure out just what is being done to what when.

3. You also say

'When opening an image with an embedded color profile, GIMP offers to convert the file to the RGB working color space.'

That will be true only if you specify it to be under Preferences>Color Management>File Open Behavior.  This is described elsewhere in the documentation, but the statement here could be misleading.  Also, if the embedded profile is sRGB, I believe gimp will use the built-in profile and not tell you.  This is logical, but it can be confusing if you expect a query when opening a file.

4. In 1.2. Color Managed Workflow,  under Display

you say

'One of the most important GIMP commands to work with the color management is described in Section 8.9, “ Display Filters  ”.'

I haven't had time to master Desiplay filters, but they do look quite powerful.  Be that as it may,  I think this sentence at this point in the documentation may be misleading.  It seems to me that if one has profiled a display, it shouldn't be necessary to make further changes in what is seen on the screen.   That seems to me to be second guessing the profiling and to some extent defeats the prupose.  If you used a filter, the resulting image could not be counted on to look the same to someone else with a different color managed monitor who didn't also use the filter.  The filters for correcting visual deficiency seem in a different category.  I have no idea how such a person might make use of color management, but it seems to me an entirely different matter.

5. In 1.22, Color Managed Workflow, under Print Simulation

you say

'In such a simulated printout, colors that cannot be reproduced will optionally be marked with neutral gray color, allowing you to correct such mistakes before sending your images to the printer.'

I think the out of gamut marking could be highly misleading.  I've only just begun to understand printer profiling, but I have managed to use an Eye One Pro with argyll to produce a printer profile, and it seems to work relatively well.  But using a printer profile for soft proofing may or may not move in gamut colors depending on the rendering intents specified when the relevant profiles were built and the rendering intents specified when using them.  If gimp is marking as out of gamut any color which is moved, which I think (possibly mistakenly) is the case, then almost everything will be shown out of gamut if that box is checked.  I think that is what happens with my current printer profile which I built with perceptual rendering intent. I think a user has to have a thorough understanding of gamuts, rendering intents, and how such intents are used to be able to make sense of such information. 

_______________________________________________

Gimp-user@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user