Re: tools for building device links (was "Proper Gamut Mapping")
Re: tools for building device links (was "Proper Gamut Mapping")
- Subject: Re: tools for building device links (was "Proper Gamut Mapping")
- From: Terence Wyse <email@hidden>
- Date: Sun, 16 Dec 2007 18:16:26 -0500
On Dec 16, 2007, at 3:58 PM, Roger Breton wrote:
You need the link to the article in question. I have a hard copy
which Elie
distributed at the GATF CMS Conference, last week. Very convincing.
So many
ways to skin a cat (sorry Marco).
I believe there's more than a few flaws with this report although this
is the first time I've heard of it or read it. My comments below are
after a quick skimming of the report.
The first thing I noticed was there didn't seem to be any mention of
what profiling package was used to create the destination profiles
used to build the links in the first place. The only mention was of
the source profile used, USWebCoated(SWOP)v2. A few reasons why I
believe this is important:
1) The "quality" or colorimetric accuracy of a device link profile is
somewhat subject to the raw profiles used to build the link in the
first place. I think some initial testing should have been performed
to ascertain what combination of source/destination profiles
introduced the least colorimetric error into the profile chain. I
suppose as long as all the device links were built using the same pair
of source/destination profiles, maybe this point is moot but I can
imagine that some device link applications would perform better using
one pair of source/destination profiles vs. another, even though the
profiles could've been created from the same data set. As noted in the
report, differences of .50 delta E or less are probably meaningless.
In the colorimetric comparison, I think a single max dE is meaningless
as well (a single poor max dE value could be printer variation as much
as the device link). Average dE is OK, but I'd rather see a "worst
10%" value. How a profile conversion handles the 10-20% most difficult
colors/patches would be very telling I think, even more so than
average dE.
2) Ink consumption report. I think it's hardly fair to compare various
device link applications that rely on the destination profile for "ink
savings" (GCR) as opposed to those link apps that can override the
destination profile separation settings. Granted, having the ability
to alter the ink savings/GCR directly within the device link
application is a nice feature but that doesn't necessarily mean that
other device link apps could not have improved upon their ink
consumption figures if the destination profile had used more
"aggressive" GCR settings. I've done a bit of evaluation of ink
savings myself and can tell you that the K generation used in the
destination profile has quite an impact on the resulting ink savings.
But to be fair, the ink savings that result from those device link
apps that offer GCR controls appears to be substantially greater than
those link apps that relay soley on the destination profile's
separation settings, at least in my testing.
3) "Purity" tests. Apparently this was tested using an Epson 4000 as
the output device but using USWebCoated(SWOP)v2 as source. As we all
know, the pure inks of almost any inkjet device that comes to mind can
be anywhere from slightly different to wildly different than an offset
press. Testing the preservation of pure ink colors from an offset
press profile to an inkjet printer would result in fairly extreme
colorimetric errors I would imagine. I fail to see where a test of
preservation of pure ink solids or tints using the parameters outlined
in the report would have any meaning at all. Preservation of pure inks
is really only relevant when repurposing from press-to-press. There's
precious few instances where preserving pure inks from a press to an
inkjet device is desirable.
Other questions:
The author of the report only stated that the conversion was performed
to the "color space of an Epson 4000" via the Apple CMM. Does this
mean the entire test was NOT peformed via a CMYK RIP but was instead
printed via the Epson OS driver? If so, then how was this testing CMYK-
to-CMYK conversions since an Epson 4000 profiled via the driver must
be done in RGB? A better test perhaps would've been to perform this
via a CMYK RIP that had some basic linearization and ink limiting
features but where the conversion itself was performed in Photoshop
instead of the RIP. I can imagine performing such a test with, say, a
ColorBurst RIP or even a GMG RIP which offers excellent calibration
features but can have profile conversions disabled. This would be a
good platform from which to generate very stable/consistent output
from the inkjet printer.
The colorimetric comparisons and "round-tripping" of profiles was
performed using an application not publicly available as far as I
know. Knowing the source of this application, I'd be reasonably sure
that it's a high quality evaluation software but it prevents any sort
of independent verification of the tests results. I'd be much more
comfortable if the author had used "recognized" applications such as
ColorThink Pro, LOGO ColorLab, X-Rite Measure Tool, etc. I would've
preferred that the author had used a more "mainstream" application
rather than a custom application that could've quite possibly
introduced errors of it's own.
Regards,
Terry Wyse
_____________________________
WyseConsul
Color Management Consulting
G7 Certified Expert
email@hidden
704.843.0858
http://www.wyseconsul.com
http://www.colormanagementgroup.com
_______________________________________________
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