Following standards (defining device unity profiles)
Following standards (defining device unity profiles)
- Subject: Following standards (defining device unity profiles)
- From: Henrik Holmegaard <email@hidden>
- Date: Fri, 7 Dec 2001 17:25:51 +0100
John Zimmerer <email@hidden> wrote:
The Default profiles that ship with ColorSync are meant to be
default INPUT, not OUTPUT, profiles.
ColorSync requires the Default profiles for RGB, CMYK, LAB and GRAY
in order to convert untagged
images in those spaces to RGB for both onscreen display and printing
(QuickDraw is based on RGB).
To get the channel recipes in an object into the PCS (if the object
is not in the PCS already aka is not in Lab or XYZ), a CIE color
space specification is required. This is true both for existing
untagged data and for NEW data created on the Photoshop canvas or the
page in InDesign and Illustrator. Data recipes only define colors, if
the data recipes are themselves Lab (or XYZ).
Thus to create a CMYK painting in Photoshop 6, I choose a CMYK
profile that defines the colors of the pixels. The profile does not
convert the data recipes, it simply defines their colors. When I edit
the pixel recipes, the new co-ordinates are reported via the CMYK
profile to the PCS. When I select 'Save' the CMYK profile is the
archival space too, and there is no way of knowing whether those
recipes will be sent to a device as is, or further color managed.
With the data recipes linked to PCS co-ordinates, I may add a monitor
profile to the chain. Then the passive profile still does not convert
the CMYK recipes, but is the source and the monitor profile becomes
the destination. The monitor profile then converts PCS co-ordinates
into RGB pixel recipes, so it does something. Or in a RIP I may want
to add a profile for the paper / ink, and the same scenario is
repeated.
It helps to think of the PCS as the hub of a flywheel with two or
three spokes: Source - destination (two) or source - simulation -
destination (three). Draw a circle and place device states described
in device profiles: Monitor state1, Monitor state2 ... Scanner
state1, Scanner state2 ... Press state1, Press state2 ... Printer
state1, printer state2. If the flywheel is turned, the device states
/ device profiles become source and simulation and destination
INDEPENDENTLY of their device type. For instance, in the Output popup
I may choose both type prtr and type mntr profiles, but not type scnr
profiles which is consistent with the ICC specification.
In saying this I should add that the ICC specification establishes
the device types, but does not require them all to be capable of
functioning both as source and destination.
An input profile is defined as a type 'scnr' scanner or digital
camera profile. This type of profile is only required to have an A2B
direction and thus is only required to be a source, but there is in
theory no reason why somebody might not want to dream up an
application for using it as destination and adding a B2A direction.
An output profile is a type 'prtr' or 'mntr' profile, because when
the profile chain is set up the scanner profile does the A2B
conversion into the PCS, the printer profile does the B2A conversion
into the printer space and the A2B conversion into the PCS, and the
monitor profile does the B2A conversion into the monitor space. If a
proofer profile is added then it does a B2A conversion.
I always found the alphabetical system logical, when it is remembered
that the ICC fathers had loose scans in mind. For page assembly I
hope the InDesign 2.0 team manages to apply what we have been waiting
for in a smooth and functioning implementation.
What I tried to say in the June ICC user group feedback thread (the
part circulated off-line), is that the Apple UI fatally misconceives
what is what in an ICC profile chain. The consequence of this
misconception is that Apple has pressed for third party developers to
implement the ColorSync Workflow functionality without grasping the
importance of defining STANDARDS-BASED unity profiles. Because the
unity profiles are the spaces data is created in. And for many many
users this also means the space data is output in.
If I have made a mistake in this analysis, then I apologize to Apple
and will learn from those who understand this better, because there
are many who do. And if I have not made a mistake, then I apologize
to Adobe whose comments wrt Apple implementations in the past I have
felt and said were too harsh. Because Adobe must now carry the
support for Apple users who choose Generic CMYK Profile as unity
profile / CMYK working space.