On Sat, 2008-02-09 at 03:06 +0100, Axel Wernicke wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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)
> -----END PGP SIGNATURE-----
> Gimp-user mailing list
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
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
'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
'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