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

[Drew Hess]

Nvidia Quadro cards have 10-bit DACs, actually.  I believe the frame
buffer is still 8-bit, though. 

But I agree with Paul that it's best to do color correction with
16-bit FP precision using linear light values, especially if you're
using trilinear interpolation with relatively small 3D textures.  For
the 3 separate LUTs, you'll probably get very similar results with the
gamma ramp functions, although that's less "elegant" since, as Paul
points out, it changes the entire display gamma, not just the color of
the OpenEXR image you're displaying.

d


Paul Schneider <address@hidden> writes:

> 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
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

pgp_Smu8toRrV.pgp
Description: PGP signature