<p>Linear vs log(arithmic) are shapes of curves. Floating point and integer are data types, I.e., different approaches to storing numbers on silicon. 32bit vs 16bit is bit depth, or how precise a number can be.  These concepts are each independent of each other; your data can be any combination of curve, type, and depth.</p>
<p>Light in the physical world behaves linearly; if you combine two sources with exactly the same output, you get twice the number of photons.</p>
<p>But human vision doesn’t work that way, which is why shining two identical spotlights on the same target doesn’t appear doubly-bright. AND, the more spotlights you add, the less you’ll notice.</p>
<p>Human vision is extremely complex and doesn’t map perfectly to any mathematical model, but computer scientists try to approximate it when data optimization is critical.</p>
<p>So, while light in the real world goes from zero to infinity, the pixels on your screen might only go from zero to 255.  If that’s the case, developers get more bang for their buck by biasing the numbers to represent more change where it’s less noticeable, and more subtle change where people are more perceptive.</p>
<p>This practice was born of necessity, as older technology had lower bit depth, and couldn’t (or wasn’t practical) to represent as many discreet values as is possible today.  As display, storage, processing, transmission, and compression become more efficient, the resulting image becomes more “HDR.”  As this trend continues, the need to convert between log and linear gammas diminishes.  One day, displays might be nearly linear, at least through the range of human perception.</p>
<p>So as bit depth becomes more of a thing, gamma curves become less of a thing.</p>
<p>Whether you use floating points or integers to store and process a number is more of computer science question; you can store either log or linear curves of lower or higher bit depth in both floating point or integer data types.</p>
<p>A “floating point” in my naive understanding of the computer science term is sort of like a “sliding scale.”  You basically re-purpose some of the numbers’ digits as an exponent.  It makes sense for data that needs an exponent (nits), but less for data which doesn’t (code values).</p>
<p>But in the context of DaVinci Resolve, “32bit Floating Point” refers to the internal processing precision that Resolve uses to approximate (reasonably) the linear mathematical behavior of physical light.</p>
<p>Similarly, “Linear RAW” refers to unmodified, bare sensor data, which is naturally linear, but varies in constitution between camera vendors, and usually ranges between 12 to 16 bits.</p>
<p>The terms are similar because they both refer to linear, physical light, but Resolve’s own internal calculations otherwise bear no correspondence with camera manufacturers’ external RAW data.</p>

CC BY-SA 4.0
2021-09-24T17:47:37.540Z
2021-09-24T19:28:47.237Z
2021-09-24T19:28:47.237Z
Jason Conrad
<p>To explain my confusion I'm going to use an example with a hypothetical sensor which clips at a max 1000% scene linear reflectance and crushes blacks at 0% light (I know there is no such thing as 0% light but it just makes the numbers easier to deal with). I've attached below a hypothetical 10bit Log Transform and a 16bit Linear RAW graph of the Input of Linear Light and Code value output(The so called OETF). The output values are both in Code Value (and Normalized from 0-1)</p>
<p><a href="https://i.sstatic.net/WHlbT.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/WHlbT.jpg" alt="enter image description here" /></a></p>
<p>Now, when the 10bit Log encoded image goes through a Color Space Transform the first thing that happens to it is that it gets &quot;Linearized&quot; to a 32bit Floating Point(this is Davinci Resolve) before any other thing happens to it. Now, I'm not a software developer or video engineer or anything of that sort but having read about Floating Point(which is much more confusing than integer values) it's been said that Floating Point allows for values greater than 1 and less than 0. The problem I'm having is understanding how does this relate to Scene Linear Reflectance getting matched to the output in Linear Floating Point? For instance is 100% light reflectance giving an output of 1(the highest possible value in integers)? Does a 500% reflectance give an output of 5?What about 1000% reflectance, would that be an output of 10 and would the graph end there?? Or am I completely way off and 1000% reflectance would still be an output of 1 just that between 0 and 1 there'd be approximately 4 billion values worth of data.</p>
<p>The thing that's tricking me is that the entire dynamic range of the camera gets squeezed into a 0-1 range in the integer encoded camera files, but I can't understand what's happening with this Linearized 32bit Floating Point. How is this 32bit Floating Point any different than the Linear RAW(Other than it being 32 bit rather than 16 bit?). What's the significance of having values greater than 1 and less than 0? Just very lost on this. Thanks</p>

<color-correction><color><color-grading><colorspace><gamma>
Confusion about Floating Point in Color Space Transforms
user36287
# Confusion about Floating Point in Color Space Transforms

(Asked by: username_0 on 2021-09-22)

To explain my confusion I'm going to use an example with a hypothetical sensor which clips at a max 1000% scene linear reflectance and crushes blacks at 0% light (I know there is no such thing as 0% light but it just makes the numbers easier to deal with). I've attached below a hypothetical 10bit Log Transform and a 16bit Linear RAW graph of the Input of Linear Light and Code value output(The so called OETF). The output values are both in Code Value (and Normalized from 0-1)

[![enter image description here](https://i.sstatic.net/WHlbT.jpg)](https://i.sstatic.net/WHlbT.jpg)

Now, when the 10bit Log encoded image goes through a Color Space Transform the first thing that happens to it is that it gets "Linearized" to a 32bit Floating Point(this is Davinci Resolve) before any other thing happens to it. Now, I'm not a software developer or video engineer or anything of that sort but having read about Floating Point(which is much more confusing than integer values) it's been said that Floating Point allows for values greater than 1 and less than 0. The problem I'm having is understanding how does this relate to Scene Linear Reflectance getting matched to the output in Linear Floating Point? For instance is 100% light reflectance giving an output of 1(the highest possible value in integers)? Does a 500% reflectance give an output of 5?What about 1000% reflectance, would that be an output of 10 and would the graph end there?? Or am I completely way off and 1000% reflectance would still be an output of 1 just that between 0 and 1 there'd be approximately 4 billion values worth of data.

The thing that's tricking me is that the entire dynamic range of the camera gets squeezed into a 0-1 range in the integer encoded camera files, but I can't understand what's happening with this Linearized 32bit Floating Point. How is this 32bit Floating Point any different than the Linear RAW(Other than it being 32 bit rather than 16 bit?). What's the significance of having values greater than 1 and less than 0? Just very lost on this. Thanks

**Tags:** color-correction, color, color-grading, colorspace, gamma


---

## 1 answers

### Answer by username_1 on 2021-09-24. Score: 1

Linear vs log(arithmic) are shapes of curves. Floating point and integer are data types, I.e., different approaches to storing numbers on silicon. 32bit vs 16bit is bit depth, or how precise a number can be. These concepts are each independent of each other; your data can be any combination of curve, type, and depth.

Light in the physical world behaves linearly; if you combine two sources with exactly the same output, you get twice the number of photons.

But human vision doesn’t work that way, which is why shining two identical spotlights on the same target doesn’t appear doubly-bright. AND, the more spotlights you add, the less you’ll notice.

Human vision is extremely complex and doesn’t map perfectly to any mathematical model, but computer scientists try to approximate it when data optimization is critical.

So, while light in the real world goes from zero to infinity, the pixels on your screen might only go from zero to 255. If that’s the case, developers get more bang for their buck by biasing the numbers to represent more change where it’s less noticeable, and more subtle change where people are more perceptive.

This practice was born of necessity, as older technology had lower bit depth, and couldn’t (or wasn’t practical) to represent as many discreet values as is possible today. As display, storage, processing, transmission, and compression become more efficient, the resulting image becomes more “HDR.” As this trend continues, the need to convert between log and linear gammas diminishes. One day, displays might be nearly linear, at least through the range of human perception.

So as bit depth becomes more of a thing, gamma curves become less of a thing.

Whether you use floating points or integers to store and process a number is more of computer science question; you can store either log or linear curves of lower or higher bit depth in both floating point or integer data types.

A “floating point” in my naive understanding of the computer science term is sort of like a “sliding scale.” You basically re-purpose some of the numbers’ digits as an exponent. It makes sense for data that needs an exponent (nits), but less for data which doesn’t (code values).

But in the context of DaVinci Resolve, “32bit Floating Point” refers to the internal processing precision that Resolve uses to approximate (reasonably) the linear mathematical behavior of physical light.

Similarly, “Linear RAW” refers to unmodified, bare sensor data, which is naturally linear, but varies in constitution between camera vendors, and usually ranges between 12 to 16 bits.

The terms are similar because they both refer to linear, physical light, but Resolve’s own internal calculations otherwise bear no correspondence with camera manufacturers’ external RAW data.


---

