A Pixel Is Not A Little Square (1995) [pdf]
31–40 of 81 posts
Re: A Pixel Is Not A Little Square (1995) [pdf]
#32Earlier quoted context omitted.
I can tell you right now that you will have a very difficult time beating a normalized gauss filter with a diameter of around 2.2 pixels in a general case. Color and luminance is a separate and orthogonal issue from filtering. I also know that people get away with compositing without converting to linear space, but I'm skeptical that any benefits they see aren't just a matter of getting the color curve they want for…
I was working at PDI Dreamworks during one of the semi annual investigations into which filter kernel was best. And I was completely blown away by how quickly the lighting sup could identify and react to various filters. Gaussian was voted down reliably and repeatedly for being too blurry. Personally, I like the extra blur I get (and extra safety and guarantees) you get with Gaussian. Back in the NTSC days I discover…
Re: A Pixel Is Not A Little Square (1995) [pdf]
#33Earlier quoted context omitted.
>We are so used to see the visual presentation of samples that look like a bar diagram, that a lot of people think analog sounds better because the curves are smoother. Except for a philosophical debate about continuity, isn't that true?
http://productionadvice.co.uk/no-stair-steps-in-digital-audi... The “stair-steps” you see in your DAW when you zoom up on a digital waveform only exist inside the computer. [...] When digital audio is played back in the Real World, the reconstruction filter doesn’t reproduce those stair-steps – and the audio becomes truly analogue again.
Re: A Pixel Is Not A Little Square (1995) [pdf]
#34A pixel is a picture element. An element of a picture. Hence the name... It turns out that thinking of them as little boxes arranged in rectangular grids is very useful. Because that is how computers deal with them. Not as point samples. The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magni…
I break every mathematical object down into three things:
1. The intuition. Why do we have this concept to begin with? What underlying idea are we trying to capture?
2. The definition. These are the axioms.
3. The implementation. This includes every way to communicate the idea, from natural language words to notation to source code.
Without the intuition, you have nothing but a symbol game. It's hollow. Something with rules and notation but no deeper intuition is, arguably, chess.
Without the definitions, you can't think rigorously about your ideas and you don't know if they lead to internal contradiction. You can dump the axioms without losing the intuition; we did this with set theory at the turn of the previous century, when Russell proved that the previous axioms were inconsistent. We saved set theory without having to abandon the notion, the intuition, of sets entirely.
Without implementation, it's just thought, and you can't communicate with anyone. Moreover, without some intuition, the implementation is meaningless, because you have no cognitive frame to use to interpret it.
So the tuple of numbers is one implementation of a vector. It allows you to communicate some aspects of a vector, but without the underlying idea of what a vector means, what concept we're trying to get across, it's just a list of numbers. They might as well be box scores or something.
Re: A Pixel Is Not A Little Square (1995) [pdf]
#35The same is true for digital audio. We are so used to see the visual presentation of samples that look like a bar diagram, that a lot of people think analog sounds better because the curves are smoother. Chris Montgomery has a great talk about this.
>We are so used to see the visual presentation of samples that look like a bar diagram, that a lot of people think analog sounds better because the curves are smoother. Except for a philosophical debate about continuity, isn't that true?
Re: A Pixel Is Not A Little Square (1995) [pdf]
#36Earlier quoted context omitted.
I was working at PDI Dreamworks during one of the semi annual investigations into which filter kernel was best. And I was completely blown away by how quickly the lighting sup could identify and react to various filters. Gaussian was voted down reliably and repeatedly for being too blurry. Personally, I like the extra blur I get (and extra safety and guarantees) you get with Gaussian. Back in the NTSC days I discover…
Were all the filters being compared with the same width? At the same width it will be softer, at a smaller pixel radius is where you can compare aliasing with the same visual sharpness as something like catmull-rom.
Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocked how good they were at it, and how not that good I was. :)
Truncating the Gaussian too closely though, and it’s not exactly a Gaussian anymore, you lose the best antialiasing properties. I can totally see how it will be sharper and more comparable to other popular filters. (Normalized & truncated at 1.1 radius is just slightly outside the 1 std dev line, right?)
Gaussian is my personal choice for large format prints of images with extreme aliasing problems.
Re: A Pixel Is Not A Little Square (1995) [pdf]
#37Earlier quoted context omitted.
The non-antialiased “case” is one spot among the continuum of antialiased “cases”; it doesn’t satisfy totally different perceptual rules. What gamma curve would you propose to correct for the perceptual equality of a 9.3px white-on-black line with a 11.6px black-on-white line? What I’m saying is that you’re presupposing the wrong layer to make the correction (antialiasing or no).
You are correct. Change my third question to, "after applying a correct gamma curve to achieve perceptually uniform line widths in the unipolar case, what is the correspondence of line widths when inverting the polarity to preserve the perception of width matching?" Then you want to break that down into the contribution assuming a perfect display and the effect from lower dpi. This question is less important than the…
It's axis-aligned and box-filtered so there are no shades of gray, which means gamma is irrelevant. The white-on-black line appears to have a greater thickness than the black-on-white line.
There's a lot of empirical research showing that reading performance is better with positive-polarity (black-on-white) text than with negative-polarity text [1, 2], probably because the higher overall luminance results in a smaller pupil size and thus a sharper retinal image [3]. So, white-on-black lines appear thicker than black-on-white lines because the eye doesn't focus as sharply on them. This is true regardless of which color space blending is performed in.
Given this fact, if one wants to achieve uniform perceptual line thickness for black-on-white and white-on-black text, a more principled approach than messing with color blending would be to vary line width or the footprint of the antialiasing filter based on the luminance of the text (and possibly the background). This is the approach Apple and Adobe have taken for years with stem darkening/font dilation.
[1]: http://jdobr.es/pdf/Dobres-etal-2016-Displays.pdf
[2]: https://www.uni-duesseldorf.de/home/fileadmin/redaktion/Oeff...
[3]: http://www.psychologie.hhu.de/fileadmin/redaktion/Oeffentlic...
Re: A Pixel Is Not A Little Square (1995) [pdf]
#38Earlier quoted context omitted.
Were all the filters being compared with the same width? At the same width it will be softer, at a smaller pixel radius is where you can compare aliasing with the same visual sharpness as something like catmull-rom.
There were a variety of widths, it was one axis of the study. But I don’t remember the details, it is certainly possible you’re talking about something we didn’t test. Personally, at first I couldn’t even see the differences they were discussing. Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocke…
Re: A Pixel Is Not A Little Square (1995) [pdf]
#39Earlier quoted context omitted.
You are correct. Change my third question to, "after applying a correct gamma curve to achieve perceptually uniform line widths in the unipolar case, what is the correspondence of line widths when inverting the polarity to preserve the perception of width matching?" Then you want to break that down into the contribution assuming a perfect display and the effect from lower dpi. This question is less important than the…
As a simple demonstration, here's an image of a 1px white-on-black line and a 1px black-on-white line: https://imgur.com/a/9d9Tu3x It's axis-aligned and box-filtered so there are no shades of gray, which means gamma is irrelevant. The white-on-black line appears to have a greater thickness than the black-on-white line. There's a lot of empirical research showing that reading performance is better with positive-polari…
Here's the interesting thing about your observation: doing alpha compositing of text in a perceptual space (as opposed to a linear space) results in a thickening of black-on-white and a thinning of white-on-black. So doing gamma "wrong" actually results in better perceptual matching.
Do you have evidence that either Apple or Adobe varies the amount of stem darkening based on text luminance? I've tested Apple (macOS 10.12 most carefully) and have not seen this.
Re: A Pixel Is Not A Little Square (1995) [pdf]
#40Earlier quoted context omitted.
Were all the filters being compared with the same width? At the same width it will be softer, at a smaller pixel radius is where you can compare aliasing with the same visual sharpness as something like catmull-rom.
There were a variety of widths, it was one axis of the study. But I don’t remember the details, it is certainly possible you’re talking about something we didn’t test. Personally, at first I couldn’t even see the differences they were discussing. Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocke…
Using only one standard deviation cuts off a huge amount of the curve, ideally it would be cut off around the third standard deviation and normalized so that the value after the last would be zero.