Hacker News Reader

Comment by haneefmubarak | Hacker News Reader

The author mentions that one should always convert to f32 for storage or computation on linear values, but why not just use u16 or i16? You'd get both the benefits of having an integer format and a smaller data type at that, while still having the expanded space to prevent precision loss (depending on what you want to do, you may have to be a touch careful, of course).

View on HN

Component values outside the (normalized) range [0,1] are necessary to represent certain colors as sRGB (and most other color spaces). So if you're color-space aware, at least i16 is warranted. f32 just means you have to worry less about overflow, quantization effects, etc., that crop up with various image manipulations. Plus, on GPUs, 32-bit floating point math is generally at least as fast as integer math. So it comes only at a loss of space.

On GPUs, fp16 is quite a bit more power-efficient (and bandwidth-efficient) than fp32.

Aren't there problems with FP16 support being far from universal, and many GPUs having far less FP16 throughput than FP32? In some situations FP16 is definitely a better choice, but I don't think it can be given as a blanket recommendation.

I work exclusively on embedded GPUs these days, so I was surprised to read this. It's easy to repurpose FP32 hardware to at least support FP16 without reduced performance. However, seems that Nvidia has intentionally reduced FP16 performance on some consumer products for market segmentation reasons.

At first it may seem alien to think about negative brightness but it really is necessary when dealing with different color spaces.

The area inside the "RGB" color triangle is represented by positive (non-negative) values. The sRGB color triangle only covers some part of the colors that physically can exist. If you have colors outside the sRGB color triangle at least one component will turn negative.

Not all colors you could represent by RGB-values do actually exist. You can even define a bigger color triangle covering all colors that exist with positive values but also some colors that don't exist.

It doesn't physically make sense but it is a very useful tool when doing calculations. By using floating point of sufficient precision you have to worry less about how you calculate your things. It's not needed but useful. If you know your calculations well you probably don't need float.

Here is an image of some color triangles and what area they cover: https://en.wikipedia.org/wiki/Color_space#/media/File:CIE193...

you are totally correct. u16 is more than enough (as is u12 apparently!). F16 is also sufficient. I'll update the text to point this out.

Note: that relies on doing proper sRGB -> linear instead of naive gamma conversion, unless I'm completely mistaken:

    In [16]: math.log2(1./colour.models.oetf_reverse_sRGB(1.0/256.0))
    Out[16]: 11.6915341649192

    In [17]: math.log2(1./((1.0/256.0)**2.2))
    Out[17]: 17.6

    In [18]: math.log2(1./((1.0/256.0)**1.8))
    Out[18]: 14.4

Although the stuff you will be losing even if you use 2.2 gamma with 12 bit depth should be fairly minimal if I'm interpreting the numbers correctly

The right thing to use is really f16, half precision floating point. It's a crying shame that CPU manufacturers have ignored f16 for so long, because there are so many applications where it's the perfect choice. Imaging, audio, machine learning.

Agreed for imaging and ML, but fp16 is kind of crappy for audio. It adds noise at -66 dB relative to the signal at every operation, which you can definitely hear. Audio data is never so large that memory bandwidth is significant, so you should use fp32.

Reply on news.ycombinator.com