[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 29, 2005, at 6:55 PM, Graeme Gill wrote:

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

I'm reasonably sure I know what I'm doing, and yet there is no reason  
under the sun I can think of why I would legitimately need to select  
ProPhoto RGB as my display profile!


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

For one, the class designation is just a metadata key and whether  
it's display or output is a possible value. Depending on the class  
value, there is a contingent minimum required tags list. Why do you  
see it as something more grandiose than that?

If you have just one class, "device" then how do you define for  
developers the required tags? Contingent on some other tag value  
presumably? Not all display profiles are LUT based, so LUTs aren't  
required for display profiles, but you need either a LUT or a matrix.  
And for output devices in an ICC paradigm LUTs are required and  
matrix tags aren't used.

I think your idea rearranges the deck chairs. It doesn't really make  
a fundamental change.

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

And you're assuming that it's ambiguous, yet you're providing no  
compelling evidence that it is, just that it might be someday to  
someone somewhere. An integer based RGB editing space is pretty darn  
unambiguous.


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

In practice all RGB editing spaces are display class profiles. I'm  
not implying it, it's a fact, and it's one I don't like.

What makes for a good RGB editing space is vastly more  
straightforward than what makes for a good CMYK editing space.


> 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 think the idea was to let the CMS make these decisions so that  
unsophisticated developers could still implement color management  
into their applications, and not become experts at parsing the guts  
of ICC profiles.

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

I see the profile class as merely metadata for parsing purposes,  
nothing more. You see it as something that ought to have more meaning.

RGB editing spaces aren't really display profiles and yet all of them  
claim that they are. It's a bogus claim, that screws up the ability  
to filter profiles effectively which is a necessary developer and  
user function. The most logical *existing* class is colorspace.  
That's why I mentioned it.


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)