• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Following standards (defining device unity profiles)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Prev by Date: Following standards (naming PCS unity profiles)
  • Next by Date: Re: Infering the Lightness Range of a device
  • Previous by thread: Following standards (naming PCS unity profiles)
  • Next by thread: Saving untagged files
  • Index(es):
    • Date
    • Thread