Re: Remote proofing
Re: Remote proofing
- Subject: Re: Remote proofing
- From: bruce fraser <email@hidden>
- Date: Sat, 13 Mar 2004 12:52:57 -0800
At 9:09 PM +0100 3/13/04, Henrik Holmegaard wrote:
bruce fraser <email@hidden> writes :
Ink limits, certainly, but black replacement most certainly not.
Black replacement is as much an image-specific concern as a
process-specific one. Simple, real world example. Screen shots
absolutely need a heavy black generation. Most natural images will
actually be hurt by a heavy black generation, particularly ones with
dark saturated colors.
The screenshots in my copy of Stefan, Dietmar and Liane's
PostScriptum have a nice magenta cast, which was an excellent reason
for not printing the cookbooks. But other than that I'd want better
black replacement and better press control systems long before I
even so much as began to think about multiple destination spaces.
Don't think multiple destination spaces-think flexible KGen. It's not
just the gray balance that makes screen shots demand Max K, it's also
the ability to make small black type readable, and it's more
necessary on a press with wobbly registration than on one that
behaves exquisitely.
You cannot have your cake and eat it, too.
That is a totally unacceptable way to try to wriggle out of the real
needs of print manufacturers.
The #1 issue that print providers have with RGB workflows is the
current difficulty of ensuring that things like black text and black
drop shadows separate as K-only. That's a document structuring issue
rather than a color management one, and it's being worked on.
The #2 issue that print providers have with RGB workflows is the
inflexibility of KGen. KGen is not merely a process-specific issue.
Yes, each process has a range of black replacement that will produce
bad results when you go outside that range, but KGen is also very
much an image-specific issue.
An image of silverware on a white lace tablecloth wil benefit from a
fairly heavy black plate. An image of chocolates, or dark leathers,
or a city skyline at night, will be killed by that same fairly heavy
black plate.
It's just silly to pretend that a single static profile is adequate
for press characterization for the purpose of making color
separations. You can use a single static profile for proofing
already-separated content, but not for creating high-quality
separations of diverse image content. This is something every scanner
operator learns by day 2.
I'm far from being the only person who has this concern. It's shared
by all the trade printers and all the high-end separation houses I've
ever talked to, and if color management is ever going to be embraced,
rather than barely accepted with ill grace, by those communities,
it's an issue that needs to be addressed, not swept under the rug.
It's entirely up to you whether you want to be part of the solution
or part of the problem. But I know which side evangelizing a workflow
that creates pink dialog boxes puts you on from my perspective. If
color management is going to work for content of higher quality than
blowaway cards or supermarket inserts, flexibility in KGen is vital.
Next to this, the rendering intent issue (which is still real) pales
into insignificance.
--
email@hidden
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.