3 ms·

It's more like a little fuzzy blob, typically with RGB sub-blobs.

kennywinker 5y ago
I think you're thinking of a pixel on a display? Because arguably that's just a rendering of a data set. The pixels the article are referring to are the data set, a set of point samples. In which case it has no shape - since it's a point - and the r, g and b components are just different samples at the same point
edrxty 5y ago
This is where I take issue with the paper. The sub blobs are really important because different displays/focal plane arrays have different pixel arrangements that can be dramatically different. You can't assume it'll be a collection of three sub-elements (often there will be different ratios in a complex arrangement) or that the pixel is even being displayed as RGB (CMY?). You have to know some things about your pixel arrangements in order to properly anti-alias, font render, or display camera images, otherwise the result can be pretty ugly.
dhosek 5y ago
Back when I was writing code for the Apple ][ (long-hand, on graph paper), I worked out graphics layouts by drawing my pixels four to a square on the graph paper, representing each pixel with a circle. I also never forgot that (a) the pixels were actually kind of rectangular and (2) in hires graphics mode, if you viewed things as 280x192, adjacent pixels were either •• and • or • and •• depending on the high bit of the byte that had the bitmap data. I think it might have been possible to get •◦• where one RGB-triple was split across bytes.
jayd16 5y ago
Not exactly right either. Before its displayed to some approximation in some RGB array, it was some back buffer. That back buffer could have been attempting to render an infinitely small, crisp line or a line almost two pixels wide. The point is that kind of information is not encoded in the buffer. Its just a point sample of the output of the previous stage in the pipeline.

I think you're thinking of a pixel on a display? Because arguably that's just a rendering of a data set. The pixels the article are referring to are the data set, a set of point samples. In which case it has no shape - since it's a point - and the r, g and b components are just different samples at the same point

edrxty 5y ago

This is where I take issue with the paper. The sub blobs are really important because different displays/focal plane arrays have different pixel arrangements that can be dramatically different. You can't assume it'll be a collection of three sub-elements (often there will be different ratios in a complex arrangement) or that the pixel is even being displayed as RGB (CMY?). You have to know some things about your pixel arrangements in order to properly anti-alias, font render, or display camera images, otherwise the result can be pretty ugly.

dhosek 5y ago

Back when I was writing code for the Apple ][ (long-hand, on graph paper), I worked out graphics layouts by drawing my pixels four to a square on the graph paper, representing each pixel with a circle. I also never forgot that (a) the pixels were actually kind of rectangular and (2) in hires graphics mode, if you viewed things as 280x192, adjacent pixels were either •• and • or • and •• depending on the high bit of the byte that had the bitmap data. I think it might have been possible to get •◦• where one RGB-triple was split across bytes.

jayd16 5y ago

Not exactly right either. Before its displayed to some approximation in some RGB array, it was some back buffer. That back buffer could have been attempting to render an infinitely small, crisp line or a line almost two pixels wide. The point is that kind of information is not encoded in the buffer. Its just a point sample of the output of the previous stage in the pipeline.