[OpenICC] Oyranos APIs update

[Graeme Gill]

Chris Murphy wrote:

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

Class is not a metadata key. Each ICC class has a different combination of
valid tags, and hence different limitations and interpretations for
the same basic purpose.

> If you have just one class, "device" then how do you define for  
> developers the required tags?

The same way you always do. I don't see any issues here. The "Output"
class is basically a superset of all the others. The only point of
contention, would be which conversion directions are mandatory. The
simplest solution to that would be to make both directions mandatory
(making life for profile creation software writers harder), or both
optional (making application writers life harder, or making some profiles
less generally usable.)

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

So LUT's wouldn't be compulsory for any device profile. All that's basically
needed is that the profile define the conversion from PCS to/from the other space
in any manner that ICC supports, Matrix or Lut.

> And for output devices in an ICC paradigm LUTs are required and  matrix 
> tags aren't used.

There's no reason for LUTs to be required, if a matrix model is sufficient.

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

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

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

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

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

The sRGB colorspace vs. sRGB device profile is classic example. There
shouldn't be two ways of doing this, leading to all sorts of strange
results.

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

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

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

Graeme Gill.