<div dir="auto"><a href="https://www.reddit.com/r/vfx/comments/ptk6ej/confusion_about_floating_point_in_color_space/" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.reddit.com/r/vfx/comments/ptk6ej/confusion_about_floating_point_in_color_space/</a><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">well, I think this answer answers it ...</div><div dir="auto"><br></div><div dir="auto">Q first:</div><div dir="auto"><br></div><div dir="auto">=====</div><div dir="auto"><br></div><div dir="auto"><h1>Confusion about Floating Point in Color Space Transforms/Management from 
    </h1>
      
        
    <a href="https://www.reddit.com/r/vfx/?f=flair_name%3A%22Learning%22" target="_blank" rel="noreferrer">
      
    <span style="background-color:#0093ff">
      Learning
    </span>
  
    </a>
  
      
      
      <div dir="auto">
    <div>
    <p>
    Dear VFX Gurus/Professionals, I am not a VFX person at all. My 
question is more from a Color Management standpoint. And seeing how VFX 
artists follow the same rules as colorists(I'm not really a colorist 
either just someone who developed a bit of a hobby recently) in color 
management and equally have to deal with the confusing physics of light,
 I was wondering if you fine people could enlighten me.
  </p><p>
    To explain my confusion I'm going to use an example of a 
hypothetical camera sensor which CLIPS White 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).
  </p><p>
    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><br></p><p>{img omitted}</p><p>     Now, as far as I understood, 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 part of the 
IDT or Input Transform in Davinci Resolve or in the case of  ACES VFX 
workflow, 16bit half float) 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 OUTPUT 
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(then what's the point of having values 
greater than 1 and less than 0?)
  </p><p>
    The thing that's tricking me is that the entire dynamic range of the
 camera gets squeezed into a 0-1 output range in the integer encoded 
camera files, but I can't understand what's happening with it when it 
becomes a Linearized 32bit Floating Point. On the one hand everyone says
 these (ACES Linear Gamma or Davinci Wide Gamut) are HDR workflows but 
the problem is everyone just uses 0 and 1's for their light inputs and 
for their outputs when they're showing the graphs. For all I know an 
Input of 1 could just mean a Reflectance of 100%(just like in Linear 
RGB) or it could mean a 1,000,000% reflectance(Which is indeed 
MEGA-HDR). And what of the outputs potentially being greater than 1 and 
less than 0(What does that even mean?) I'll admit I haven't really tried
 to truly understand Float Point Operations, perhaps that's where I am 
failing.
  </p><p>
    How is this 32bit Floating Point any different than the Linear 
RAW(Other than it being 32 bit Float rather than 16 bit?). Are they 
exactly the same with the only difference being there is an infinitely 
bigger amount of data values between Output 1 and 0(which linearly maps 0
 - 1000% light reflectance)? What's the significance of having Output 
values greater than 1 and less than 0? Just very lost on this. And yes I
 have read multiple articles on this(Chris Brejons, ACES Manual, etc...)
 but the lightbulb isn't turning on for some reason. Feel free to 
correct me since as an amateur I definitely need guidance. Thanks   </p><p><br></p></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">=====</div><div dir="auto"><div dir="auto">
              <div>
    <p>     Welcome to the fun of colorspace. The whole thing is a pain. I've 
set up some facility level color pipelines (camera to broadcast), and 
even when you have a decent grasp of it, it's still basically a 
nightmare.
  </p><p>
    A properly linearized image, rendered to EXR, will show values 
greater than 1, in my example earlier, they'd read 13-16 and everything 
in between. that's what half float (16) and float (32) allow to happen. 
But, and this is a big one, most container formats can't support values 
over 1. So historically LOG images have always been encoded with a LOG 
curve to jam their data into that 0-1 range. So it's important to note 
which colorspace transform has been applied to create the output image. 
Nuke makes it explicit to the format type, Resolve defaults to gamma 2.4
 unless otherwise changed at the project level.
  </p><p>
    The note above about reading in RAW, IIRC, is to make sure all the 
data is pulled in (no clipping) and then the correct colorspace 
transform is applied in app, pushing the super white values above 1. 
This was done for a couple reasons, a) to again keep all the data, and 
b) to allow any legal -> full range expansion before applying the 
colorspace move. It's less prevalent now, but there used to be a 
workflow where the camera SDI was outputting a legal feed, and the 
outboard capture decks were were also applying a full -> legal 
transform, creating master files that were double legalized.
  </p><p>
    A lot of folks still render EXR with the LOG curve applied, so it's 
still technically 0-1 range. This is also the safest way for VFX vendors
 because if we reapply the same log curve on export, when it gets to the
 color house it will be apples to apples the same regardless of how they
 linearize (same as source). In theory the best practice would be to 
linearize the footage and leave it linear, but in reality that's 
problematic, as each software suite uses slightly different math to 
linearize. ACES color management is meant to solve this, but again most 
folks don't actually work in ACES correctly, to be fair most folks don't
 manage color is Resolve correctly either though.
  </p><p>
    Also, I've seen this a few times, depending on where you start, I've
 noticed that some people speak in opposite jargon. IE when they say 
"log" they mean "was log, has been linearized" and when they say 
"linear" they mean flat raw log. When I refer to footage as log I mean 
very flat looking camera native, and when I say linearized I'm referring
 to footage that looks much closer to how we would see it if we were 
there on the day.   </p><p><br></p><p>==== quote end =====</p><p><br></p><p>So .... it seems to be software-dependent what kind of values it can put in fp32 EXRs ....</p>
  </div></div></div></div>