[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 29, 2005, at 11:26 PM, Graeme Gill wrote:


> Yes it does, it simplifies the infrastructure, and removes unnecessary
> complication, complication that affects both implementations and  
> interfaces.
>

After reading all of what you wrote, I'm unconvinced. Take a look at  
Microsoft's WCS profile structure and see if it better fits your  
vision. Given that only Microsoft controls it, if you can provide a  
convincing argument for changes to what they currently have, it will  
no doubt occur at a faster pace and with greater likelihood than any  
such changes to the ICC spec.

>
>
>
>> 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.
>>
>>
>
> People use other spaces than RGB in Photoshop all the time
> to edit images.
>

I'm very clearly talking about RGB ones. That other spaces can be  
used is obvious. I'm not talking about those.


> That (and there being no technical reason
> compelling image editing in RGB spaces) is sufficient for me
> to know that editing spaces don't have to be well behaved RGB spaces,
> even though it may be often desirable for many people.
>

Actually there are numerous technically compelling reasons to edit  
images in RGB and there are a number of books on the subject, and  
experts in image editing who have demonstrated it better than I can.  
But this is totally beside the point. The characteristics of an  
integer based RGB editing space aren't ambiguous.



>
>
>
>> 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.
>>
>>
>
> The fact that you can edit in CMYK or Lab in editing applications
> like Photoshop is sufficient evidence to the contrary in my view.
>

Re-read what I wrote. I'm talking only about RGB. Obviously there are  
no CMYK or LAB display class profiles, Graeme. The RGB ones are all  
display class, yet they don't describe a device (display or otherwise).




>
>
>
>> 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.
>>
>>
>
> In my experience, implementing one set of users distinctions deeply  
> into
> technical infrastructure simply for the convenience of one set of
> developers, is the sort of thing that later results in hard to use,
> hard to understand systems, because they behave in odd, unexpected  
> ways.
>

At least with the problem I'm talking about, there was no issue until  
one profile class was usurped for a purpose for which it was not  
intended. And to date neither the ICC, Adobe, Apple nor Microsoft  
have gotten a clue about the resulting problem to the point where  
they've decided to do anything about it.



>
>
>> I see the profile class as merely metadata for parsing purposes,   
>> nothing more. You see it as something that ought to have more  
>> meaning.
>>
>>
>
> It doesn't matter how you see it, it's not the way ICC is formulated.
> ICC profile classes are not metadata, they imply different valid
> combinations of tags, and hence different behaviour. There is almost
> certainly different code paths in CMMs and applications for each  
> different
> profile class. Adding one for editing space, is adding work and  
> complexity.
>

Yet your idea implies different valid combinations of tags and  
behavior as well, but merely dependent on existence, or lack thereof,  
of other metadata. I don't see the advantage, but then I'm not the  
one you have to convince. It would be a cakewalk to convince me  
compared to convincing the ICC.


>
>
>
>> 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.
>>
>>
>
> Many are idealized display spaces, so the distinction is rather fuzzy.
>

Many? I count one in common use (sRGB) and two that aren't  
(ColorMatch RGB and Apple RGB). There are many other RGB editing spaces.


> You're looking for profiles with particular properties (RGB, grey  
> balanced,
> etc.) to be deeply distinguished from other profiles, because for your
> purpose they are especially useful as an editing space.
>

I'm fine with them now, I just don't like UI implementations that  
literally encourage users to do nonsensical things.



>
> I'm saying they are not fundamentally different enough from all other
> PCS to/from Other space conversions to merit such a fundamental  
> distinction,
> and further, that all users would not necessarily agree with your  
> choice
> of editing space characteristics.
>

Anyone who has spent even a week's worth of time editing images would  
clearly get the fundamental distinction between an RGB space that  
isn't gray balanced, or has cross-overs, and one that is well  
behaved. From a profile structure point of view, they're no  
different, but whether one category appears in one list of profiles  
when it makes no sense to do so is a huge fundamental difference.

And pleasing all users is never the goal. Cater to most of them, and  
then offer advanced or undocumented features for the rest if the  
developer has the time. I'm totally disinterested in the concept of  
screwing 90% of end-user's user experience for the 0.01% of the  
market that wants to select ProPhoto RGB as their display profile. I  
can count all of the people who'd want to do that on one hand. And I  
think it's insane to expect such differentiation in profiles to occur  
on operating specific basis, let alone an application specific one.  
It's a recipe for end users and most developers moving to the asylum.


> System configured list of suggested profiles
> would cover your purpose without restricting those with a broader  
> view of desirable
> editing spaces, and without having to add anything new to the  
> profile format.
>

Insufficient.

1. It's a platform specific solution.
2. It doesn't account for newly developed editing spaces.
3. It doesn't account for user installed editing spaces, that didn't  
come with the system's suggested list of profiles.

The profiles themselves must be self-identifying to prevent most  
users from getting into trouble. The "dangerous" option to do what  
you want is an application developer decision, they can always choose  
to have their profile lists display all profiles, whether it makes  
sense or not. They've never been restricted in what profiles they can  
present to the user.


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)