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

[Chris Murphy]

On Jan 27, 2011, at 3:28 PM, Hal V. Engel wrote:

>> 
> 
> GIMP and other "smart" open source applications are already handling the 
> transform to get things into the display color space.  What these don't have 
> at this point, with the exception of CinePaint, is the code to tell CompICC 
> that they will handle this.  What CompICC does is extends CM to everything 
> else on the desktop (IE. all of the dumb apps).  But at least in theory I 
> agree that it would be better to have apps that understand CM use underlaying 
> system level CM support if it is available since this has a number of benefits 
> such as improved performance because it will be using the GPU for this work.  
> CompICC is so new that it will take some time and effort to get 
> everyone/everything on the same page so that this happens.
> 
> The path forward will likely come in stages.
> 
> 1. Get CompICC mature enough that it can be considered production quality.  I 
> think it is fairly close to this now but it does need more testing and perhaps 
> some fixes if that testing finds issues.
> 
> 2. Convert existing CM aware programs to detect the presence of CompICC (or 
> some other similar system level code) and issue an Opt-out.  This is a very 
> simple thing to do to these apps since it leaves the CM code in these apps 
> alone.  Keep in mind that these apps need the non-CompICC CM code path to run 
> correctly on Windows so this will likely not be removed in the foreseeable 
> future.
> 
> 3. As the work can be done convert CM smart apps to use the system level CM 
> path for screen output.  This will take some effort and likely will not happen 
> until everyone is convinced that CompICC (or similar) is mature.  Also these 
> apps will need to retain the non-CompICC CM code path for other OSes like 
> Windows. 

This is all very helpful and I can appreciate the need to roll out in stages, although boy would be it be great to abbreviate some of it, just to avoid duplicative engineering efforts.

For what it's worth, originally for Windows Vista, the idea was to have a legacy pipeline for legacy applications, and a new pipeline. Where they converged was a 32bpc scRGB based compositing space which then was converted to whatever maximum bitdepth (integer) and color space was supported for the display and its pipeline (video card LUT and physical connection).

I only point this out because they did this in order to get an earlier implementation while maintaining legacy application support for applications that would not directly use the new pipeline (i.e. such apps don't draw in a 32bpc float encoded space, but they still inherit the compositing space by the equivalent of a window server).

So I think perhaps the target audience of engineers are those considering the need for a 32bpc float Rec 709 based compositing space anyway and have them build what they need and repurpose much of it for use at a system level and by X. The top category of development needing such a massive space is video.


> I believe that CompICC is using an OpenGL shader to handle the transforms and 
> OpenGL supports a number of bit depths in the following formats:
> 
> unsigned normalized 2, 4, 8 & 16 bits
> signed normalized 8 & 16 bits
> signed and unsigned integral 8, 16 & 32 bits
> floating point 16 & 32 bits
> 
> I am not sure which of these CompICC is using but I think it is one of the 
> higher bit depth formats.  In any case this should be at least one of the 16 
> bit formats supported by OpenGL if not one of the 32 bit formats.  With modern 
> GPU hardware I don't think that there is a significant performance penalty for 
> using the high bit depth formats since most of this hardware is highly 
> optimized for 32 bit floats and has been for some time now.   Also all of the 
> 8, 16 and 32 bit formats listed above are REQUIRED and must be supported by 
> all OpenGL systems.
> 
> OpenGl also has direct built in support for sRGB, all other formats are 
> assumed to be linear, but I don't know how useful this is since I am not an 
> expert on OpenGL.   I think CompICC assumes that all RGB values from CM dumb 
> apps are sRGB values.  So the built in sRGB support may make this more 
> efficient.

This all sounds very good. There's clearly an advantage to the composite space being 32bpc float with sRGB primaries. You can throw 16bpc and 32bpc HDR images at it, ProPhoto RGB 16bpc images, composite them all together and display, and have effectively zero meaningful loss of precision or color gamut. And it's invertible, again largely without loss. Very powerful for video and also quite useful for photography (which are in some sense converging markets).



Chris Murphy