I believe that it is commonly felt that the profile for ISO Web coated
gives a good result for those who print to the ISO 12647-2 spec, which
calls for Ink that conforms to another ISO number (ISO 2846-1 I
believe).
I saw that there was a point raised earlier making a reference to the
proof4press specification (PPA) which is based on a Dupont "curve" for
one of their devices called Euro Offset DP10. Calibrated proofs created
by Dupont devices with this curve are accepted by Magazine Publishers
in the UK as a de-facto proofing standard.
In conversations with web-offset printers in the UK, most claim to use
the ISO ink sets, which makes it possible for them to print to the ISO
12637-2 spec. I have seen a report created by an "independant" saying
that this Dupont "curve" is a good representation of ISO 12647-2, but I
don't believe it. I have a suspicion that this Dupont "curve" is based
on a different ink set called "European Colour Scale" (DIN 16539 I
believe), and not the ISO Ink set.
Does anybody know what ink set (or printing condition) the Dupont "Euro
Offset DP10" curve tries to represent ?
Are Inks based on Euroscale still in commercial use today?
Many thanks,
Andy Psarianos
I'm interested in knowing if any one
On 9 Aug 2004, at 16:54, Chris Murphy wrote:
On Aug 5, 2004, at 5:21 PM, Belinda Beckinsale wrote:
If an imposition contains some pages that have
been set using
traditional gray balance (eg 75 65 65 90 etc) and some pages that
have been done using a profile such as the ISO web coated that uses a
very different gray balance, with a lot less yellow, then how is the
printer meant to handle balancing two very different gray balances in
the same sheet?
The problem is being overstated. Downloading the "ISOwebcoated.icc"
profile, Paper type 3, gloss coated web (LWC), 150 lpi (60/cm),
FOGRA28L, from the ECI web site, I get the following conversions for
L*50
SWOPv2, RelCol+BPC, 55, 46, 46, 11
ISOWeb, RelCol+BPC, 44, 35, 34, 28
ISOWeb, Perceptual 41, 32, 32, 23
For L*25 I get:
SWOPv2, RelCol+BPC, 68, 62, 61, 51
ISOWeb, RelCol+BPC, 60, 49, 46, 62
ISOWeb, Perceptual 56, 45, 43, 52
Now when I take 100% yellow, and ask the SWOP v2 profile, and ISO Web
Coated profile what the LAB values are (AbsCol),
I get:
SWOP v2 84, -6, 83
ISO Web 86, -3, 93
That is a huge difference numerically. Simple delta E is 10. Delta E
2000 predicts delta E 3 because it does a better job of understanding
humans aren't that sensitive to saturated colors, in particular
yellow. Still a real delta E of 3 is noticeable, therefore it makes
sense the separation is going to be different because an integral
primary is different. The other primaries are no where near this
different.
So the answers to the question:
1. There is no traditional gray balance.
2. If a printer is receiving jobs with different gray balance, one of
them is wrong, and he will have to either make the right one look
right (good), the wrong one look good (bad), or compromise (maybe good
or bad depending on context).
Moral of the story is that your separations, including gray balance
need to be targeted for the final output process. That means one set
of separations for U.S. publications and another set for Euro. You
need them anyway because the TVI difference is more radical than the 4
point discrepancy in shadow gray balance for yellow compared to
magenta.
This may not be a problem with ISO or SWOP
profiles that have GCR and
aren't really relying on CMY to make neutrals, but what about when
the idea of tailor making your own profiles to suit your press really
takes off, and different separations and black generations get used?
If the measurement data is correct for the printing conditions being
used, even irrespective of paper white, then GCR is not going to
dramatically affect this if the profile is built correctly. The
profile building application should build the proper CMY balance to
produce a neutral regardless of paper white.
Is there perhaps a case for a gray balanced CMYK
'working space'
like there is in RGB? (ie work is done in this space and then
converted to the appropriate press space). This would probably cause
less arguments with scanner operators. Lets face it, the ideal RGB
workflow is still not a workable reality for a lot of pre-press.
I don't see how this could work. There are standard printing
conditions already, and profiles based on their measurement data are
gray balanced. That each one has different gray balance is due to
different inksets being used, primarily, as in this example.
Also, there was a comment earlier that you
don't want to set your
scan range in RGB from 0 to 255 for the same reason that you would
not set it to 0 to 100 for CMYK. I'm just wondering if this is
unecessarily limiting the range of the scan. You don't actually print
the RGB scan, it gets converted to a CMYK profile which would then
handle what can actually be printed from that data (if that makes
sense). Maybe I haven't fully thought through the logic of this, but
any yays or nays would be appreciated.
There are two possibilities. A dumb scanner setup should be set
conservatively so you aren't clipping shadow or highlight detail. This
is the one size fits all approach, constantly scanning with the same
settings. Yes you do lose a few levels with this strategy. Someone is
going to have to set white and black later, in Photoshop for example.
So there is no free lunch here unless you have more skilled Photoshop
operators than you do scanner operators (that is the trend).
The other approach is to set black point and white point in the
scanner software on an image by image basis. This maximizes the
ability of the scanner better, but clearly is more time consuming up
front.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management"
Published by PeachPit Press (ISBN 0-201-77340-6)
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit