Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you normalize RGB values by 255 or 256?

30fps.net

Post reply on HN
Print view View original

31–40 of 156 posts

Re: Should you normalize RGB values by 255 or 256?

#31

Post by atilimcetin »

vitorsr wrote: post #29
atilimcetin wrote: post #23

Interesting article. I tend to use - i = min(floor(f * 256), 255) (from float to uint8) - f = i / 255 (from uint8 to float) Basically a mix of the 2 approaches mentioned in the article. For all integers between [0,255], if I do uint8 -> float -> uint8 conversion, I will get the same result. -- edit: I wondered what's the maximum jitter amount that I can introduce to the float and get the same uint8 value. And also th…

This is what I do for the former: floor( nextafter( 256, 255 ) * value )

Oh very nice idea to get rid of the min operator.

Re: Should you normalize RGB values by 255 or 256?

#33

Post by Sesse__ »

lacedeconstruct wrote: post #27
StilesCrisis wrote: post #25

Earlier quoted context omitted.

It's just multiplication. Floating multiply is extraordinarily fast.

The difference between 20 cycles and 1 clock cycle in a hot loop is very noticeable

Useful, then, that you can start several vectorized floating-point muls each cycle. (E.g., most modern x86 are 3/0.5 cycles for vmulps. No 20 cycles in sight.)

Re: Should you normalize RGB values by 255 or 256?

#34

Post by Nuthen »

That was a fun article to read of something I haven't had to think about in a while. It brought to mind moments in game development of having pixel art needing to be drawn on an integer value despite the game logic using floating point math. I tried something similar to the +0.5 in places so that it wouldn't look as bad (especially when there's a moving camera, which also needed to be truncated..).

I also enjoyed the 2002 article by Jonathan Blow [1] that's linked at the bottom. The visualization from the first article helped a lot once this started to go more in-depth.

[1] https://web.archive.org/web/20240706043551/https://number-no...

Re: Should you normalize RGB values by 255 or 256?

#35

Post by pixelesque »

dgently7 wrote: post #30

"Let’s say you’re writing an image processing program. The program takes in an image, converts it to floating point, does some processing and finally saves the modified pixels to disk as 8-bit colors. " excuse to argue about the best way aside, if this is the goal you should not be rolling your own image file reading. you should use openimageio. idk what approach it takes in its internal conversion to float, but that…

If you're a beginner, or just want something which works quickly, sure.

However OIIO is far from perfect in all situations (having had to debug and fix issues with its mip-map generation filtering code in the past), so don't always assume that just because there's a mature open source library out there doing something that it's always perfect.

Re: Should you normalize RGB values by 255 or 256?

#36

Post by AgentME »

dgently7 wrote: post #30

"Let’s say you’re writing an image processing program. The program takes in an image, converts it to floating point, does some processing and finally saves the modified pixels to disk as 8-bit colors. " excuse to argue about the best way aside, if this is the goal you should not be rolling your own image file reading. you should use openimageio. idk what approach it takes in its internal conversion to float, but that…

OpenImageIO uses the standard division by 255 technique: https://openimageio.readthedocs.io/en/latest/imageoutput.htm...

Re: Should you normalize RGB values by 255 or 256?

#37

Post by infinet »

herf wrote: post #4

I'll argue for the +0.5 solution. First, I don't like half-sized intervals at the edges, and second, a 255-based representation is typically a SDR (not HDR) image. RGB values represent luminances against some adapted state, and a "zero" in a daylit scene is not "zero luminance" - it's just about 0.001x as bright as the brightest point - it's millions of photons, way more than zero. In a sense our eyes experience cont…

Interesting idea, but somehow I feel the world is shaking. For the processing program, what used to black(0.0) and white(1.0) has became very dark gray and very bright gray.

Re: Should you normalize RGB values by 255 or 256?

#38

Post by Tuna-Fish »

lacedeconstruct wrote: post #27
StilesCrisis wrote: post #25

Earlier quoted context omitted.

It's just multiplication. Floating multiply is extraordinarily fast.

The difference between 20 cycles and 1 clock cycle in a hot loop is very noticeable

FP Division by constant is optimized by a compiler into a multiply. Graphics processing typically happens on the GPU these days, and on all recent GPUs FPMUL belongs to the class of lowest-latency operations. That is, there are no other instructions that complete faster.

Re: Should you normalize RGB values by 255 or 256?

#39

Post by AgentME »

atilimcetin wrote: post #23

Interesting article. I tend to use - i = min(floor(f * 256), 255) (from float to uint8) - f = i / 255 (from uint8 to float) Basically a mix of the 2 approaches mentioned in the article. For all integers between [0,255], if I do uint8 -> float -> uint8 conversion, I will get the same result. -- edit: I wondered what's the maximum jitter amount that I can introduce to the float and get the same uint8 value. And also th…

It's worth pointing out that the article explicitly calls out your first mixed technique:

> Finally, one should never mix the encode and decode steps of the two quantizers. That’s just broken code. It’s an easy mistake to make, though.

Re: Should you normalize RGB values by 255 or 256?

#40

Post by exyi »

lacedeconstruct wrote: post #27
StilesCrisis wrote: post #25

Earlier quoted context omitted.

It's just multiplication. Floating multiply is extraordinarily fast.

The difference between 20 cycles and 1 clock cycle in a hot loop is very noticeable

It's 3 cycles for float multiplication (and 1 for shift right):

https://uops.info/table.html?search=mulss&cb_lat=on&cb_tp=on...

https://uops.info/table.html?search=shr&cb_lat=on&cb_tp=on&c...

In throughput it's even less of a difference: 2 per cycle vs 3 per cycle.

Post reply on HN