[Openicc] Linux CM ideology, was: meta data in test chart

[edmund ronald]

Kai-Uwe,

 When I want to write "Hello World", I don't want to have to choose a
font, a kerning, a color, a background color etc, allocate a buffer,
allocate a graphics port, image into the buffer and then copy onto the
port.
 But yes, many C++ developers think that this should be necessary in
order to "preserve flexibility".
 It maybe necessary to have an API that can do the above, but it
shouldn't be exposed to most people.
 I think many programmers prefer to just do printf("Hello Kai-Uwe");
 In the same way I think that any color model that requires developers
to know what a color space or a rendering is is already dead for most
of them.

Edmund

On Fri, Feb 4, 2011 at 8:44 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 04.02.11, 00:55 +0100 schrieb edmund ronald:
>>
>> Indeed, "a complex mechanism which in the end is completely understood
>> only by the experts." as you say is a good description of the ICC
>> model. In the end it has produced not only a difficult user-model, but
>> also a programming model which is too complex for non-specialist
>> application developers. I would agree that a clean slate approach is
>> not only feasible but also desirable on Linux. In the end, what is
>> there to lose? Speaking for the print side, Gutenprint will continue
>> to put dots on paper whatever the upstream color model happens to be.
>
> To write in analogy, I doubt that users and developers like to go to a
> simplified font format for the goal of having something which is only useful
> for a artifical user group - the masses. It would largely reduce the culture
> of type setting to a one fits all shoe. Contrary, the effort of font engine
> developers went in a quite different direction. APIs where created to
> abstract various font complexity from decidedly naive users
> with the flexibility to deliver more details on demand. That approach
> appears to me quite reasonable.
>
> What we need for colour is not a simplified exchange model, but APIs which
> are able to abstract the colour description models while maintaining their
> flexibility for demanding users. lcms is the API of choice for many
> developers for that purpose currently. We are now in the phase to build on
> top of it and alternative APIs and integrate more deeply into systems to
> provide abstraction layers.
>
>
> kind regards
> Kai-Uwe Behrmann
> --
> developing for colour management www.behrmann.name + www.oyranos.org
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>