Re: [Openexr-devel] Introduction and CTL/ICC question

[Paul Schneider]

Hi, Kai-Uwe,

it depends on what kind of color management you want to do.  The 
framebuffer doesn't have access to any pixel values outside of the 
0-1.0 range, so if you perform an adjustment that darkens the image, 
you will clip rather than pulling superwhite pixels into the 0-1 range.

Also, although most APIs allow you to pass a 16-bit or float ramp for 
future-proofing, I believe that almost all video cards only implement 
an 8-bit ramp (at least in 32-bit display mode).  I don't think there's 
any point to having a gamma ramp bigger than 8 bits when your video 
buffer is only 8 bit.  So, you'd have to watch for quantization, as 
well.  I could be wrong about this, though.

In other words, I think you'd run into the same limitations as the 
current ICC implementation with a gamma-ramp approach, even if you were 
just correcting for display.  You don't have these problems if you 
manipulate floating-point data in OpenGL.  It could be that I 
misunderstand your intentions, though.

If you want to manipulate the gamma ramp on an OS X machine, check out 
CGDirectDisplay.h: specifically, CGSetDisplayTransferByFormula() and 
CGSetDisplayTransferByTable().  I've used these with success in the 
past.

Good luck!
- Paul



On Mar 10, 2005, at 12:44 AM, Kai-Uwe Behrmann wrote:

> Am 10.03.05, 00:11 -0800 schrieb Paul Schneider:
>
> > Yes, XF86VidModeSetGammaRamp is an X-Windows API.  There is an 
> > equivalent API
> > for OS X.  See CGDirectDisplay.h and friends.
> >
> > However, this routine adjusts the gamma ramp of your video card, 
> > which 1)
> > affects the entire monitor and 2) only operates on the 8-bit data in 
> > the video
>
> For screen colour managament this is quite ok. It leads to more
> consistency, what I want to figure out. Beside that, at least
> XF86VidModeSetGammaRamp supports as well more than 8 bit as provided by
> hardware. Graeme Gill pointed out.
>
> > framebuffer.  You'll lose a lot of precision if you're trying to 
> > manipulate
> > floating-point data like this.
>
> You mean for manipulation of floating point data an integer ramp is
> incompatible. Seems reasonable. Maybe I did not understood what the 
> ramps
> was meant to do - display correction or manipulation with later saving 
> to
> file.
>
> regards
> Kai-Uwe Behrmann
>                                 + development for color management
>                                 + imaging / panoramas
>                                 + email: address@hidden
>                                 + http://www.behrmann.name
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel