[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 28, 2005, at 7:44 PM, Graeme Gill wrote:

> And a good thing too really. "Editing Space" is a subjective  
> judgement,
> so it shouldn't be encoded as a fundamental type such as profile  
> class.

What makes for an appropriate RGB editing space is not a subjective  
judgement. There are clearly defined characteristics for an editing  
space, the overriding concept is that it isn't based on the behavior  
of any real world device.

Thus far all editing spaces are already encoded exclusively as  
display class profiles even though they are not at all based on the  
actual behavior of a display.

> It's your judgement that useful colorspaces to edit in are grey  
> balanced
> etc., but other users may have different purposes in mind, and not
> need such properties.

Let's hear those different purposes before we further subject  
confusion onto users en mass.

> The correct approach (IMHO) is to categorize
> in the operating system or application, and allow the configurers and
> users to decide which profiles are in the "Editing Space" category.

Yeah, and that's really worked out well! To date the actual  
experience of most end users has demonstrated this approach has been  
nothing short of a disaster. People *routinely* select profiles that  
are not appropriate for editing images in, and wonder why they get  
posterization, and noise in their images, and can't get them to gray  
balance; and other users with less frequently but still utterly  
common is the selection of a wide gamut RGB space as a display profile!

The facts are, the overwhelming majority of end users still don't  
know anything about color management. Those who do know something  
about it aren't sophisticated enough to make this kind of decision.  
The default needs to be safe, and the first level options also need  
to be safe.

If you want to have a hidden but documented method for advanced users  
to walk this path of treachery that's fine, but to subject it onto  
all users of all sorts will sabotage color management implementation  
for the rest of us.


> Some applications may have various implementation limits on
> what they can use as Editing Space (ie. only 3 channels,
> RGB like space etc.), so obviously inappropriate profiles can't
> be used for such a purpose.

The colorspace profile class is seldom used, and I think is a more  
appropriate profile class for these kinds of profiles. They certainly  
are not display profiles, so why put them in that class? Well,  
because the display class profile had certain features available at  
the time of the invention of intermediate RGB spaces, and the  
colorspace class did not. And it takes the ICC nearly half a decade  
to make meaningful progress from the word go. So I understand why  
they are display class, I just don't agree with it. It amounts to a  
hack.

But you're absolutely correct in that the lack of sophistication of  
applications in lieu of this issue is tragic. It's lunacy that in  
2005 Apple's most advanced operating system in the world will allow  
me to see, and choose ProPhoto RGB as a display profile, as though  
it's an on-par option with the rest.

So really the question to present to developers is if it's useful for  
them to have some kind of differentiation between display profiles  
and editing spaces, so they don't have to parse at all or as much to  
test whether they are suitable editing spaces for their users. I  
think most developers would prefer two brute force options:

1. The ICC profile spec defines well behaved editing spaces, and  
creates a class for them.
2. The application can then use that class, and OPTIONALLY allow  
users to select some other space.

Because what happens when people use some wholly inappropriate  
profile as an edit space, they contact the developer, or hassle a  
bunch of their fellow users, or in extreme cases just live with  
inferior image reproduction. It's a waste of everyone's time.

>
>
>> sorting by profile class. But since the display class was usurped   
>> for this purpose, we now have various problems, including that of   
>> user interfaces showing non-device "editing spaces" in lists for   
>> display profiles to select for a particular display! Bad!
>>
>
> Any profile capable of defining a colorspace in relation to CIE space
> should be available. Some people want to edit in CMYK, Lab, HSB etc.

I do not see how this at all relates to the above paragraph you seem  
to be commenting to. It makes no sense to select non-device profiles  
for a display device, let alone selecting a CMYK or LAB profile for a  
display device. No one needs to do that, and any developer doing that  
to their users is sabotaging color management. In fact this is how  
both Windows and Mac OS work today. You can select ProPhoto RGB as  
your display profile, and it does happen with some regularity in the  
wide array of end users I visit. It's a bad experience, a waste of  
time, and totally avoidable.


> [Now I think in fact that the ICC format has to many distinctions  
> without
>  clear purpose. Why class display profiles differently to output  
> profiles ?
>  What is the point of Colorspace conversion profiles ? It's one  
> thing to
>  mark the nature of the device colorspace in the profile, it's  
> another to
>  make it a completely different class. Only 4 or 5 classes are  
> needed.]

Lars probably knows more about the history than I do, but I think  
there were two points behind the different classes. First, most of  
them do very different things in the additional profile classes. The  
basic classes for devices, are more similar to each other in their  
structure and capability, but the class designation is useful  
metadata about the profile for the purpose of easier profile list  
parsing. If you have a "printer profile" pop-up menu it makes no  
sense to list scanner profiles or display profiles. If you have a  
display profile popup menu (before the days where the OS knew what it  
was, and you had to select it manually; or in some implementations  
like QuarkXPress, and Freehand where you *still* have to select one  
manually) it makes no sense to see printer profiles in the list.

It's about making things easier for developers as well as end users.  
And this system broke when something completely different came along  
(edit spaces) and yet claims it's a display profile. It isn't a  
display profile.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)