Re: [Openexr-devel] Negative pixels and gamma math issues on half16

[Lars Borg]

Yes, gamma is better than linear for user interface color pickers.

for e-srgb see for example

http://www.morgan-multimedia.com/M-JPEG2000/SDK/group___color_space_i_d.html#ga19

Lars

At 9:11 AM +0200 7/8/05, Christophe Lorenz wrote:

> Thanks for your feedback !
>
> There's more in gamma than working with integer systems...
> If you consider color corrections, gamma tweaking is a basic tool to
> work with.
> It is a different story than the one we are used to with linear
> encoded images.
> Here we don't want to mimic real life light, but we want to alter
> reality. And any trick is welcome here ;-)
> So we input float and output float... We don't want the grader to clip
> all the nice float images to a LDR image. :-o
> The negative pixel values still can find some use later on, so we want
> to keep them.
>
> You're probably right regarding the half-float precision around zero,
> there's no need for a linear area over there.
> I'll do some tests and check that.
> And it is true that I can simply mirror the gamma curve below zero...
> I don't understand why I didn't thought about that ....

The e-sRGB curve is quite nice... Do you have more information on how that curve is built ? I don't see much on that on the web...

Chris.





gary demos wrote:

I believe that the only time gamma is needed is for interoperation with gamma-based integer
 systems.  For such interoperation, 0.0 will mean black which is no light at all.  Negative
 values would then be clipped to 0.0 in floating, which will map to 0 (or 16 or 64) in
 integer pixel values.  There is no meaning defined below the black value of integer
 pixel systems.  I believe it is best not to use anything below the black value of
 an integer system.

-Gary Demos

Lars Borg wrote:

Re: [Openexr-devel] Negative pixels and gamma math issues

I would rather expect you to do the opposite: A linear segment near 0 and gamma otherwise.

Fractional gamma is not a problem: Just treat values as positive.

For an example, see how the e-sRGB curves are constructed.

Also, do you really need a flat section when you're using float encoding?

The half-float should have enough dynamic range around 0 for using gamma through the entire curve.

(e-sRGB uses an integer encoding so a flat section is needed to save on bit depth.)

Lars Borg

Adobe

At 10:22 AM +0200 7/7/05, Christophe Lorenz wrote:

I'm just curious how you guys get around that problem....

We have to apply gamma correction on linear images in half16 format....
The issue is of course that powers of negative numbers with fractionnal exponents isn't always possible...
The other thing is that even if a power of 2 is always possible, the curve flattens at zero and goes up again.
This is typically not an issue when displaying an image because the values are clamped anyhow...

But because we do colorgrading, we want to keep the information present across the whole range, even after applying a gamma correction. (otherwise we end up with range clamped between 0-1)
We also want to avoid the flat part around 0, but keep the curve close to a real power function.

We ended up doing a special gamma function that has 2 linear parts at 0 and 1 and smoothly blend with the real gamma on a 0.1 range.
Then, below 0 and above 1, the linear function is used.
(this is similar to what the broadcast tv guys are doing in the low lights)

Has anyone faced the same issue ?

Chris.

--
Lorenz Christophe - R&D
ACE Digital House
Schiphollaan 2 - 1140 Brussels - Belgium
T: +32 2 735 60 20    F: +32 2 734 09 63
http://www.ace-postproduction.com

This e-mail and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify me at (32)2 735 60 20 and permanently delete the original copy and any copy of any e-mail, and any printout thereof.

_______________________________________________
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
 

>
> --
> Lorenz Christophe - R&D
> ACE Digital House
> Schiphollaan 2 - 1140 Brussels - Belgium
> T: +32 2 735 60 20    F: +32 2 734 09 63
> http://www.ace-postproduction.com
>
> This e-mail and any attachments thereto, is intended only for use by
> the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended recipient
> of this e-mail, you are hereby notified that any dissemination,
> distribution or copying of this email and any attachments thereto, is
> strictly prohibited. If you receive this email in error please
> immediately notify me at (32)2 735 60 20 and permanently delete the
> original copy and any copy of any e-mail, and any printout
> thereof.