Re(3): use of sRGB as a default
Re(3): use of sRGB as a default
- Subject: Re(3): use of sRGB as a default
- From: Olaf Drümmer <email@hidden>
- Date: Sun, 20 Jun 2004 22:31:26 +0200
Hi Matt,
email@hidden wrote 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.
no problem with that. If the solution to all this mess was obvious, there
wouldn't be a mess in the first place.
It took me a long time to kind of figure out what _I_ think is a decent
approach to deal with all this - from a user's point of view as well as
from a developer's point of view. And honestly: I am still working on
extending and fine tuning and polishing and verifying my own
understanding. Will probably still take much more time than I like.
>
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.
Yep, absolutely correct. Neither Apple nor ICC nor anybody else (to the
best of my knowledge) ever came up with good guidelines.
Some of my own conclusions:
Forget about finding out what the right source profile for an image or
any graphic object is. Instead, start with the question: what is the
original. What is the appearance (colorwise) of some image that I (or
whoever is in charge at that point) declare to be the original.
In order to be able to answer that question, I need a mechanism that
allows me to see the color. With today's (colorimetric) technology that
means I need to establish a link from my color numbers in my image to an
idealized representation of color, and then propagate that idealized
representation of color to a device that allows me to actually see the
color. The link from image color values to the idealized representation
is achieved by means of a source profile (which happens to be a
mathematical amalgam of transfer curves and/or a matrix and/or a look up
table with some accompanying parameters), the idealized representation is
usually called profile connection space (PCS), and the route from PCS to
some display (or printing) device is achieved through a destination
profile. The underlying assumption here is that in principle the
transformations from source to PCS to destination by means of appropriate
ICC profiles and a CMM as the actual number cruncher works sufficiently well.
On the background of this scenario there is always a source profile
involved, whether it is embedded in the image, chosen ad hoc by the user
or assumed as a default by a programmer or some application.
Surprisingly, it does not matter whether that source profile is the
'right' profile (e.g. the scanner profile for the scanner that was used
to capture the image) - it is more relevant that when viewing the image
using a certain source profile its appearance is considered 'original' by
the person that is in charge.
Once this step "declared original" is completed, an appropriate source
profile is known and should actually be associated with the image (by
embedding it).
So as a developer of whatever application the following questions are
relevant:
- has the image already been declared original?
- if so, by means of an embedded profile? If yes, maintain/honor that
profile (or convert numbers to some other profile and then save the data
with that other profile)
- if not, who is responsible for declaring some appearance the 'original'?
- if the user can't be bothered, some best guess approach is needed; if
the guess is good and the users says 'wow, this looks great', just
associate the resp. profile with the image data
- if you can bother the user, let him/her choose among a couple of
alternatives, or maybe he/she brings her own profile to the table;
provide visual feedback, and let him/her make the choice, and take it
from there.
All in all: if the users thinks an image looks great, don't argue. You as
a developer know (should know) how you managed to display that image, and
based on that knowledge you can derive what the proper source profile is.
Grab it, use it for display/printing/conversions, and put it inside the
file so that further downstream other applications don't have to start
from square one.
Does that sound like a starting point? Or still to much theoretic bla bla?
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.