Re(2): use of sRGB as a default
Re(2): use of sRGB as a default
- Subject: Re(2): use of sRGB as a default
- From: Olaf Drümmer <email@hidden>
- Date: Sun, 20 Jun 2004 12:41:40 +0200
Hi Matt,
sadly enough you are right - if the color management experts can't get
their act together, why should developers (who more often than not have
to implement many other things besides some color management
functionality) even when they try to listen to the experts' advice get it
right?
email@hidden wrote Sun, 20 Jun 2004 03:38:32 -0500
>
On 6/19/04 at 3:33 PM, Chris Murphy <email@hidden> wrote:
>
>
> On Jun 19, 2004, at 4:29 AM, Dennis W. Manasco wrote:
>
>
>
> > By the way: How could anyone hired to program Mac OS X color issues be
>
> > so unaware of color-management as to assign the monitor profile as the
>
> > source?
>
>
Well, I hate to interrupt such an unfettered session of naked
>
superiority, but here goes.
>
>
I'm a programmer. I have an image editing program. I open an image that
>
has no profile attached, and the user edits it, adjusting colors, levels,
>
rotating this or that, airbrushing whatever. Now I want to save the
>
image, but there's no existing profile information. I have to assign a
>
profile to it. The only source I have is - you guessed it - the display.
the first question to be asked is: how do I initially display the image
(when first opening it) - here using the display profile for
characterizing the color data in the image is one option that is by
definition less than perfect unless the image has been created using that
same display. One assumption that actually seems to work quite OK is to
assume sRGB (or Generic RGB, as John has just thrown in), or you could
interactively ask the user by iterating through a series of RGB profiles
and let the user decide which looks best/correct. Whether you end up with
sRGB or something else: you'd then have to use that profile as a source
profile and convert to display color space for displaying the image. The
user could then edit the image, and for saving the data back to disk
you'd use the sRGB (or whatever it was) to (finally) tag the file.
The "my monitor profile is my working space profile" approach had been
used by Photoshop until around version 5.0 or 5.5, but from then on they
switched to a working space profile independent of the monitor. One
additional reason to do so is that certain profiles are better at being
used for editing/color corrections etc. than others. And some have
deficiencies (like sRGB whose gamut is too small in certain areas - which
you can't really blame it for, as it was initially conceived as a kind of
lower end profile/color space, high quality prepress or professional
digital cameras were not on its agenda) one would tend to avoid. Typical
working space profiles for professional work are Adobe RGB or eciRGB
(though I bet we'll see a couple of replies that even these are not good
enough and we need profiles much better than these...).
>
My user has made the image look the way he wants using his display. The
>
most logical thing to do is to embed the display profile. Given the
>
basic concepts, that *should* mean that the embedded profile describes
>
how the raw pixel values differ from the ideal color space. Either that,
>
or I convert the image using the display as a source with "generic" as a
>
destination and embed the profile to describe how the raw pixel values
>
*should* look. Or something like that.
>
>
Yet the overwhelming vibe on this list is that anyone with such an idea
>
is too stupid to be allowed to *view* color, much less manage it.
>
Despite this, I have yet to see any rational explanation, in simple
>
terms, of what you folks consider the correct profile to embed, and why.
>
>
> It's for performance reasons that the concept exists. But I think we're
>
> long past the point where display compensation should be occurring
>
> within application windows.
>
>
And this is what I mean -- you're suggesting here that to manage color
>
properly, an application should not use display profiles to compensate
>
for anything?
Display profiles should only be used for converting color such that it
can then be displayed on the monitor. Ideally this is handled by the OS.
>
I know you all think this is incredibly logical, because you give off
>
that message every time you look down your noses at John or anyone else
>
who dares to suggest that there may be more to designing the system than
>
your particular needs. It's incredibly off-putting most of the time, and
>
it's no wonder that more programmers don't read this list and pick up
>
your wants and needs more correctly.
I wholeheartedly agree. While I am definitely once in a while more than
disappointed how certain things are implemented in OS/X (or Windows, or
Adobe apps, or Quark apps, or ....) I do believe we should focus on
voicing our requirements (and our disappointment) but try to be fair
towards others. Sadly enough I get the impression we are lucky that folks
like John and his group are still trying to make as good a job as they
possibly can give the limited resources they have. We shouldn't beat them
and others but encourage them (you know, the "glass is half empty versus
the glass is half full" thing).
>
There's also so many terms thrown around that it's next to impossible to
>
keep up with them. Chris seems to use "monitor RGB" instead of "display
>
color space" or "source color space," I think. Others seem to use
>
"default profile" and "generic profile" as the same thing, and I'm not
>
sure they are. And the only consensus there's been on "ColorSync
>
Preferences" is that apparently there should be 25 different versions so
>
everyone can make it work they way they imagine it.
Here I believe ICC is to blame. Thorough terminology (beyond the ICC file
spec) and best practice guidelines for implementation never got addressed
properly in their work.
>
Feel free to bitch at me about this, it's no skin off my nose. But this
>
is what I perceive. I'm becoming increasingly convinced that color
>
management doesn't improve because customers are more interested in
>
calling vendors stupid for not supporting their ideas than in working
>
together to tell all vendors what they expect, how what they see differs
>
from that, and why it's important.
Olaf
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.