[Openicc] Print and monitor Color Pipeline

[Chris Murphy]

BTW, Photoshop has been doing display compensation in real time on comparatively piss poor hardware with no discernible performance lag since Photoshop 5, which was released in 1998.

Now video is another matter. But color handling in video I think is pretty f'd up, mostly because of its analog roots. But now we appear to have a lot of very unclear specifications on how color is supposed to be encoded when there are conflicts between codec and wrappers and players, and display technologies, etc. 

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. 

Chris Murphy


On Jan 28, 2011, at 1:22 PM, Jan-Peter Homann wrote:

> Hello Hal and all.
> 
> If you are able to render a bitmap with usage of ICC-profiles to the monitor, you are alo able to render a bitmap for a color managed print out.
> 
> Did I missed something ?
> 
> Best regards
> Jan-Peter
> 
> 
> Am 27.01.11 01:47, schrieb Hal V. Engel:
>> On Wednesday, January 26, 2011 02:05:56 pm Jan-Peter Homann wrote:
>>> Technically different ways for rendering data to the monitor and to the
>>> print out does not make sense in my eyes.
>> There is some technical difference that needs to be kept in mind.
>> 
>> 1. Monitor output is happening in real time and for some applications may be
>> happening at high frame rates.   In some cases like a photo editor the real
>> time requirement has a major impact on usability (IE. you don't want to wait
>> too long for a manipulation to the photo to be rendered by the editing
>> software).  Print output never happens in real time and is never something
>> that the user directly interacts with.
>> 
>> 2. The overall software stacks are completely different and there are very few,
>> if any,  shared components.