Re: Modern-day color spaces
Re: Modern-day color spaces
- Subject: Re: Modern-day color spaces
- From: Quincey Morris <email@hidden>
- Date: Thu, 20 Dec 2012 10:25:20 -0800
(resent because it didn't arrive on the list the first time)
On Dec 18, 2012, at 22:59 , Kyle Sluder <email@hidden> wrote:
> My current understanding is this:
I don't know, but (especially since no one else seems to have jumped in) this has been percolating at the back of my mind. I'm very likely wrong, but let me try to spur some ideas ...
> Since 10.4, Quartz does not support the concept of a device color space
> _at all_. That is to say, you cannot create a bitmap context and assign
> a color space such that drawing RGB(128,0,0) is guaranteed to feed
> RGB(128,0,0) to the graphics hardware.
>
> If you continue to ask for a Device color space, Quartz will instead
> give you a "Generic" color space. The generic color space is described
> in QA 1396 and an email to the quartz-dev mailing list [1] as an
> ICC-based color profile that represents the "gold standard" to which
> Apple monitors strived in 2005 […]
The way I interpret the language you refer to is that prior to 10.4 there used to be two display-related color spaces: (1) a device-dependent color-managed space (CG "user default"); (2) an unmanaged space that just passed color components through (CG "device").
In 10.4, both of these turned into (3) a device-independent color-managed space (CG "generic").
> The AppKit release notes for 10.4 say the following: [3]
>
> """Calibrated NSColors (those created with colorWithCalibratedRed:..,
> colorWithCalibratedHue:.., or colorWithCalibratedWhite:...) now use
> Quartz generic color spaces, rather than the "display" (aka "device")
> color spaces. For debugging purposes this behavior can be disabled with
> the NSUseGenericColorSpaceForCalibrated default. This is a debugging
> default and will be removed in a future update.
>
> In applications, the proper way to get the device color space behavior
> is to create colors with colorWithDeviceRed:...,
> colorWithDeviceWhite:..., etc.
>
> In many cases, as appropriate, the underlying color for NSColors
> representing colors used in the user interface (for instance, methods
> such as -[NSColor alternateSelectedControlColor]) has been changed to
> device color space."""
>
> I'm trying to rectify this with my understanding of the situation as it
> pertains to Quartz.
I think the words mean different things in the Cocoa world, and it looks like they might also have changed meaning across the 10.3/10.4 boundary. Regardless of the history, the current (2009) Cocoa documentation says: (1a) Cocoa "calibrated" is a device-independent color-managed space; (2a) Cocoa "device" is a device-dependent color-managed space.
Note that (1a) is semantically whacko, because "calibrated" and "device-independent" seem to contradict each other. It starts to make sense if you postulate that prior to 10.4:
(1a) == (1)
(2a) == (2)
and after 10.4 arrived:
(1a) == (3)
(2a) == (1) **
Why would the terminology flop around like this? I assume because prior to 10.4 "calibrated" was the normal choice, and 10.4 wanted existing apps to get the new normal behavior. So they changed the behavior, not the names.
** Or perhaps:
(2a) == (3)
It wouldn't be surprising if the Cocoa distinction collapsed the same way the CG distinction did. But the release notes make sense, and the documentation is accurate, only if you buy into my first suggestion. But then which display does it represent? (System Preferences allows a different profile for each display.)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden