[Openicc] Print and monitor Color Pipeline

[Kai-Uwe Behrmann]

Am 28.01.11, 20:03 -0700 schrieb Chris Murphy:
> On Jan 28, 2011, at 6:01 PM, Graeme Gill wrote:
>
>> Chris Murphy wrote:
>>> I don't know what Apple is doing differently than other companies, but I'm seeing a wide
>>> assortment of video that has always looked different on various displays (computer and TVs), but
>>> now with the Apple TV and iTunes virtually dead nuts between displays including from a wide gamut
>>> display to a TV. Shocking.
>>
>> Complete control over both the hardware and software.
>> That lets you solve problems.
>
>
> Nooo. Not their displays, and not their television at all. The only 
> thing that's their software and hardware is the AppleTV box itself and 
> the software it runs. The displays are NEC, Mitsubishi and Sony. Somehow 
> they've figured out how all these formats are color encoded and they're 
> doing something that just works.

CompICC works similiar, just on Linux. But Linux means non relyable 
OpenGL support for desktops other than on the specified Apple hardware 
and acompanying drivers. Apple can deploy a relatively robust OpenGL based 
graphics stack.

Missed OpenGL robustness on Linux is in my eyes exactly the reason why 
people blame the OpenGL based Compiz in the first place. 
Distributors want to ship something which "works out of the box"(TM), 
reads no switching depending on underlying hardware or drivers.
Kwin, the KDE window manager, had recently much trouble while deploying a 
different shader language than Compiz for their compositing. However kwin 
circumvents the OpenGL hazzles by making hardware accelerated compositing 
dependend on the actual detected driver and graphics card. The Linux 
distributors have no extra work, so I guess its widely accepted. Still 
it is much extra work for the kwin project. I guess Gnome will enface 
similiar problems while switching to a OpenGL based compositing model for 
Gnome 3.0.

So blaming one window manager for its usage of OpenGL is the wrong target.
Linux needs OpenGL for proper usability!
I have read Android requires OpenGL/ES 1.0 as a basline[1]. Thats smart.


The fast colour conversion in old Photoshop versions is probably highly 
optimised. That would not be easy to repeat with few volunteer 
contributors.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


[1] http://developer.android.com/guide/topics/graphics/opengl.html