On Sat, 2008-02-09 at 03:06 +0100, Axel Wernicke wrote:
> 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?
> Version: GnuPG v1.4.8 (Darwin)
> AW7MEb5dkf7chKksvIUTc5o=
> =zTgP
> _______________________________________________
> Gimp-user mailing list
> Gimp-user@lists.XCF.Berkeley.EDU
> 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 mailing list

Reply via email to