Chris!
I have been following this conversation and I must admit that I have had the
same misperception about gamut mapping. So I went to test this straight away
and I must say that you are right. So this mean that ICC-profile software
manufacturers assume some kind of wide colour space to start with. And this
also means that if one is using small RGB space and perceptual rendering one
never fully utilise the whole CMYK colour space.
Is there somewhere info what kind of starting colour spaces different
software (e.g. Gretag ProfileMaker, PrintOpen) have? It must be quite large
- otherwise colours that would be outside this assumed colour space would be
clipped?
BR Jouni
-----Original Message-----
From: eci-en-admin(a)lists.transmedia.de
[mailto:eci-en-admin@lists.transmedia.de] On Behalf Of Chris Murphy
Sent: 1. kesäkuuta 2005 12:46
To: eci-en(a)lists.transmedia.de
Subject: Re: [ECI-EN] ECIRGB versus LstarRGB 2
On Jun 1, 2005, at 3:05 AM, Karsten Krüger wrote:
When using perceptual rendering, the whole source gamut has to fit
into the destination colorspace. Rendering does not look for how much
of the source gamut your image is using. If it would do so you would
receive different results when moving from image to image. So when
your source gamut is huge, it gets compressed a lot when rendering to
a small CMYK output gamut.
This is not an uncommon misperception. The reality is that gamut
compression is not dynamic. The CMS does not do "more" gamut
compression for a large source space because it defers to the gamut
compression that's "pre-baked" into the output device profile. Gamut
mapping in the output profile is done at the time the profile is built,
when a source space is not even selected yet.
If you take an sRGB image and convert it to ProPhoto RGB, then convert
both to CMYK you will get effectively identical conversions. You do not
get more gamut compression by virtue of having your image in a giant
color space. Color management isn't that smart.
This does not happen with colorimetric rendering (either absolute or
relative). In this case everything outside the smaller output
colorspace is just clipped to the edge of it. If your image is small
enough, you don't see any problem. If it is bigger, you end up loosing
details.
There is still some gamut compression with relcol otherwise we'd have
images with even a little bit of out of gamut colors that would get
totally clobbered by clipping. But there should theoretically/ideally
not be much gamut compression for in-gamut colors. Only out of gamut
colors would get compressed.
Take a picture of neon advertisement at night or
flowers with vivid
colors in bright sunlight with an EOS 20D. Render them to ISOcoated.
Using photographic rendering intend you get decent results. Using
colorimetric rendering intend you end up loosing a lot of details and
the emotions from your pictures are gone.
I've experienced this also. But practically speaking, the vast majority
of images in the world do not have highly saturated fine detail that's
really important - we can accept some detail loss or the detail isn't
highly saturated. So relcol works very well for most images, including
those in ProPhoto RGB.
I like to use an other setup. Why should I keep and
manage data I am
not able to reproduce.
You can't reproduce it today perhaps. That doesn't mean you won't be
able to reproduce it tomorrow. A majority of images destined for print
to a press aren't likely to get reused ever again, so it's not a big
deal to limit them from the get go. I have no problem with this. I'm
just saying that there's a good reason to use a wide gamut RGB space
that is not normally talked about, and that's about shadow detail. I'm
not looking to tell people what they are using successfully today is a
bad choice and that they should change. It depends on what you do and
what's important to you.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en