Re: "Proper Gamut Mapping"
Re: "Proper Gamut Mapping"
- Subject: Re: "Proper Gamut Mapping"
- From: Jan-Peter Homann <email@hidden>
- Date: Mon, 17 Dec 2007 10:40:49 +0100
Hello Todd, hello list,
If a ICC-profile is choosen as source-profile in a conversion, the
transformation from the source- device colorspace to Lab is depending from:
- the software choosed for profile calculation
- the settings for percptual gamut mapping in the profiling software (if
available)
- the rendering intent, which is specified for a transformation.
Lets assume, a photographer has made a properly shot of a standard
camera profiling target. If this shot is used to produce a camera
profile with different profiling software, this will lead to different
perceptual camera->LAB conversions.
The same is with CMYK to CMYK conversions. If printer profiles are
calculated form standard characterization-data like e.g. FOGRA39, the
resulting perceptual tables for
- CMYK->Lab (profile used as source profile)
- Lab->CMYK (profile used as target profile)
Are quite different depending on the profiling software.
If your source profile is matrice based RGB-profile like e.g. sRGB,
AdobeRGB, ProPhoteRGB or eci-RGB, the gamut mapping in the
transformation is only depending from the target profile, because
matrice profiles have identical tables for all intents the profile.
Actually the ICC (vendor-group maintaining the ICC profile
specification) is making the first steps for a better compatibility of
gamutmapping between profiles from different vendors. The project is
called RPMG ( Reference Print Media Gamut)
This could be interpreted a target values, how the perceptual intent of
a profile should be calculated.
The concept has some good ideas, but till today, the ICC has no defined
test procedures for a profile, if the perceptual gamaut mapping of a
profile is conform to the RPMG definition, neither not one of the big
ICC-players like e.g. X-Rite, Heidelberg, Kodak, AGFA e.g. announced to
support the RPMG specs in their. The only application I know is the
opensource ArgyllCMS from Graeme...
For high end colormanagement workflows:
--------------------------------------
Actually, if you want to harmonize gamut mapping for different target
printing processes, all target profiles should be calculated with the
same profiling software. Files deliverd to a printing house should
always be in the final colorspace which has to be agreed with printing
house before making the separation
A special version of an highend RGB-workflow is the usage of
devicelink-profiles from e.g. AdobeRGB to the different target
colorspaces. In this case, the gamutmapping from AdobeRGB to the target
colorspace is optimized through the devicelink creation.
Regards
Jan-Peter
Todd Shirley wrote:
Hi Graeme
I'm interested in this thread, but I'm getting confused, so hopefully
you can clarify. It seems like you didn't respond to Marco's question
because he used the word "convert" instead of "mapped". In your post
(below) you say "mapped from an unspecified non-specific source gamut
to a specific destination gamut" which to me implies a conversion, and
if it doesn't, what do you mean? Are you referring to the fact that a
conversion using standard ICC profiles requires 2 profiles because
each profile can only describe one device, and therefore the
destination profile is converting from a "non-specific source gamut"
because it, by itself, does not "know" the source? How is this a
problem, considering you must use a source and destination profile for
any conversion?
My (limited) understanding of device-links is that they more-or-less
just roll two device profiles into one, thus fulfilling your
requirement that proper gamut mapping is "mapped from a specific
source gamut to a specific destination gamut". How is this gamut
mapping better than using two discrete profiles?
I get confused when you say "how can the source profile have any
affect on the gamut mapping ?" Perhaps I don't understand exactly how
all this works, but doesn't the source profile convert the color
information into LAB using the source gamut, thus resulting in a set
of LAB numbers that are limited to the source gamut? Then when this
information is passed to the destination profile, isn't the source
gamut implied because all the LAB numbers fall within the source
gamut? So it seems to me that even though the "gamut mapping has
already been hard coded into the destination profiles B2A table",
because the LAB numbers are limited to the source gamut the
destination gamut is "informed" by the source gamut? When I write it
out like this, I see that maybe there could be a problem with this
transform, but I can't quite get my head around it. Clearly you have a
better idea, so I'd appreciate if you could clarify why a device
profile transform is better!
Thanks for your time.
–––
--
*********** Neue Adresse / new adress ************
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:email@hidden
*********** Neue Adresse / new adress ************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden