Precision: 8, 16 or 32 bit?

[Krikor]

Hi, 

I was trying to use the RGB equivalent of a specific CMYK, namely 4,100,95,0 (RGB = 244,8 0,0 12,8; #F5000d).

However, although I selected this color (# F5000d) the result when checked was always #F5000c; RGB 245.0 0.0 12.0

Even at http://paletton.com/#uid=75B0u0kw0vijNCzp8xHytouDMjd when I entered the code #F5000d, the code #F5000c was automatically assumed.

I struggled with this limitation for some time until I finally looked for a solution.

This happened by chance, when doing experiments I changed the precision from 8 bit to 16-bit integer and voilà.

With that precision, I was able to select the color #F5000d and now the Color Picker Tool recognized that color. (Although the RGB slightly different 245.0 0.0 13.0)

I am not aware of this precision issue (Image - Precision - x bit)
Does choosing between 8 bit, 16 or 32 results in some type of higher memory or processor consumption?
Can I select the option 32 bit (or 16 bit) without any fear of any unknown consequences?
In general what reference should I take to find out what is the best precision that best suits my use?

Thanks in advance!

[rich2005]

I think that is why the developers are keen on using the 0 to 100 percentage scales rather than the 0-255 RGB values. The decimals shown in the RGB 0-255 scales are a bit of an anomaly.
Converting the hex to decimal is always going to be regardless of precision.
F5 = Red = 245
00 = Green = 00
0d = Blue = 13

Using a higher precision does give a larger file size.
You can see the benefit of a higher depth especially with gradients, less 'ramping'
As far as I know, many of the internal calculations are using 32 bit fp even if using 8 or 16 bit

[Ofnuts]

(03-21-2020, 08:55 AM)rich2005 Wrote: I think that is why the developers are keen on using the 0 to 100 percentage scales rather than the 0-255 RGB values. The decimals shown in the RGB 0-255 scales are a bit of an anomaly.
Converting the hex to decimal is always going to be regardless of precision.  
F5 = Red = 245
00 = Green = 00
0d = Blue = 13

Using a higher precision does give a larger file size.
You can see the benefit of a higher depth especially with gradients, less 'ramping'
As far as I know, many of the internal calculations are using 32 bit fp even if using 8 or 16 bit

I confirm, AFAIK all internal calculations are now done in 32-bit FP linear so 32-bit FP linear is the fastest option if you have the RAM (4x the RAM of the 8-bit precision).