1:20 p.m.
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
9:53 p.m.
New subject: ECIRGB versus LstarRGB 2
On Jun 1, 2005, at 5:20 AM, Marttila Jouni wrote:
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.
Correct. This is why I've not been a proponent of perceptual
rendering for most images. It does a fine job with respect to
preserving detail, but it totally clobbers the image with respect to
saturation. I'd say some 90% of the images I come across render much
better with Relative Colorimetric + Black Point Compensation. Now
that BPC is document, I consider its use a basic requirement for
conversions, other than for proofing or spot color matching. The
exception images are the ones that are highly saturated and have fine
detail - those typically render better using perceptual or sometimes
saturation rendering.
Supposedly there is some possibility for dynamic gamut compression
due to changes in ICC v4. But it seems to me for this to happen, we
need new CMM's that are not only v4 compliant, but also are
specifically written with dynamic gamut compression in mind. It's not
like the ICC profile is smart enough to do this on its own. While
there are ICC v4 compliant CMMs (a handful anyway), the only one I'm
aware of that appears to be doing something that hasn't been done
before is from ColorIQ (www.coloriq.com). I have not yet had an
opportunity to test this new CMM however, so I really don't know much
about it at this point. But I am absolutely in favor of smarter CMMs.
Now in a PDF/X-3 or PDF/X-4 context, smart CMM's turn into a
challenge because what if I use a different smart CMM than my
printer? Oops. We have different rendering, and my expectations are
not met. There is an argument to be made for allowing pre-rendering
using a smart CMM, without committing to a specific output space, to
solve this particular dilemma. That is, you'd use the smart CMM to
prerender your images based on a close approximation of the gamut of
the destination device, and then build a device-independent PDF/X-3
document. Then the PDF/X-3 goes to the printer where "normal"
conversions and gamut mapping practices apply to convert from device-
independent space to device-dependent 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?
It's a secret :) The guts of profiles use proprietary computations
which is in large part what profile companies use to claim copyright
for the profile. I personally find this argument specious because
there are equally complex algorithms found in Photoshop, and if you
use multiple layer effects arguably you are creating a composite
algorithm much more complex than used to build an ICC profile. Yet
Adobe makes no claim to copyright the image you've created using
their algorithms and software.
In any event, it's unlikely this information is documented for public
consumption.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)
7:48 p.m.
New subject: ECIRGB versus LstarRGB 2
Hi all
I have just caught up with the RI discussions, very interesting and Chris's
comments match my own 'Real World' findings!
Having put together a number of colour managed page work flows processing
1000's of RGB images to CMYK a month, the CM needs to be automated.
After a lot of testing I can confirm that for 95% of RGB images the relative
colorimetric intent, with BPC, is the most suitable. The remaining 5% are
not 'spoilt by this intent, just not as good as using perceptual.
However if perceptual is used, a poor, desaturated CMYK often results.
So in a 'industrial' CM workflow, where choice and manual intervention is
limited, RC is the intent.
Paul Sherfield
The Missing Horse Consultancy Ltd
Telephone: 01442 871752
Mobile: 07899 906385
Apple Solutions Expert-Print & Publishing
This email and any attachments may be confidential and are intended solely
for the use of addressee. If you are not the intended recipient of this
message, any disclosure, copying or other distribution is strictly
prohibited and may be unlawful. If you have received this message in error,
please notify the sender and delete all copies from your system. Email may
be susceptible to data corruption, interception and unauthorised amendment.
We do not accept liability for any such corruption, interception or
amendment or the consequences thereof. We do not accept liability for any
action or inaction by the recipient as a result of advice or information
contained within this email.
9 p.m.
New subject: ECIRGB versus LstarRGB 2
On Jun 3, 2005, at 11:48 AM, Paul Sherfield wrote:
Hi all
I have just caught up with the RI discussions, very interesting and
Chris's
comments match my own 'Real World' findings!
Having put together a number of colour managed page work flows
processing
1000's of RGB images to CMYK a month, the CM needs to be automated.
After a lot of testing I can confirm that for 95% of RGB images the
relative
colorimetric intent, with BPC, is the most suitable. The remaining 5%
are
not 'spoilt by this intent, just not as good as using perceptual.
Yeah and what this means for developers making products that produce
output device profiles, we really need well behaved colorimetric
intents! It's not good enough to just focus on the in-gamut colors and
maybe some out-of-gamut colors.
To test for this, build a Granger Rainbow (or download it from
colorremedies.com/realworldcolor and click on Downloads), assign an RGB
profile to it and then convert using an output profile you wish to
test. I don't expect RC to do a perfectly smooth job, especially when
using a wide gamut color space as source. But for it to posterize and
have nasty holes in it, not OK. This is not an irregular occurrence and
causes a greater dependence on perceptual rendering than is otherwise
necessary.
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)
3:52 a.m.
New subject: ECIRGB versus LstarRGB 2
Hello
Now that the discussion has reached this point would you mind commenting on
these points
(1) Is it taken for granted that some editing of the conversion side of the
profile table is necessary to create acceptable separations
(2) Are industry standards like SWOP and ISO profiles artificially corrected
to create desired gray balance, colour saturation and reduce the difference
between perceptual and colormetric rendering intents
(2) While I appreciate that profile software is evolving all the time, but
recently in a direct comparison between GMB and Monaco I have found Monaco
to have better saturation ( or suffering less desaturation particularly in
perceptual intent)
(3) Does any know if it is possible to take the data from an ECI2002
measurement file which was created using Gretag MacBeth Measure Tool
And use it to create a profile with Monaco software
Michael Gardner
Technical Services
PMP Print
Phone 03 9538 8594
Mobile 0423 602 337
Email michael.gardner(a)pmplimited.com.au
From: Chris Murphy <lists(a)colorremedies.com>
Reply-To: eci-en(a)lists.transmedia.de
Date: Fri, 3 Jun 2005 13:00:08 -0600
To: eci-en(a)lists.transmedia.de
Subject: Re: [ECI-EN] ECIRGB versus LstarRGB 2
On Jun 3, 2005, at 11:48 AM, Paul Sherfield wrote:
**********************************************************************
This email and any attached files are confidential. They are intended solely for the use
of the individual or entity to whom they are addressed. If you have received this email in
error, please notify the sender by return email, and delete the original.
All outgoing emails and attached files are virus scanned, but we do not represent that
this email and any attached files are free from computer viruses or other defects.
Further, we do not accept any liability for any damage caused by this email or
attachments.
Hi all
I have just caught up with the RI discussions, very interesting and
Chris's
comments match my own 'Real World' findings!
Having put together a number of colour managed page work flows
processing
1000's of RGB images to CMYK a month, the CM needs to be automated.
After a lot of testing I can confirm that for 95% of RGB images the
relative
colorimetric intent, with BPC, is the most suitable. The remaining 5%
are
not 'spoilt by this intent, just not as good as using perceptual.
Yeah and what this means for developers making products that produce
output device profiles, we really need well behaved colorimetric
intents! It's not good enough to just focus on the in-gamut colors and
maybe some out-of-gamut colors.
To test for this, build a Granger Rainbow (or download it from
colorremedies.com/realworldcolor and click on Downloads), assign an RGB
profile to it and then convert using an output profile you wish to
test. I don't expect RC to do a perfectly smooth job, especially when
using a wide gamut color space as source. But for it to posterize and
have nasty holes in it, not OK. This is not an irregular occurrence and
causes a greater dependence on perceptual rendering than is otherwise
necessary.
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
5:35 a.m.
New subject: ECIRGB versus LstarRGB 2
On Jun 8, 2005, at 7:52 PM, Gardner, Michael wrote:
Hello
Now that the discussion has reached this point would you mind
commenting on
these points
(1) Is it taken for granted that some editing of the conversion
side of the
profile table is necessary to create acceptable separations
I think what is necessary depends on a number of things: your
tolerances (or that of your customer's), the kind of images you're
converting, and to what degree you are satisfied with the gamut
mapping of the software building the profile. The less you're
satisfied with gamut mapping in particular, the more likely you're
going to make color-in-color edits, such as with blues or reds. This
kind of profile editing is, in my view, unfortunate, as well as it is
fragile. Profiles break easily with this kind of editing, which is
why I'd rather see better gamut mapping on-the-fly (smarter CMM),
which can also take some degree of input from the end user.
However, the ability to edit profiles is also a good thing insofar as
our measurement devices and color models don't account for everything
the human visual system does. So we use the tools to get most of the
way there, then evaluate the result and fine tune it by hand with
some light profile edits. If you're having to do major edits in a
profile, something isn't right.
(2) Are industry standards like SWOP and ISO profiles artificially
corrected
to create desired gray balance, colour saturation and reduce the
difference
between perceptual and colormetric rendering intents
As far as I know, they are built directly from their corresponding TR
001 and FOGRA colorimetric data sets.
(2) While I appreciate that profile software is evolving all the
time, but
recently in a direct comparison between GMB and Monaco I have found
Monaco
to have better saturation ( or suffering less desaturation
particularly in
perceptual intent)
I like them both for different reasons. I prefer the Monaco RelCol,
and the gmb perceptual (using Colorful setting). I think which
package you go with has less to do with which one absolutely does
better than the other rather than it has to do with which one is
performing the way you want it to, for the images you work on, and
has the rendering you like.
(3) Does any know if it is possible to take the data from an ECI2002
measurement file which was created using Gretag MacBeth Measure Tool
And use it to create a profile with Monaco software.
It should be able to consume them directly so long as you tell it
you're using the ECI2002 target.
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)
2:34 p.m.
New subject: ECIRGB versus LstarRGB 2
Hello
Now that the discussion has reached this point would
you mind
commenting on
these points
(1) Is it taken for granted that some editing of the
conversion side of
the
profile table is necessary to create acceptable
separations
(2) Are industry standards like SWOP and ISO profiles
artificially
corrected
to create desired gray balance, colour saturation and reduce the
difference
between perceptual and colormetric rendering intents
(2) While I appreciate that profile software is
evolving all the time,
but
recently in a direct comparison between GMB and Monaco
I have found
Monaco
to have better saturation ( or suffering less
desaturation particularly
in
perceptual intent)
(3) Does any know if it is possible to take the data
from an ECI2002
measurement file which was created using Gretag MacBeth Measure Tool
And use it to create a profile with Monaco software
ColorThink 2.2 beta from Chromix is the ability to read Monaco Profiler
export and session files and export them in the standard CGATS format
that GretagMacbeth uses. So you can use ColorThink to convert Monaco
Profiler readings for use with GretagMacbeth software. But from GMB to
Monaco, I do not know.
Kind regards,
Kimmo Poikonen
Cmykit
6905
days inactive
6913
days old
eci-en@lists.callassoftware.com
6 comments
5 participants
participants (5)
-
Chris Murphy -
Gardner, Michael -
Kimmo Poikonen -
Marttila Jouni -
Paul Sherfield