3 ms·
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
by jessetemp 4mo ago
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.
- bjourne 4mo agoHow do you fit 256 distinct values into 255 bins?
- jessetemp 4mo agoBy counting the edges
- jrmg 4mo agoI see what you’re saying - index 0 holds values from 0-1, index 2 from 1-2 etc, but then you have index 255 holding values between 255 and 256. So you’re sort of arguing that the 0-255 8-bit quantization is actually representing ‘real’ values of 0-256?… Edit: somehow missed alterom’s reply - they explain it much better than my question above does.
- jnovacho 4mo ago> index 0 holds values from 0-1, index 2 from 1-2 etc, Well, now you are double counting the end values of the ranges. In your example 1 is included in both 0-1 and 1-2.
- jessetemp 4mo agoNot quite. I'm saying there are 256 discrete numbers (0-255) and 255 intervals between those numbers. Most of the real values will fall into the intervals and get mapped to 0-255 somehow, maybe by nearest neighbor, but I'm not trying to define how they get mapped. The point is that 255 is the largest number that can be represented with 8 bits, so you should normalize by 255. I wrote a longer replay to alterom but it looks buried for some reason. https://news.ycombinator.com/item?id=48365800 https://news.ycombinator.com/item?id=48365800
- nomel 4mo ago2*8 = 256. You can represent 256 distinct values, bins, with an 8 bit number. If you stick a 0 in that first one, it takes a bin. If you fill the rest with by-one increasing integers, then the max value will be 255, thus the 2*bits - 1, which is the max value you can store.
- pornel 4mo agoNo, the author understands the problem way deeper than you do. You haven't grasped the fact that the choice isn't obvious, and has subtle trade-offs. If you don't believe the author, check the other posts he references.
- jessetemp 4mo agoJudging by your other comment in this thread, you might agree with my rational [1] more than you realize [1] https://news.ycombinator.com/item?id=48365800 https://news.ycombinator.com/item?id=48365800
- alterom 4mo agoSorry, you seem to be confused. >There are only 255 bins, not 256 There are 256 bins because there are 256 values. The questions are: 1. What are the boundaries of these bins? 2. Which sample represents a particular bin? With 1-bit color, we have sample values {0, 1}. What bins do they represent? Here's one choice: [0, 1), [1, 2) Two equally sized bins, spanning the interval [0, 2] of length 2, each defined by its sample at lower bound. Alternatively, we could consider these bins: [-0.5, 0.5), [0.5, 1.5) These are also equally sized bins, spanning the interval [-0.5, 1.5] of length 2, defined by samples at the center. We could also define bins like this: [0, 0.5), [0.5, 1] Two equally sized bins spanning the interval [0, 1] of length 1, where we sample the first bin at the lower bound, and the last bin at the upper bound. This, in a nutshell is what the author is trying to explain. Let's look at this again, with 2 bits. With 2-bit color, we have sample values {0, 1, 2, 3}. Which bins do they come from? The three options above yield: [0, 1), [1, 2), [2, 3), [3, 4) [-.5, 0.5), [0.5, 1.5), [1.5, 2.5), [2.5, 3.5) [0, 0.5), [0.5, 1.5), [1.5, 2.5), [2.5, 3] The first two span an interval of length 4, the third spans an interval of length 3. In the third case, the tail bins are short (have size ½), and the rest have size 1. The last bin must be a closed interval in the third case, so that it includes the value we picked to represent it. None of these choices is inherently invalid or better than the others; and none stems from "confusing bins with edges". The third option does have the distinction that the first and last bins are smaller than the rest. But it's not necessarily a drawback. Especially when we're talking about color, hardware interpretation, and human perception. When you remap these bins into the [0, 1] interval, you're "dividing by 4" in the first two cases, and by 3 in the third case. The maps are: x → x/4 x → (x + ½)/4 x → x/3 The inverse maps (that yield a sample in {0, 1, 2, 3} given a floating point value in interval [0, 1]) are: x → trunc(4x) x → round(4x - ½) = trunc(4x) x → trunc(3x + ½) In the first two options, the domain is [0, 1). It might be necessary to apply clipping because the exact value 1.0 falls outside the range of the forward transform. The 2nd option is the most symmetric, of course, but the 3rd one is the most straightforward (and cheapest) to implement, so that's the default. The choice amounts to making the highest and lowest bins slightly smaller to make the rest sightly larger. That's to say, if you generate uniform noise between 0 and 1, you'll get the following samples from your function with equal probability: 0 or 3 1 2 As the author points out, this hardly matters when you are talking about having 256 bins. That, and with color specifically, the "good" histograms aren't uniform anyway (and any photographer wants to avoid getting much at either extreme). TL;DR: The author is not confusing anything — but their diagram and explanation are, indeed, a bit confusing.