Good afternoon, everyone. I'd like to welcome you to session 118, which is ColorSync. Again, I'm Travis Brown. I'm the Mac OS X imaging technology manager, and I'll be being assisted by the ColorSync engineering team. ColorSync has a new role in Mac OS X, and what's important to note is that it's fundamentally integrated in the operating system. And this is a different story from ColorSync on previous versions of the Mac OS, where it was an optional extension. In fact, many users who were not maybe in the professional publishing space never even bothered to install it or never even knew what it did.

Well, Mac OS X takes the opportunity to integrate ColorSync because color and color management is very, very important to a customer experience, whether it be a high-end publishing customer or even someone using, let's say, a digital camera and trying to look at an image on screen and then print it. For that reason, Quartz takes advantage of ColorSync in great detail. Additionally, it's used throughout the print path to provide color-matching services for printer drivers as well.

Because of this, I want to bracket the sort of content for today's session. We're going to aim some of the content at developers who maybe have never used ColorSync or even may be aware of ColorSync. So we're going to start with an overview of ColorSync. And then we're going to drop down into a fairly detailed discussion of how ColorSync and Quartz interreact to provide a color-managed experience on Mac OS X. Then we're going to come back up a level and talk about profiles and CMMs.

This will be familiar to developers who are used to developing with the ColorSync APIs on Mac OS X and earlier. And then one thing we think is very important is since all applications can share in the color-managed workflow that exists within any Mac OS X system, we feel it's important for developers to take advantage of the preference systems, the preference APIs that are available in Mac OS X, for you to figure out what the user wants in terms of color.

This is something that is going to be very important because you could have, for example, a designer who maybe creates content for the web. And therefore, they want their primary RGB color space to be maybe something like sRGB. And it's very important for application developers to learn how to pick that information up from the system.

Then we'll also talk about device integration where you can associate profiles with devices that are available on the computer. And then we'll conclude with a question and answer. So what I want to do now is turn things over to David Hayward who's going to tell you more, give you an overview of ColorSync.

Good afternoon, everyone. Thanks for coming. Again, I want to start out today talking about a general overview of ColorSync. For those of you in the audience who may not be familiar with color management in general or ColorSync in particular, First thing to be aware of is what is the problem that ColorSync is trying to solve? Well, as we're all aware, there's a wide variety of devices that we all work with these days.

Some of them such as flatbed scanners, digital cameras, LCD displays, tube displays, toner printers, inkjet printers. All of these devices represent colors in very, very different ways. They have different color spaces and also they have different gamuts, which is a term for the range of colors that a device can represent.

So this is the problem that makes it very difficult for a document that's acquired from one device to be rendered correctly on another device or in a printer or a different kind of printer. The solution is ColorSync, which is an established solution that provides a complete color management solution, which is designed to provide consistent color across a wide variety of devices.

Even more than that, though, ColorSync can also be used to do color management or color transformations that are not even associated with devices. Such as hue rotation or contrast enhancement. But for most of the subject we'll be talking about today, you can think of ColorSync as a way of transforming colors from one source device to a destination device.

So that's the problem and the solution. The two key foundations upon which ColorSync are built are ICC profiles and color management modules, or CMMs. I want to talk in a little bit more detail about these two key ingredients. First of all, ICC profiles. The ICC profile is a cross-platform file format defined by the International Color Consortium, or ICC, which is made up of members from 70 different companies.

You can find out more information about them from their website, which is www.color.org. The idea behind the profile format is it's a document that contains data that describes how to transform between device color space and an intermediate color space, or PCS, which is the term that the ICC promotes.

Now, this file format allows for description of a wide variety of devices, but also encompasses several standard color spaces, which you may have worked with, such as sRGB, NTSC, et cetera. The data that's contained in the profile, to a certain extent, implies a certain processing model, but it's also flexible and open.

The profile format can be extended by optional tags, which vendors can take advantage of in order to provide specific solutions for their customers. Also, the ICC profile format is an evolving format. It's ongoing improvements are being made to it. I'll be talking more about that later when we talk about the ICC4 profile format that's on the horizon.

So if you think of profiles as the data that are used for color management, CMMs are the code. And the CMM, or Color Management Module, provides the mathematical engine to perform profile-to-profile transformations. There's a default CMM that Apple ships as part of ColorSync, which is the Apple CMM.

And this is the same CMM that we ship on Mac OS 9 and Mac OS X. However, again, we've designed the system to be open and expandable. Third parties can add their own CMMs if they want to provide their own alternate methods for doing color transformations, and several have been provided in the past by a wide variety of vendors.

So this is a classic diagram to show how ColorSync fits into the Mac OS X architecture. At the top, you have the familiar purple boxes for Carbon and Cocoa applications. These applications can call ColorSync either directly or indirectly by going through other APIs such as QuickDraw and Quartz rendering system. ColorSync can then dynamically call CMMs as needed, either using the Apple CMM or third-party CMMs, and all of this system is based upon the Darwin Foundation provided in Mac OS X.

So that's sort of the architectural overview. Here's a diagram that I wanted to add to give an idea of how color management is actually used in practice, for those of you who are not aware. The idea is, again, you have an application at the top, which is using ColorSync either indirectly or directly.

And what the document wants to do, or the application wants to do, is to render a document correctly. That document, let's say, for example, it comes from a digital camera. The document may contain a profile embedded with it that describes that device's color space. Or it's also possible, if that profile doesn't contain a profile, to obtain a correct profile for that device.

Given a correct profile for that device, we now know how to correctly understand the colors that are represented within that document. Without a profile, those values are just values we don't know how to correctly interpret them. Now, if we want to render this image correctly on the display, then we need a destination profile.

In this case, we need to obtain the profile for the display. Once we have a source and destination profile, now we can match the pixel data from the source or camera profile to the destination or display profile in order to provide the most faithful reproduction of that source image on that destination device.

The story when it comes time to print is very similar. Again, you need a destination profile. In this case, we can obtain a profile from the printer. And again, we can now match from the source to the destination printer profile in order to provide the best, most faithful representation of the image across to print time.

And lastly, just a little bit of a history lesson of ColorSync. ColorSync started back in 1993 in version 1.0 and has grown and become more and more established along the way to version 3.1, which ships today as part of Mac OS X. So it's been an exciting project to be involved with. The ColorSync 2.0 and greater API, which many of you who are familiar with using ColorSync on Mac OS 9, is fully supported on Mac OS X, which means that it should be very, very easy for you to port your applications that are using ColorSync today to Mac OS X.

That being said, there are also some new API and new functionality provided for ColorSync on Mac OS X, which will provide some new enhancements which you may want to take advantage of. And also, what's very, very important is that Quartz and the printing model on Mac OS X make full use of ColorSync, which provides a good segue for me to pass off to Luke Wallis, who will be talking about ColorSync and Quartz. Thanks.

Thank you, David. As you just learned, ColorSync API on Mac OS X is fully implemented. It covers completely the ColorSync API on Mac OS 9. It includes some new features, and it's available for all applications that want to use it. In Mac OS X, however, ColorSync was assigned a new role. Besides the standard application services similar to those on Mac OS 9, ColorSync is now also used to provide color management to other system components. One of those components is Quartz, our new graphics system based on the PDF imaging model.

I would like to show you how ColorSync is used in Quartz. As you are going to see, Quartz created a new paradigm for color management, which offers an alternative access to ColorSync functionality. And if I wanted to be very specific about the topic, I would rephrase it as ColorSync and Quartz Color Management.

The objective for the Quartz color management was to integrate graphics and color management services, satisfying some basic requirements. First of all, Quartz needed an ability to composite different color spaces and opacity. To meet this requirement, ColorSync is used to convert data from many different color spaces into the one selected by Quartz as a working space for compositing.

The second requirement is focused on the needs of developers. It comes from the fact that all applications using Quartz will have to work with color management. A scalable solution, which is implemented in Quartz, should serve the needs of a wide range of applications. On one end, the involvement of an application in color management can be very minimal and just limited to the use of some predefined default settings provided by Quartz. But on the other end, an application will have the same full control over color management as in accessing ColorSync directly.

In simple terms, quartz color management could be described as built around ColorSync, which is used as an engine to process PDF color data produced by quartz. But in order to better understand its design, let's review some of the basic concepts pertaining to color in PDF and ColorSync.

In PDF, color is defined by one of the known color spaces: device, calibrated, or ICC-based. As you can see, this list reflects in essence the history of color management. Initially, only device color spaces were supported. As we can say from today's perspective, those merely provided a classification of different process color models.

And because the color appearance is device-dependent, these spaces are, as a matter of fact, the worst choice for the fateful color reproduction across different devices. Next, calibrated color was invented, along with the idea of color conversions through device-independent color. The advantage of this method is a significant improvement in color matching across different devices. PDF follows that by adding calibrated color spaces.

Later on, calibrated color evolved into the standard form that we here in this crowd are quite familiar with, and this standard form is the ICC profile. When the color management based on ICC profiles gained its popularity and became the de facto standard among color professionals, PDF added ICC-based color space, which allows for embedding ICC profiles in PDF documents. PDF color conversions could be described as a function of source color space, destination color space, and rendering intent.

Please take note of the rendering intent values in PDF as they will refer to the next slide. Let's take a look now how ColorSync and ICC define color and color conversions. Naturally, Color is defined by an ICC profile. As I mentioned a moment ago, the ICC profile is, in practice, the most general form of the color space description.

ICC color conversions are basically very similar to those in PDF. The difference is an option for inserting the intermediate profiles between the source and destination. These additional profiles are used in advanced color management for things like soft proofing, color device simulation, applying special effects, etc. As we can see now, the rendering intent values in ICC are exactly the same as those in PDF.

The color model in Quartz was created by integrating PDF and ICC color models. Let's review some of the most important features of this model. First of all, all PDF color spaces are expressed in Quartz as ICC profiles. Device color spaces are assigned default profiles. Calibrated color spaces contain the calibration record, which can be very easily repackaged as the ICC profile. And finally, ICC-based color spaces provide their own ICC profiles.

Another simple but very important concept that Quartz inherited from PDF is color space equivalence. An implied rule is that color conversions are necessary only if the source color space is different from the destination. Quartz takes advantage of this simple rule to properly organize the flow of color data through multiple rendering stages.

As I mentioned, all PDF color spaces are expressed in Quartz and ICC profile in the manner which is seamless and transparent to all applications working in the PDF imaging model. But at the same time, we needed provision in Quartz to create color transformations from more than two profiles.

For that reason, we designed a color space which can consist of one or more ICC profiles. This way, we are able to preserve the PDF concept of matching a single source to a single destination. But at the same time, we are able to create those complex color transformations which are suitable for advanced color management. And if the need arises for such a color space to be embedded in PDF, the multiple profiles contained in such a color space will be able to be embedded in PDF.

space can be concatenated by color syncing to a single profile. For the completeness, it's worth mentioning that Quartz can also encompass implicit device conversions as defined in PDF by proper configuration of the default color spaces. Here is an example of a configuration handling device gray to device RGB and device CMYK to device RGB conversions.

Let's see now how all the things I was talking about come together to provide the desired color processing in the Quartz drawing model. From the top-level perspective, there are three main components involved in this model: an application generating the graphic contents, Quartz providing the rendering services, and the destination for the rasterized data.

In terms of color processing, the application can request cords to render data in any of the PDF color spaces. To accomplish that, Quartz will convert all these into ICC profiles. The default profiles are selected by Quartz, but can be overloaded by the application. Quartz will do all compositing in the working space.

And ColorSync will be invoked to perform color transformations from any of the source color spaces to the working space. And finally, when compositing is completed, the rasterized data will be sent to the desired destination. Naturally, if the color space of the destination doesn't match the working space, an additional conversion must be done between the working space and the destination.

Here is an example of quartz color management usage. An application creates contents in the device RGB color space. After being rendered, that content should be displayed on the primary monitor without any color conversions. From the color management point of view, we can classify this case as are creating and rendering the data in the same color space. This case can be a typical case of a very simple application which doesn't have any color management capabilities.

If that were the old system and the application opened a file which contained data in different color spaces than device RGB, then the application itself would have to convert the data to the system profile. Otherwise, displaying such data would cause the color errors or perhaps would be even possible at all.

Let's see what happens in Quartz if the application didn't do anything about converting color and pass the data directly to Quartz. As you have seen, all conversions happened correctly in Quartz, and the data from different color spaces is converted properly to the primary display. As a matter of fact, this configuration is a predefined default setting used by Quartz. The same configuration could be used by the advanced color applications, which would like to use Quartz only for rendering without any color conversions. Obviously, many other combinations are also possible here.

Let me show you now how convenient quartz color management can be for some other color operations. For example, applying special effects to all data can be very easily achieved by simply adding the abstract profile to the working space. As you can see, all conversions to the working space will include the transformation defined in the abstract profile. Another example could be soft proofing. The only thing we need to do is to add the printer profile to the working space.

And this way, all color corrections defined in the printer profile will be reflected in the working space and consequently shown on the primary display. The use of multi-profile color spaces is not limited to quasi-internals. An application also could use it. Here is an example of an application using this kind of color space to create some kind of free transform color space for some additional color effects.

To complete my story about color management in Quartz, let me tell you how color is handled in printing from Quartz. So far, I was talking about the main flow of the color data from the source to destination. But one more step is possible here. The contents can be spooled in the PDF form for printing, which will be handled by the print center. There is one very important fact about the spooled data. As I pointed out here, all color data is tagged in spooled PDF, and all end profiles are assigned to the data exactly the same way as they were for ColorSync processing.

Quartz is also used to rasterize this pooled PDF at the printing backend. From the color management perspective, we have a few options here. The first one is to use ColorSync for color matching. In this case, the working space is created from a printer profile and a special kind of working space profile. This working space profile has a gamut large enough to contain the gamut of the printer profile, but at the same time has all the features needed by Quartz for compositing.

The reason for adding the printer profile is to assure that all data tagged with different rendering intents in the spooled PDF will be rendered according to the corresponding tags contained in the printer profile. When the rendering is completed, the PrintJobManager will convert the data from the working space to the printer profile.

Another option is custom driver color matching. By assumption, our goal here is to provide the best WYSIWYG experience. For that reason, the color data by design is going to be handed off in the system profile color space. For that reason, working space is set to the system profile. As a result, all data which is tagged with system profiles will remain untouched. and obviously all other color data will be converted by ColorSync to the system profile.

ColorSync is also involved in PostScript backend. From the color management perspective, our goal here is to convert the color spaces containing the spooled PDF to PostScript CSAs. For those of you who are not familiar with the term of PostScript CSA, let me briefly explain that CSA stands for color space array, and it is used in PostScript the same way for containing the calibration record as calibrated spaces in PDF or ICC profiles. Quartz has internal capabilities to convert PDF calibrated color spaces directly to PostScript CSAs. All ICC profiles will be converted to PostScript CSAs using ColorSync. And this concludes my talk on Quartz and ColorSync. So now I'll pass it back to David. Thank you for your attention.

Thanks, Luke. So after that detailed discussion, I want to go back and go into a little bit more detail on the subject of ColorSync profiles and how they work on Mac OS X. As you may be aware from Mac OS 9, profiles are traditionally stored in the Profiles folder within the System folder.

If an application wanted to get access to that folder, it would use the ColorSync API cm get ColorSyncFolderSpec, passing in for the vrefnum constant kSystemDisk, or I forget the other constants that were equivalent to that. But the idea behind it is that would give you the location of the ColorSyncProfiles folder. You could also use find folder, which is an equivalent API.

However, on Mac OS X, one of the key features in Mac OS X is that it's designed from the get-go to be multi-user and network savvy. And for this reason, there's no longer just one location where profiles can be installed. So now there's several locations. First of all, there's a special location inside the system folder, which is system, library, ColorSync, profiles.

And this is where ColorSync stores a few profiles that it needs for critical operations, which it needs even if all the other profiles were to be trashed by users, they could--ColorSync could still work with just these few profiles to a limited extent. This profiles folder is locked and protected, but if you need to get access to be able to read the profiles in this directory, you can get access to this location by--still by calling CM get ColorSync folder spec, but instead you can pass in k system domain for the vrefnum parameter.

The main place where profiles are stored is in library ColorSync profiles. This is where we ship the majority of our profiles. This location is actually read and writable by users, so your application or users can install profiles in here as well. If you need to get access to this location, you can pass in Klocal domain for the read VREFNUM constant. If you're in a network environment and your administrator has installed profiles on the network for your network devices, these can be installed in the standard location network library ColorSync profiles. You can get access to this by passing in Knetwork domain.

Lastly, users can install their own personal profiles within their home directory, which is in the Unix Parlance Tilda library ColorSync profiles. And as on Mac OS 9, ColorSync also supports looking in subfolders of all of these directories, or aliases to folders, or aliases to profiles. So the end-all situation we have here is there's a lot of locations where profiles can be stored. So what this means is it's probably more important than ever.

If you're an application and you want to present a pop-up menu that shows a list of profiles that are installed to the user, you really want to use the CM Iterate ColorSync Folder API. This API will quickly call a callback proc for every profile that is installed in the system. In addition to simplifying your code from having to deal with all these locations, it also has performance benefits in that it caches the frequently needed information.

One caveat to mention, however, is if you're running Mac OS X and you have a classic system folder set up, ColorSync will not automatically search in the classic system folder's profiles directory. However, if your application wants to get access at this location to show those profiles to your user, you can easily do that by again calling CM_GetColorSyncFolderSpec, and this time you can pass in the k classic domain.

So that's a lot of directories, I know, and it's one of the more common questions we have is, quite simply, where do I install my profiles? And the short answer to the question is, applications should install profiles in library ColorSync profiles or in a subfolder of it. That being said, users can install profiles if they wish in their own home directory.

So what does it mean to be a profile? Well, traditionally, profiles were filtered based on their type and creator on Mac OS 9. The type was prof, and the creator was sync. But in actuality, that's not all that important, because profiles actually come from a variety of sources, and they may not have types and creators. So ColorSync no longer checks the type and creator of profiles.

Also, profiles need not have any suffix, or they may have any suffix. It doesn't matter. But if you are going to have a suffix, we request that you use .icc. By standardizing on one suffix, it makes it easier for applications that are using the Cocoa NS Open Panel to filter profiles.

For the same reason, if you are going to use a type and creator, we'd recommend you use profsync, because that'll make it easier for applications that are using the Carbon Navigation Services to filter profiles. But at its heart, ColorSync doesn't care about type, creator, or suffix. It'll just make life easier for your users.

What really matters that distinguishes a profile from any other file on your disk is that it have the valid ICC profile. And one quick way of determining that is if there's an appropriate offset within the header, there's a signature bytes. Which are ACSP. ColorSync Profile, I believe it stands for.

And that's what really matters, and that's what ColorSync uses to determine if a file is a profile. We also impose the additional restriction that the profile have a valid description tag in it. Because we realize in actual practice, a lot of applications put up pop-up menus or scrolling lists with profiles.

And if a profile has a bad name in it, it can either be rendered as garbage or cause other problems. So in order to avoid this problem, it's more important than ever to use the Profile First Aid ColorSync utility to make sure that the profiles that your application ships or creates are free of common errors. I'll show that a little bit later.

Also, another one of the key features of Mac OS X is that it's, for the first time, it's a multi-localized operating system, which means that a given CD of Mac OS X contains multiple languages on it. We wanted to provide that same functionality for ICC profiles, which previously did not have this support.

So we defined a new optional tag type of type MLUC, which stands for multi-localized Unicode string. And this tag, you can think of it as containing a list of a string, be it the name of the profile or whatever, which has been localized for multiple language and regions. We've also provided an easy API for you to access this data. That's turned out to be tricky in the past.

So first off, there's the API CM copy profile localized string dictionary. And what this API does is allow you to get a CFDictionary which contains the language locale and string for multiple localizations. And it'll return that to you from a specific tag of a given profile. Similarly, there's a CM Set Profile localized string dictionary, which allows you to write a dictionary of localized strings into a tag of a profile.

In more typical practice, however, your application just wants to get one specific name out of a profile. And for that, we have an API, CM Copy Profile Localized String, which you give it a profile, a tag, a requested language and region, and then it will return to you the actual language and region and the actual string.

Here's an example of it being used in practice at the bottom here. It is a CM Copy Profile Localized String. We pass in the prof, the DSCM tag, which is the optional tag where this might be stored. And then, in this case, the application is looking to see a US English string being returned. If that profile does not contain a US English string, it will try to return an English string. If it doesn't do that, it will fall back to a reasonable default.

Another typical usage of this API is if your application doesn't even care what language is being returned, you can pass in nil where the EN-US is passed in here. In this situation, which is very simple to call, the ColorSync will automatically return the best language in the profile, given the user's current preferred language settings.

So, while still talking about profiles, I want to talk for a bit about ICC profiles, which is an important change that's on the horizon. The ICC Consortium has been working long and hard on a new format for profiles in order to provide more flexibility and power, and they're calling it ICC version 4.0 profiles.

I don't want to go into all the details of the changes. You can probably get information on that in more detail on the web, but I just want to give you a few highlights of the changes and what to be aware of. First off, there's obviously a new version field in the header of the profile, so that you can tell whether a profile is a version for a profile or an earlier version.

Also, there's an MD5, or Message Digest, checksum within the profile header, which is a very useful feature if your application wants to be able to tell if two profiles are identical or not, or to tell if a profile has changed over time. You can either access this MD5 checksum directly from the header, 16-byte value, or you can also use the ColorSync API, cm-get-profile-md5. The ColorSync API has the advantage that it works on both ICC4 profiles and earlier profiles, which don't have it embedded in the header.

There's also some new tag data types, which are really where the new power and flexibility come with ICC version 4 profiles. For one thing, they've standardized on the MLUC, or multi-localized Unicode tag, which I spoke about in the previous slide. But also, there's some new multi-dimensional transform tags, or multi-purpose transfer tags, MBA and MAB, that provide a lot of power to profile creators.

The important thing to be aware of is that some of your existing tags that you're used to reading may contain the new data formats, whereas before it contained the old data format. So, for example, if you were to look in the A to B0 tag of a profile, traditionally that used to contain either the MFT1 or MFT2 tag types. But starting with ICC version 4, that data may actually be of a completely different type, which is the MBA or MAB tag. So, the good news is that ColorSync and AppleSync... ...will be fully ICC 4 savvy.

Which means that if your application doesn't do any parsing of profiles, and all it does is open profile references and does color management using those references, or uses ColorSync indirectly through Quartz, then everything will work perfectly. However, if your application is in the business of creating profiles or modifying profiles, you need to be aware of these new tag types and make sure that you handle those cases correctly.

So I want to go into a little bit more detail on CMMs on Mac OS X as well. Like with profiles, CMMs can also be installed in multiple locations. The typical location if an application wanted to install a profile would be in library ColorSync CMMs. I don't know if you've noticed the sort of family here is that a lot of the ColorSync stuff is stored within some library ColorSync directory.

So in this case, it's library ColorSync CMMs. Also, a user, if they had a CMM that they wanted to use just personally but didn't want to force everyone on that machine to use that CMM, they can have a personal CMM installed, which is a great way to debug CMMs, by the way, installing it in tilde library ColorSync CMMs.

So what this means is that if you have an application that wants to present a list of CMMs to the user that are available, so that the user can choose a preferred CMM, you want to use the iterateCMM info API. This call will give you information about all the CMMs that are installed in the system, including the default Apple CMM.

If your solution involves building a CMM, there's some things you need to be aware of. The one key thing is that CMMs on Mac OS X are CF bundle-based, whereas on Mac OS X they were component manager-based. So you'll want to take a look at the CFBundle documentation for information on how to package your CMM as a CFBundle.

But for the most part, the CMM will be very familiar to you on Mac OS X. Again, all your entry points that you've supported in the past, CMM open, CMM concat, CMM match bitmap, will all be there. The only difference is that instead of having a component manager wrapper around these entry points, you'll have a CFBundle wrapper around it instead.

The Apple CMM, which we ship as part of Mac OS X, has undergone a lot of work in order to make sure that it is tuned and integrated fully with the core system, and it works fully in that environment. And as such, it has gone to some effort to make sure that it handles all the various profile types and all the different image color spaces correctly.

What this means is that if you're developing your own third-party CMM, and you want it to work in this ColorSync environment, you need to make sure to thoroughly test your CMM under a wide variety of cases. Because if the user chooses your CMM as a default CMM, it will be used throughout the core's imaging model. It's a very powerful feature.

So we've had a lot of talk so far. I want to just do a little bit of a demo here, just to kind of give you a guided tour of where things and how things live on Mac OS X. So first of all, I'm just started out in the root level of the hard drive. I want to go on my Mac OS X volume. I can go into the library, ColorSync directory. And inside here, we have the majority of the profiles that we install. And all of these end in .icc.

There's also a displays profiles folder, which is where profiles that are for actual displays are installed as well. We also have a bunch of example scripts for the ColorSync scripting environment. Not be showing that much today there, but there's a lot of power in there. You might want to investigate those scripts if you're an Apple scripter. Also, if you actually want to know where ColorSync resides, which can be a little tricky, you go into System Library.

Frameworks. Let's see, where are we here? Frameworks. ColorSync is a sub-framework of the application services framework. So you go into application services frameworks, and then there lies ColorSync. And this is where you can find the headers for your browsing. Also, if we go back up a directory, we can also see in the system library path, there's a ColorSync directory where the minimum required set of profiles that Apple needs are installed. We also have plug-ins for our scripting architecture, or Apple scripting architecture here, for various file types.

Also, there's a few applications that ColorSync has installed. One is, if you go into application, Let's see, where's utilities? It's always at the bottom. There is the Where is it? Display Calibrator. This is where our calibrator resides. Currently, it's an application. I can just launch this real quickly. It's very similar to the old display calibrator, although with a slightly more updated look to it. And we can go through and do our typical display calibration set. We'll skip that today.

There's also the ColorSync Utility application, which in the version that ships with Mac OS X today, has within it the functionality of Profile First Aid. I'd actually kind of like to show you a new version of ColorSync Utility that we're working on, which has this plus some more. Let me launch it real quickly.

So as you can see, one of its functionality is Profile First Aid. And so this is familiar. If you've used Profile First Aid in the past, you can hit Verify, and it'll go through and search all the profiles on your disk. Also, however, it has some new modules, one of which is the Profiles module. And this is sort of the beginning of a work in progress.

But what this module does is it's client of the CM Profile Iteration API. So it uses the API to locate all the profiles on the disk and then present them to the user in a variety of fashions. Here we have them all grouped by location. So you can see system library, ColorSync profiles, slash library, ColorSync profiles. We can see all the profiles.

We can see basic information about the profiles that even a novice can understand, the full path, the color space when it was created. We can also, however, as a convenience, group these by different things. If you just want to, say, for example, see where all the CMYK profiles are, you can just check out the CMYK profiles and look at them there. So I'm going to show more of this later, but now I think I'll go back to the slides.

And actually, this provides a good opportunity for me to pass the microphone over to Eric Broadben, who will be talking about ColorSync preferences and supporting APIs. Thanks. Thanks, David. Alright, well I wanted to start out today with a little bit of an overview. Why are we even talking about ColorSync preferences and supporting APIs? Well, here's a view of an application in classic Mac OS and how it interacts with different parts of the system and the user.

Applications, generally speaking, did not have any knowledge of devices on the system. So applications that are doing color management would often want to have an idea of that, so they would present a user interface so that the user could tell them what kinds of devices they would have on their system.

and the application would get some information about that in order to do color management to those devices or from them. Similarly, applications, if they really want to do color management, also sometimes need to understand where data is coming from in documents if there are no profiles. So again, applications would, as part of the user interface, often have parts of it which would allow the user to select a default profile for a color space or something like that.

And this was actually very good. We were encouraged by the fact that applications were starting to do this over the last few years because it meant that they were taking color management seriously and they were putting an effort into their applications to make sure that they did things right.

There was a little bit of a problem though over time where, as more and more applications did this, there were slight differences between the user interfaces and users were becoming... A lot of the power users were not confused, but some of the users were confused about, you know, how come I have to do this in this application and this in this application and the terminology is slightly different. So the end story at that point was that the application would simply call ColorSync to do its color management.

We wanted to provide a better story for both application developers and users. So on Mac OS X, we think we have a more intelligent way of doing this. First of all, ColorSync is aware of devices on Mac OS X, which we'll see. And secondly, we've redesigned our user interface to take advantage of some of this knowledge, so some of the devices are actually reflected in our user interface.

The user interface covers a lot of the data points that the applications use to try to collect from the user. Applications can use the APIs behind these, which we'll talk about, to get the preferences for profiles, incoming default profiles for color spaces, and in some cases, actual profiles for devices, instead of guessing about them. And then the application can go ahead and do what it's good at or what it was designed to do, which is, in this case, image manipulation or something like that, and then call ColorSync the same way as before to do the color management.

So as I said, our preference panel was redesigned. It was introduced in ColorSync 3.0, which shipped on Mac OS 9 first. And it was designed to provide a single point for users to go to to control color in terms of profiles on their system. Also, it allowed us to formalize some of the concepts and terminology that are important for users to understand, so they really understand what color management is about, color devices and color spaces.

And we built it on a model that allows for us to easily add to it in the future in terms of providing more support for new color spaces and new devices. So here's a look at what the new panel looks like on Mac OS X. There's several panes of it, but we're just going to talk about the Profiles pane. It has the first view of this is default profiles for documents.

Documents can contain lots of different types of data. So an application can utilize the fact that this is where users can set up profiles for different color spaces that will be contained in documents. Now, if the data has a profile associated with it, then that takes precedence, but often documents don't have profiles in them.

And this is where the user gets to set up their preferences for what happens when there is no profile associated with the color data. The application can get access to this preference by using the CM/GET default profile by space API. They pass in one of the color space types that are defined in our headers, and they get back a profile reference. And this would be appropriate, obviously, as a source profile. It's a default profile for the colors coming in.

The second view in the Profiles pane is the profiles for standard devices. Here, applications, obviously, many of them that are doing color management want to know where the data is going to and need a profile for that or where it came from if they know that it came from a device.

ColorSync actually will reflect devices that are installed on the user's system into this so that users can see that. Applications can get access to these preferences by calling the CMGetDefaultProfileByUse API, passing in one of the standard use types and again getting back a profile reference. Often this would be a destination profile, but it can still be an input profile. I wanted to give an example of how an application might benefit. I wanted to give an example of how an application might benefit from these APIs in a simple color management example.

I have a sample code which would not compile, obviously, but my match image routine which takes some kind of an image reference which the application can extract information or data from. As I said before, the first thing an application should do when managing color from a document is to find out if there is a profile embedded, or in this case an image. Modern image formats contain containers for profiles, so there are known ways to find out if there is a profile in an image and get it out of there.

If there is one, great. If there is not, well then we can go ahead and use the API CMGetDefaultProfileBySpace. But of course first we need to find out what color space the image is in. Once we complete that, we can go ahead and get a reasonable default source profile for that image.

Once, at that point, we have a source profile, we want to go ahead and get a destination profile. So, let's say we're matching to the display. We can call cmget default profile by use display, cmdisplay use, and get a destination profile. And now we have source and destination. We can do our color management, get the bitmap from the image, and go ahead and match it.

Now, there's a little bit of a caveat here. This code sample would be appropriate for a classic or Carbon application running on Mac OS X. On Mac OS X, as you saw in Luke's presentation, much of the destination color management is done for you. So, you don't really need to do this kind of matching if your application utilizes Quartz. But at least what you should do is be aware of where the data is coming from. And if there's no profile associated with it, you can tag it using our... APIs.

So in summary, in terms of where ColorSync preferences go, all data is now color-managed on Quartz, and your application can really be a full player in the color management story by simply making sure that data is associated with a correct source profile, and if need be, a destination profile. Most applications can simply use these APIs for color management and have the knowledge that they're getting the user's preferences.

A lot of applications will still need to put up their own user interfaces. We don't mean to say that the ColorSync preference panel is the be-all, end-all of what color management is about on the system, but we're hoping that a lot of applications will simply be able to use our preference panel and the APIs behind it. Again, they're extensible. They allow us to add support for future devices and color spaces, and again, they're flexible in that applications can manage color from both a document-centric or device-centric perspective. Speaking of devices, another new feature in ColorSync on Mac OS X is device support.

And on Mac OS X, we have new kernel, new I/O, and new device managers for input display and printing. And this gave us an opportunity to integrate ColorSync with those device managers to allow ColorSync to be aware of actual devices and their profiles. This is very powerful. It was implemented with the following services in general: device registration, profile registration, the notion of defaults for devices and profiles, and notification services, which we'll talk about later.

A little bit more detail on device and profile registration. Again, we rely on the device managers. We built support into them for this. They are the points on the system that understand when devices are attached or removed. They also are the points on the system that can discover profiles for printing. There's a known way to do that.

Display, same thing. The display manager knows how to discover or build device profiles for the display. Then they go ahead and use some ColorSync APIs to tell ColorSync about the device and its profiles. There's register, unregister, and there's CM set device factory profiles. ColorSync makes a distinction between factory profiles and custom profiles, and we'll talk about that a little bit later.

In terms of defaults, we saw that the APIs in the profiles for standard devices and the API reflectors give access to defaults, not just any device profile. And the way this works is that when profiles are registered, one of them is identified as the default for that device.

Over time, a user may change their settings. For example, maybe initially when installing a printer driver, plain paper is a default setting, and then they go ahead and change it to glossy or something like that. The device manager is aware of that and tells us that the default profile has changed. So again, the device managers are the place where these changes are noticed, and they go ahead and notify ColorSync. And then they can use CM Set Default Device if a default device changes, or CM Set Device Default Profile ID if a default profile changes.

So one of the things that this allows for, which we haven't had on Mac OS before, is support for calibration. And this is done because of the data that we have with a profile. Along with the profile, we get an ID, which has to be unique per device, a mode name, which really means under what conditions is this profile used, like plain paper, glossy, transparency, and so on. It's not the name of the profile, it's the name of the condition under which the profile is used, and actually something that's not listed here, but a URL for where the profile is on the system.

And profiles are actually referenced most of the time by ID, so we don't bind with the URL until late in the game when we actually need to do the color management. What this means is that Those profiles can be customized by an application that knows how to do it.

So a calibration application might go ahead and get the factory profiles, ask the user by putting up a list of modes, which mode they want to calibrate for, do their calibration, and then overlay by ID with a new URL, a new profile that's on a different place in the system. And the printer, the print system, or the user, doesn't have to go and set anything else. The calibration application has done this. That new profile will be used when it comes time to do the color management.

So there are some APIs that support this. GetDeviceFactoryProfiles, and then set, we could have called it setDeviceCustomProfiles, but we just called it setDeviceProfiles and setDeviceProfile if the calibration application just wants to do one profile. Up until this point, the APIs in the device support have pretty much been things that just the system would call, but at this point, if a calibration application wants to get involved, it would use these APIs.

Finally, as part of our device support, if applications want to, they can become aware of the changes in devices on their system that the device managers tell us about. ColorSync will post notifications to a distributed center, and by this we just mean that any process on the system can get a notification if it registers with a distributed center.

Some of the things you can get notified for are changes to a default device for a device class if the user plugs in a new printer and sets it as their default printer or something like that. There's a notification for that. Changes to factory or custom profiles, changes to a default profile, and registration and unregistration. There are no ColorSync APIs for this because we don't actually support notification per se.

We post notifications through the services available, and an application needs to register with them through either Core Foundation or Cocoa. So go ahead and look at those APIs if you're interested in that. You will need to look in the ColorSync headers for the notification strings that you register for.

So in summary, we've integrated on Mac OS X with device managers. This gives us some new features and some new integration. Applications have access to default profiles simply through our preferences APIs. Applications can actually get more specific profile information if they want using some new APIs. Calibration is supported because of the way we register and deal with profiles on the system. And finally, applications can get notified of these changes.

Speaking of which, I believe we have a demo, David, of an application which will take advantage of this. Thanks, Eric. Okay, so switching to... So as I left you wondering about before, we have this Devices button in the ColorSync Utility module. And what this module is, is it's a client of the device integration API.

And what it'll do is it'll show you a list of all the devices that have registered profiles on this system. And what I have here is we have different classes of devices, general classes, scanners, cameras, displays, printers, proofers. And there's one display registered. Also, for purposes of demoing, I've registered two cameras as well. If we look at the--we have two cameras.

For each of these cameras, there's two different modes associated with it. If I click on the indoor mode, it will show what the factory profile for that is, which in this case just defaults to sRGB. And there's also an additional profile if it's been overridden by the user or by a calibrator. And there's a second profile for that as well. So we're going to have different device classes, different devices, and different modes within a given device.

So this application is kind of nice because it allows you in one spot to be able to browse the list of ColorSync-savvy devices on the system. We can also change what the profile is here. If we don't have a specific calibrator, we could create our own calibrated profile and just associate that profile with this device if we wish. And it'll be used automatically. Also, we have the display here, which also has a profile associated with it.

This is the profile that was generated automatically when the system is booted. So it's based on information returned from the EDID. But if I actually go into the system control panel, system preferences, go to displays, and go to the color tab. This also shows me the same profile.

So we have two different clients of the same database, if you want to think of it. Now, one other thing about this application is it's registered that it wants to receive notifications of any changes. So if I go to this tab here and change the profile to Multiscan 17 for some reason, you'll see that in the background, this app has already received that notification and it's already been updated.

If I flip it back. Also, if I were to go and calibrate and go through the process of calibrating the display, again, this is--the profile for this display would be changed and it would be reflected in this database. So this is really powerful. It allows applications in a standardized way to calibrate a wide variety of devices and for the users to get the best possible color out of their--out of their individual devices. Another way of kind of demonstrating this is we have a printer we've hooked up here that registers for profiles.

If I just go in here and plug it in, USB, excuse me, bring this app to front and then go to print center. A little bit of a beach ball. It's automatically recognized the printer, and as you can see, let's see, did it register? Oops. Let me delete it, quit it, and launch it again.

Sorry about that. No, it's decided to be honorary. This was working earlier, I swear. Okay, well, that's a good demo without something not working as expected. But anyhow, you can see we're receiving notifications for the different devices and they'll be registered automatically. The real advantage of this is by having a device that registers for profiles, registers its profiles, it allows a savvy user of your device to be able to query to see that device's profiles and also to be able to calibrate that to be able to get the best possible results out of that device.

So I think that's it for now. We have a minor mystery of why it didn't Oh, look, it's back. I needed to relaunch. Sorry about that. So here we see the Stylus Color 880 coming up and registering no less than, I believe, eight different profiles, all slightly different for different print modes.

I think they could be named slightly differently, but it's really great that they're registering all these modes. We can also change which one is the default mode for this printer. If we had multiple printers, we could check which one is the default printer. All right, that's it for now.

So as always, where to go for more information? If you're more interested in getting more detailed information, you can go get information on ColorSync from www.apple.com/colorsync or the SDK site as well. Also, I always make a pitch for the ColorSync dev and ColorSync users list. There's a lot of great information there as well. And feedback can be sent to [email protected].

and I'll pass it over to Travis for a few more words. Thank you, David. I want to just quickly go through the roadmap of the remaining graphic sessions here at WWDC. We have 1.13, which is text on Mac OS X, which is very important if you're interested in doing advanced text drawing on X and also text drawing in conjunction with Quartz.

We have another interesting session, which is OpenGL High Performance 2D. If you're looking to do some 2D graphics and make them go very, very fast, there's some interesting applications of OpenGL to do that. We also have a printing session, which is on Thursday, which will cover Mac OS X printing tips for Carbon, Cocoa and also some BSD.

Then we also have on Friday a very important talk, if you're a Carbon developer, where we have the graphics and imaging tips and tricks, where we'll go over quite extensively issues such as QuickDraw and Quartz integration, in addition to talking about the optimization of graphics in general by working in conjunction with Quartz Compositor.

This is the contact information. I can be reached if you have any questions about ColorSync. You can reach me at travisb.apple.com. We also have a product manager for ColorSync technology, who's John Zimmer. If you have any suggestions on how ColorSync can be improved, feel free to email John. He's available at johnz.apple.com.