Hacker News Reader

Comment by bonoboTP | Hacker News Reader

It's actually somewhat of a reality in some image processing code, and some people feel really passionate about whether the topleft corner pixel is located at (0.5,0.5) or (0,0).

View on HN

Direct3D made this a thing. Trying to draw unscaled 2D elements you often end up with blurry images as it bilinearly filters with the neighbouring pixels.

This is because of a mess with where it considered pixels located, where texture samples are considered located, and where, when rasterizing an included pixel, the texture coordinates sampled. See detail at [0].

If your graphics API was blurring all your images, you'd be passionate about that half-pixel offset too.

[0] https://www.gamedev.net/blogs/entry/1848486-understanding-ha...

I can relate. Spent countless hours on this stuff with computer vision and convnets. The intricacies of align_corners, implementation differences between deep learning frameworks, striding and pooling when numbers aren't neatly divisible, uuh.

The center of the pixel is at 0.5 but the top left of the pixel at the top left is 0. And the bottom right of the top left pixel is at 1.

Or the top left is located at -0.5 and every other place has the coordinates one would naively expect.

Pixels are point samples, they do not have corners, they are not little squares. [1]

[1] http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf

Except when they are. No camera samples points, almost all are closer to the little squares model.

I am quite deep into dangerous half-knowledge territory here, but I think this is wrong. The optics of a camera will transform a point source according to its point spread function [1] and you are then integrating the contributions of all point spread functions overlapping a given sensor element, which often is a little square. So taking into account the optics, what you have actually sampled is not a square, you only integrated across a square. And each spot within the sensor element was illuminated with different light that got integrated together into a single pixel value, so you can not just turn around and say that each spot on the sensor element was illuminated with the same color, the one you got from integrating across the entire sensor element. If the scene you imaged had no frequency content above the Nyquist frequency [2], then you should be able to exactly reconstruct the illumination of the sensor, including at scales smaller than a single sensor element.

[1] https://en.wikipedia.org/wiki/Point_spread_function

[2] https://en.wikipedia.org/wiki/Nyquist_frequency

Funnily enough, I actually wrote code that does that very thing this morning.

Reply on news.ycombinator.com