int for high bitdepth

[feisty2]

all pics/vids or whatever with a bitdepth > 16 are stored as float format, why, what's so fancy of float over int, why float over long, double over long long
if it's all about BTB and WTW (outta range data), we can just pick tv range int to store under/overflow data
I'm not saying float is bad and we should all switch to int, I'm just curious, what's wrong with long and long long

[pandy]

what's wrong with long and long long

Nothing - they just require knowledge... float's are safe for careless...

[raffriff42]

http://wolfcrow.com/blog/the-advantages-of-working-in-32-bit-float/High end video work is 10-bit linear. Film scanned is 10-bit log (about 12-bit linear). 16-bits per channel should be more than adequate to work with existing material, except: If the material is created by a 32-bit 3D engine
If the material is HDR and has a large dynamic range that cannot be covered in 216 = 65,536 tonal values per channel.
If the footage has poor color for chroma keying
If precise visual effects are added for photo realistic effect
If log and linear data have to be matched
If you are working in a wide gamut color space
In such scenarios it is advisable to work in a 32-bit floating point environment.
...
Color grading in 32-bit float has the following benefits: Greater precision in calculations and color operations
A lot more colors to choose from, and results which are visible on a high-end monitor
Allowance for a greater tonal range
One can work in true HDR
True compatibility with wide gamut color spaces, including the CIE XYZ space for DCI

[feisty2]

High end video work is 10-bit linear
that's definitely INSANE, you can't just stuff linear light images into low bit depth like 10bits, you'll get CRAZY bandings at those dark scenes, even int16 is not enough for linear light (convert 8bits gamma light image to single float linear light --- round to int16 --- convert to float gamma light and round back to 8bits, and the result is slightly different from the source image, you'll have to pick a whole float precision chain, no stuff like rounding to a lower bit depth allowed, not even int16, and you get the exact same image when converted back to 8bits gamma), so just forget about int10 linear, NEVER EVER gonna work

[feisty2]

and, 2020 transfer is only allowed to vids with 12bits or higher bit depth according to rec.2020, 2020 transfer is for 12+bits vids and NOT linear, so just tell me how is 10bits linear possible from any aspect?

[feisty2]

and... anyways, I wasn't asking about "why 32bits?", cuz the answer is apparently, obvious, more precision for image is just like more money for you, always better
I was asking about "why float (single precision), not long?", float and long are both 32bits
so, actually kinda off the topic

[feisty2]

Because floating point allows more precision over integer for intermediate calculations. Using only integers means you lose all the fractional values.

not true, with the same bit amount
float = larger range, more rounding errors
int = smaller range, less rounding errors
float is kinda trading precision for range, with int, you got errors <= 0.5, with float, the error is a lot more

it's the concept for general data processing
but for images, doesn't really matter, float or int, practically the same

the point is, pixel values are relative, not independent, the value just represents a certain strength of lightness (L/Y/XYZ/RGB) or color (ab/UV) or whatever, but always one word, strength

so the largest value is always full strength, smallest value is always nothing, black or no color or whatever

when you finally display the values on screen, say, it accepts integer values from 0-1023, the range will just get scaled to 0-1023, the one with larger range and more rounding errors (float) will have a more aggressive scaling factor than int, errors will be scaled like that also, so it's like, int introduced an error 0.3, float introduced an error 3, but when scaling, int got a 1/10 factor and float got a 1/100 factor, and 0.3/10=3/100 and they end up the same

[feisty2]

How would truncated integer values ever be more precise than floating point? With integers every calculation is truncating off any fractional value.

floating point != decimals, it's like a*2^b, not a.b
that's all I can tell you
yep, you can pick a to do decimals, but that tiny error from a will *2^b, and we all know what ^ means, the error can easily exceed 0.5
Edit: I was outta my tree and described float wrong, corrected

[pandy]

but for images, doesn't really matter, float or int, practically the same

For floats more or less you have protection against some signal processing aspects already implemented in (usually) HW - as such as a code creator you can work at higher abstraction layer and stop bother with all special cases...
However if your goal is create efficient code or even more important efficient HW implementation then floats are not the best choice.
Decision for software is always limited or rather i should say should be guided by HW nature - if you have efficient float path (more efficient than integer) then float will be better than int.
Nowadays where float is almost same efficient as int , with all protection set by standard (IEEE754) float are simply more convenient to deal with unpredictable signal.
But You know all that so it is purely academic discussion.