[OpenICC] Oyranos APIs update

[Graeme Gill]

Chris Murphy wrote:

> 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!

That's not a technical problem though, it's an applicaton/user interface
problem. Present the application by default with profiles in the
Editing space category that won't behave in unexpected ways. But don't
stop users who know what they're doing being able to select something else.

> 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.

Right, but there's little logic in having classes Colorspace, Display
and Output either. They're all just (frustratingly slightly) different
ways of representing the same thing, conversions of non-CIE spaces to/from
the CIE based reference space. Far better to have one class, and rely
on other attributes flags to allow human sensible categorization.

> 1. The ICC profile spec defines well behaved editing spaces, and  
> creates a class for them.

You're still assuming that an editing space is an unambiguous thing. I don't
see any reason to think this.

>> 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.

I'm confused about what you're talking about then. You seem to be implying
that an editing space _has_ to be a display profile. Why ? The space someone
wants to manipulate (edit) color in, has nothing to do with the space of
the device they are monitoring the results from. If they're using a CRT,
then they need the profile for that too. If they're using a 6 color laser
projector, they need a profile for that too.

People use photoshops Image "Mode" to switch editing colorspaces all the time,
to best suite their purpose.

> 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.

Not that I can see. I can see only four fundamentally different classes:

PCS to/from non-PCS	"Device" profile
PCS to PCS		"Abstract" profile
non-PCS to non-PCS	"Device link" profile
Name to PCS		"Named color" profile

Why the first is split into 3, I don't know. It could be purely
historical, with Display profiles once being restricted to matrix type etc.,
but once Display profiles were allowed to be Lut type, the reason for
a separate class is hard to fathom.

> 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.

No disagreement that the profiles should be marked with additional information
to classify them into the types of devices etc. It might even be reasonable
to have a "grey balanced" bit that indicates that equal device values will
give you grey etc. What I'm pointing out is that you will often trip across
situations in which there is no logical reason a particular profile can't
be used for a particular purpose, but the CMM implementation won't let you,
because they weren't expecting the profile to be of that class. I've seen
this sort of thing when people try and use one of the sRGB Colorspace
profiles in applications that were expecting an sRGB Display profile.
I think it would be a bad move to make this worse, by trying to introduce
yet another profile class, that is fundamentally just another PCS to/from non-PCS
profile.

Graeme Gill.