Hacker News Reader

Comment by __abadams__ | Hacker News Reader

Placing pixel centers at 0.5, 0.5 is only the obvious choice if you think pixels are little squares rather than point samples. Pixels-as-squares makes intuitive sense to people, especially those raised on pixel art, but it's just one possible choice you can make for your reconstruction function. It's not even a particularly good choice. It doesn't model real sensors or real displays, and it doesn't have particularly nice theoretical properties. The only thing going for it is that it's cheaper to compute some things.

View on HN

It’s true that pixels aren’t most accurately modeled as squares, but they should still be centered at (0.5, 0.5), because you want the center of mass of a W×H pixel image to be at exactly (W/2, H/2) no matter what shape the pixels are. Otherwise it shifts around when you resize the image—perhaps even by much more than 1 pixel if you resize it by a large factor.

Unfortunately doesn't make sense when you need to look up pixel 0.5,0.5 in the framebuffer.

When dealing with cameras, the central point us rarely h/2,w/2. So you're really dealing with two sets of coordinates, camera coordinates and sensor coordinates, that need to be converted between.

Integer coordinates are convenient for accessing the sensor pixels, and the camera-to-sensor space transform should theoretically include for the 0.5,0.5 offset. However, getting a calibration within 0.5 pixels accuracy is going to be hard to begin with.

Nobody’s suggesting that pixels are stored at half-integer memory addresses. After all, only a small subset of the continuous image space will lie exactly on the grid of pixel centers—and this is true no matter how the grid is offset. The point is that the grid should be considered as being lined up with (0.5, 0.5) rather than with (0, 0).

So, for example, if you’re scaling an image up by 10× with bilinear interpolation, and you need to figure out what to store at address (7, 23) in the output framebuffer, you should convert that to continuous coordinates (7.5, 23.5), scale these continuous coordinates down to (0.75, 2.35), and use that to take the appropriate weighted average of the surrounding input pixels centered at (0.5, 1.5), (1.5, 1.5), (0.5, 2.5), and (1.5, 2.5), which are located at address (0, 1), (1, 1), (0, 2), and (1, 2) in the input framebuffer. The result will be different and visually more correct than if you had done the computation without taking the (0.5, 0.5) offset into account. In this case the naive computation would instead give you a combination of the pixels at (0, 2), (1, 2), (0, 3), and (1, 3) in the input framebuffer, and the result would appear to be shifted by a subpixel offset. This was essentially the cause of a GIMP bug that I reported in 2009: https://bugzilla.gnome.org/show_bug.cgi?id=592628.

Sub-pixel accuracy is needed for good results when using stereo camera pairs, and can routinely be achieved.

If your reconstruction function is symmetric, which it should be, then your pixel centers are at 0.5, 0.5. All commonly used resampling algorithms are symmetric, except perhaps truncating implementations of point sampling (which are thus inconsistent with the rest and arguably wrong for this reason). It doesn't matter how you choose to reconstruct, samples should still be centered around their reconstruction function.

Otherwise, you're shifting the image around every time you reconstruct. This causes errors and can be very hard to reason about.

In particular, (0.5, 0.5) pixel centers together with a 1×1 box filter makes for a decent approximation to the square pixels on a display.

Exactly. For example a path tracer takes multiple samples between 0,0 and 1,1 to create anti-aliasing.

But what I also miss from the article: shouldn't the range of a pixel be -0.5,-0.5 to 0.5,0.5?

If you translate a pixel, to for example a LED on a screen, it makes more sense that it's location is the center of the LED.

Reply on news.ycombinator.com