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: Matt Deatherage <email@hidden>
- Date: Sun, 20 Jun 2004 12:05:36 -0500
I'm really not trying to pick on you, Olaf, but I want to illustrate my point that the people who write application software aren't going to participate in this kind of discussion with some comments. Please don't take them personally -- it's not like I understand the topics any more clearly than you do, actually, far from it.
But it makes me look like a bit of a bastard. Sorry about that in advance.
On 6/20/04 at 5:41 AM, Olaf DrC<mmer <email@hidden>
wrote:
>
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.
Can the first question be less confusing? :)
>
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.
OK, stop right there. Most discussion I've read (including Apple's
developer documentation) calls sRGB a _color space_, but you just
called it a "profile" and a "source profile." I thought a _profile_
defined a device's behavior. I'm not meaning to pick on you, because
there clearly is such a thing as a color space profile, but if people
use such key terms interchangeably when they're not, there's no way
anyone is ever going to figure anything out. I'm beginning to think
the unmodified word "profile" should never be used except to refer to
an ICC file on disk, and that in all other cases, it should be "device
profile," "display profile," "color space profile," etc.
<
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/
csintro/csintro_colorspace/chapter_3_section_3.html#//apple_ref/doc/uid
/TP30001148-CH222-TPXREF106>
Second, it's clear that without any kind of profile, my theoretical
program must assume *something* about the characteristics of the raw
pixel values in this image I've just opened that has no embedded
profile. What I'm reading is that I should assume that the image is in the sRGB or generic RGB _color space_, but a color space profile is not a source profile for this purpose, is it?
When I'm done with the image, I'm supposed to embed a color space profile and not a device profile? But my user just spent two hours making the image look right on his display! You're telling me I'm *not* supposed to use any of the characteristics of his display by embedding his display profile in the image file? If you want programmers to understand that quickly, someone's going to have to tell them *why* in terms they can understand without reading them five times.
I have yet to see that in any ColorSync document, discussion, or header file that I've examined. It's all on one of three levels: "ColorSync is magic and embedded profiles solve everything" for beginners, "Here's how to do everything in Photoshop and QuarkXPress" for creative professionals, or "Since you can already construct ICC profiles in your sleep" for color professionals.
>
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.
As a programmer, btw, I tune out right about here - I'm not writing Photoshop (theoretically) and how files round-trip between my application and a six-year-old version of Photoshop does not interest me at all. If anything, I want to make files that the *current* version of Photoshop won't mangle when it opens them, but that's a check-off item and not a total design goal for most programmers.
>
One additional reason to do so is that certain profiles are
>
better at being used for editing/color corrections etc. than others.
[lots of text trimmed here] This kind of background is good for creative professionals, but programmers are going to zone out, because they're not going to edit images in AdobeRGB or eciRGB. Programmers want to know what they should do with untagged images by default, both in the simple (invisible) case (like Preview), and in an advanced case where they might have to present you with choices if you ask for them. My program is not going to explain AdobeRGB in its help files, so bluntly, I don't care. If you guys want *all* programs to manage profiles correctly, you can't explain the history of color management in the answer to every question.
>
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.
So, as a programmer, do I *ever* embed a display profile? If not, can there be a simple statement somewhere that says "display profiles are always destination profiles and never source profiles?" (I may have missed it, but if it's that simple, it *should* be that simply said.)
>
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.
Apple often has its own style guidelines, but if the company doesn't have a standard set of terms for these concepts, perhaps the ColorSync community should make one and try to enforce it. No programmer's going to implement the right answer if he doesn't understand the question.
(I know there's a ColorSync-Dev mailing list, too, but my point here is more that if users want programs and operating systems to behave differently than they do today, the goals and the terminology needs to be precise. To a programmer, there's a world of difference between an FSRef and an FSSpec, even though conceptually, both are references to a file on some volume. If you use imprecise terms, you'll get imprecise results.)
--
Matt Deatherage <email@hidden> <
http://www.macjournals.com>
I read this list in digest mode; copy me privately for faster responses
_______________________________________________
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.