[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 28, 2005, at 2:10 PM, Craig Bradney wrote:

> On Wednesday 28 September 2005 21:58, Chris Murphy wrote:
>>
>> Tagging doesn't necessarily mean fully embedding an ICC profile. A
>> simple matrix profile will barely take up 2k of space. But even if
>> that's too much, there needs to be an agreed upon mechanism for
>> supporting color space information, if only by proxy. So either the
>> format is open to more than one color space, in which case it needs
>> to have a mechanism to define the space used; or the format is closed
>> and defines a single supported color space.
>>
>> If people are unwilling to do this, then by definition the format
>> isn't taking color seriously, and trying to second guess that outside
>> of the specifications process for that format is probably a complete
>> waste of time.
>>
>
> It might be worth noting that while all this is wonderfully  
> idealistic, there
> are a LOT of existing graphics files in all kinds of formats that  
> people will
> use and apply formats to. Programs that do or will use CMS or  
> libraries that
> support CMS need to handle these just as well as the rest. You  
> simply cannot
> exclude certain formats from being used by whatever user base, and  
> even if
> they were to convert them to a supporting format, you then must  
> give them the
> ability to supply a profile, assuming they even have an idea what it
> originated from.

I don't totally follow this response. I am not suggesting the  
exclusion of any formats. That's an application developer decision,  
it's certainly not up to me.

But if a format does not allow for the embedding of color space  
information, by definition the program will not be able to handle  
such formats as well as formats that do support color space data  
(either with metadata in the file, or by assumption by specifying a  
space in the format specification or a combination of the two).  
Formats that have absolutely no mechanism for color definition either  
in the file or spec itself demonstrate that they don't take color  
fidelity seriously.

So at that point it becomes something like a game of trivial pursuit  
to find out what space *might* be the most logical to use, and then  
convert data into that space when writing out image data into that  
particular format. But this is a dicey road to go down. Should  
developers provide an interface for users to select a destination  
profile for such a format? I think that is an advanced option, not  
one developers are required to do unless their users want it. The big  
beef I have is with formats that neither allow color space metadata  
in their formats, nor propose a default or assumed space in their  
specification.

I encourage application developers who choose to support such formats  
to have a UI element that flags the user to the fact color space data  
will be lost.


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)