Re: Remote proofing
Re: Remote proofing
- Subject: Re: Remote proofing
- From: Henrik Holmegaard <email@hidden>
- Date: Fri, 12 Mar 2004 12:30:47 +0100
On torsdag, mar 11, 2004, at 21:57 Europe/Copenhagen, Roger Breton
wrote:
What is so objectionable about Perceptual rendering when converting
from RGB
to CMYK? And why is that a hindrance for widespread remote proofing
adoption?
The moment you introduce LUTs into text processing and color
processing, you introduce the concept of automating visual adjustments.
This concept is immensely powerful and immensely political, on two
levels.
On the first level you get a conflict between manufacturers over which
flavour of table architecture the market should standardize on.
On the second level you get a professional - non-professional conflict
over the value of the table architecture that manufacturers eventually
standardize on.
The first level conflict was settled by 1996 with the release of the
International Color Consortium Specification the year before and the
OpenType Specification in that same year, after Apple and Microsoft had
failed to agree on GX Typography and Microsoft had failed to carry
TrueType Open forward.
The second level conflict started in the 1995 - 1996 timeframe with the
initial releases from LOGO and ColorBlind, the release of Live Picture
2.5 with ColorSync 2.0 support under John Sculley who had left Apple,
the shift of LinoColor from an RGB editor to a CIE editor (and the
shift of Danish scanner manufacturers to CIE models).
If you talk to the people who shouldered development, support and
marketing in this period there are many stories of the behaviour of
professionals towards non-professionals. Typically, LUT-based
technologies were put down as inferior and work was not infrequently
deliberately destroyed.
The professional would have been apprenticed three to four years to
earn a job, and would be in competition with other professionals to
keep a job. The invisible craft of realising creative intention is
valueless when it is automated, because the value shifts to the
creative intention itself, so the professional opposes the
non-professional.
Sample cases of labour conflicts and technological countermeasures,
(1) The ColorAssistant in LinoColor is designed to make sure that
scanner operators working shifts on production machines scan the same,
which they would not due otherwise as they would tend to keep their
curves to themselves.
(2) A Danish manufacturer of equipment for image designers reported
that customers so often had work intentionally destroyed by scan and
print service color separators that each scnr device had to be shipped
with a printer in order that the image designer had a viewable graphic
to hold the color separator to.
(Essentially we're still doing the same thing when an image designer
feels compelled to have a creative Photoshop project imaged to a
transparency or reflective medium which is then scanned by somebody
else who might just as well have received the tagged TIFF, PDF or PSD
file out of Photoshop.)
Publishing is teamwork and the quality of the publication is only as
high as the quality of the teamwork. The only way to ensure that the
printing process is fed the _right_ CMYK values is to only place RGB /
Lab in InDesign. The fundamental idea of color management is that all
objects in the page geometry share the same ink limit and black
replacement, which is in fact an idea even PostScript Level 1
conceptualizes. Maybe it's time the CIE-based mindset caught up with
the basics -:).
Thanks,
Henrik
_______________________________________________
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.