God no.
I am aware of the limitations of the 16f EXR format and happily stuff that full of log all of the time becasue:
I am not sloppy. I understand the implications and I adapt to suit the format/budget I am working with.
Exactly!
Weāre optimizing several digits past the decimal point hereā¦
And itās not widely talked about. The Flame forum here is the only discussion Iām aware off. Might exist in some other high standard discussions as well. But if you Google it, itās hard to find.
If that is any indication of how worried you should be for the average daily pixel dose.
Iām just a bear of very small brain and my Christopher Robin says linear only - no log in the openEXR container.
So I just do what he says.
If anybody here has a competitive Technical Academy Award, Iāll listen if the bar is open and free.
2065-1 encompasses all that we might ever encode and subsequently display.
SMPTE say that 2065-4 is the only true path because it is 32-bit and uncompressed.
Most mortals cannot currently afford uncompressed 32-bit workflow.
Find a workflow.
End of anecdote.
For internal processing Iām also gobsmacked at how many numbers you might need in a 32-bit log file in order to decode what was linear(integer) and what was 32-bitlog (a 32-bit LUT) - I really am struggling with this concept since the numbers go into the millillillillions - I think @ALan knows?
Some from ADSK must know also since it appears to be used for the MachineLearning TW internal processingā¦
@philm If you look up the definition of 16fp (brought to you by the bright people of ILM originally apparently):
There largest value that can be stored is 65504 (plenty, since most HDR RGB values top out in the teens).
The smallest value that can be stored is 0.000000059604645, after that flips to negative infinity.
Of course this works differently than your integer encoding where the code values are evenly spaced.
For 32fp itās 3.4028234664 Ć 10^38 an 1.4012984643 Ć 10^ā45 (from 38 digits before the decimal point, to 44 zeros after the decimal point).
And if you still donāt have enough, thereās always 64fp
Not that this is very helpful in terms of wrapping your head around.
A more practical example would be:
What is the smallest humanly perceptible banding under realistic conditions and how close to edge of the values are you?
Of course in many cases the problem becomes bigger when errors in the various nodes stack on top of each other and what was an imperceptible jump in a color value suddenly gets amplified into a horrific wart.
Which is why higher precision is more important in the processing (and possibly in intermediate renders) than in anything thatās a final export.
And no ding on following the advise of the ultimate masters. A great teacher of mine always said āin an ideal world, what would you do different?ā - maybe use 32fp and linear??? Alas, my disks are of limited size even though itās hundreds of TB, and I watch enough progress bars during the day already (does it add up to 10% of my daily activity). Sometimes I think my job description is āprofessional progress bar watcherā, not something I want to extend further. And my clients donāt always afford me the time to go after 44th digit after the decimal point. The social media monster needs feeding and the crankiness rolls down the proverbial shit pile. So compromise it is.
@allklier - you funny guy Jan - you think that I understand what youāre talking about - bless you for your generosity - my blathering is not meant as any disrespect to you or anyone else - Iām a pretty useless dummy who left home and washed dishes, then found flame and ended up cleaning plates.
No masters degree here, no doctorate.
When Doug tells me, āthis is what you do Philā, I just listen,
When he reviews my homework and says this is correct, I donāt deviate.
My GPU doesnāt do 64-bit fp - Iām still rocking the pedestrian gear of the proletariat, and I certainly wonāt be venturing into CPU processing any time soon - my hardware is already 15 years old.
And Iām just hoping that I get my head around OCIO before too long, because, well, vfx reference platform and all thatā¦
I was reading the link you posted about Doug Walker. I was quite surprised to read all this and think why flame uses a specific implementation of colour management instead OCIO. I donāt understand it at all.
pretty sure synColor came before OCIO 
flame just hasnt made the step up to ocio yet. but they have THE GUY thereā¦ so we can just hope
I did not remember that. In any case, OCIO could also be implemented.
maya had syncolor as well before they went ocio,