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

41–50 of 156 posts

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

#41

Post by Tuna-Fish »

lacedeconstruct wrote: post #19
dist-epoch wrote: post #15

Earlier quoted context omitted.

Only in micro-benchmarks. For real usage, today's CPUs are limited by memory bandwidth.

What are you talking about in a hot loop in my software renderer this is like 10x faster // color4_t result = { // .r = (src.r * src.a + dst.r * inv_alpha) * INV_255, // .g = (src.g * src.a + dst.g * inv_alpha) * INV_255, // .b = (src.b * src.a + dst.b * inv_alpha) * INV_255, // .a = src.a + (dst.a * inv_alpha) * INV_255 // }; // 1/256 but much faster color4_t result = { .r = (src.r * src.a + dst.r * inv_alpha) >> 8,…

If the latter is 10x faster, the issue is some kind of weird compilation failure for the above version. For one, it only cuts a third of the multiplies.

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

#42

Post by Timwi »

dudu24 wrote: post #3

If you have a ruler and it goes to 12 inches, you should normalize by the length L and not by 13, the number of points on the ruler.

I'm confused by that analogy. Is the “ruler” a 255-inch ruler with 256 points labeled 0–255, or is it a 256-inch ruler with 256 1-inch segments, making L = 256×1?

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

#43

Post by pixelesque »

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…

As someone with a lot of experience in this area doing image processing and rendering for VFX (including writing image readers and writers for my own software and commercial VFX software), I think you might be forgetting that colourspace conversion (to sRGB 'linear' rec709 for old-school SDR, but other more wider gamuts for newer formats) would happen after this, so the 'squish' of the dynamic range would happen after loading.

Also, a lot of workflows for image processing and compositing do assume that 0 means zero, whether correctly or not (often incorrectly). So there are often assumptions that for 8-bit, 0u maps to 0.0f and 255 maps to 1.0f for things like masking or alpha: as soon as you have 0 values which become just over 0.0, you then have artifacts because some code somewhere is using a hard threshold of 0.0 to mask some other operation, and vice-versa for 1.0 with alpha, where suddenly because the 255 values are no longer 1.0f, you have very slightly see-through objects (often only visible in certain situations or when pixel-peeping) after pre-multiplication.

(Same thing can happen when 254 becomes 1.0f after +0.5 with masking).

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

#44

Post by mgaunard »

Tuna-Fish wrote: post #38
lacedeconstruct wrote: post #27

Earlier quoted context omitted.

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.

That's only valid to do if the reciprocal is representable exactly.

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

#45

Post by dheera »

xigoi wrote: post #28
lacedeconstruct wrote: post #6

Earlier quoted context omitted.

yes but >> 8 is so much faster

You don’t divide a float by 256 by shifting it right eight bits; that would yield complete garbage. You subtract 8 from the exponent, then check if you got an underflow.

Same point; divide by power of 2 is a fast subtraction operation in float world, while divide by 255 shits all over the whole float

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

#46

Post by dgently7 »

pixelesque wrote: post #35
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.

sure of course nothing is perfect and oiio has a lot of surface area / is still oss. thats good advice.

ive just seen a lot of "ai researchers" who are getting into professional image processing and are both beginners and want things quickly and so could do much worse than just starting from what they get out of oiio. especially for a lot of the non-obvious stuff (more of that in color handling than just the io stuff though)

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

#47

Post by pixelesque »

Tuna-Fish wrote: post #38
lacedeconstruct wrote: post #27

Earlier quoted context omitted.

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.

Only with things like -ffast-math enabled will compilers do the reciprocal. It can make a fair difference in some cases, but it's often better to selectively use it in code locations you know are acceptable by doing it manually in the code.

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

#48

Post by jessetemp »

The author is confusing bins with bin edges. In their first plot, the standard approach looks strange because 0-7 should be the bin edges, not the center points as shown in the plot.

You can see this confusion again in the histogram example. There are only 255 bins, not 256. If you fix that mistake and remove the 0.5 offset, then the histogram is distributed correctly at both ends.

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

#49

Post by herf »

pixelesque wrote: post #43
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…

As someone with a lot of experience in this area doing image processing and rendering for VFX (including writing image readers and writers for my own software and commercial VFX software), I think you might be forgetting that colourspace conversion (to sRGB 'linear' rec709 for old-school SDR, but other more wider gamuts for newer formats) would happen after this, so the 'squish' of the dynamic range would happen afte…

good point - alpha is a notable exception, it is not luminance

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

#50

Post by bjourne »

jessetemp wrote: post #48

The author is confusing bins with bin edges. In their first plot, the standard approach looks strange because 0-7 should be the bin edges, not the center points as shown in the plot. You can see this confusion again in the histogram example. There are only 255 bins, not 256. If you fix that mistake and remove the 0.5 offset, then the histogram is distributed correctly at both ends.

How do you fit 256 distinct values into 255 bins?
Post reply on HN