If you do not need to handle gray-level inputs, but still want a signed distance transform without a step from 1 to -1 across the boundaries, some years ago I wrote a clever bit of 80's style C code which is O(N), has lots of 1-letter variable names, and is very CPU cache friendly that solves this problem:
https://people.xiph.org/~tterribe/notes/edt.html
The resulting code (linked at the end of the page) is a bit more complicated than the standard distance transform, but only by a modest constant factor.
With the proliferation of nonstandard RGB Bayer Matrices in consumer devices, sub-pixel anything seems dicey until we have an effective device awareness/translation layer.
I'm thinking we might make it to 8K screens before that level of coordination happens.
This isn’t about 3×1 red/green/blue subpixels, though it could be applied to it; the article only mentions that once. Rather, it’s about calculations at fidelity below one pixel, which turn out to be important for accurate and pleasant results even without ClearType-style rendering, especially if you’re animating size or position changes. I kinda wish variants of the last half-dozen paragraphs had been at the start also, to give context.
Empirically, people can't manage even gamma properly, so imagining device dependent spatial orientation aware xforms seems like a stretch.
I mostly agree with you, especially for OLED. The use of "pentile", vert RGB, RGBY, and RGBW of various rotations makes it a pain. However, they already do super-resolution, transport compression, local dimming and other tricks in the display driver/TCONs. So something like this might be done locally, but you might also end up with weird results since just a couple of days ago a web demo on HN managed to screw up LCD pixel inversion. It's a case where there's rarely enough profit margin in doing something right in HW, while it can be done correctly in SW.
Discussed at the time:
Sub-pixel distance transform - https://news.ycombinator.com/item?id=36809404 - July 2023 (31 comments)
Steven's articles are always a joy. I love that he often delves into details others miss or leave out on purpose. For SDF fonts in particular, most articles skip the fact that in Valve's paper, very high-res per-glyph textures are used to produce SDFs of satisfying quality, making realtime generation rather difficult. Steven explains very nicely how to circumvent that, while still being fast and accurate (enough).
I've not seen "Grumpy wizards make toxic brew for the evil queen and jack" before. Is suppose to be a pangram?
I see no H.
Edit: oh wow. I missed that one.
Please join us in the future where you can use CTRL+F to ask the computer to search for text for you.
I've always associated that sentence with Google Fonts, since I first encountered it on their site and they use it for previewing the fonts they provide.
How long ago did you see it? I didn't start using it until recently and it seems it uses other placeholders today.
Hmm, good question...it definitely was years ago that I first saw it, but I'm not sure how recently the last time I remember seeing it is. Taking a look now, I think the entire site seems to be different compared to when I last looked at it; the layout is completely different, and I don't recall it having a dark mode before.
The h is silent
it's in "tHe"
"...tHe..."?
> some of the established practice on generating SDFs from masks is incorrect
SDFs are for some reason riddled with false beliefs. Earlier this year it drove me nuts to learn that boolean operations for SDFs are not correct
What do you mean by "boolean operations for SDFs are not correct"?
Most of them are approximations instead of exact, so they can produce incorrect SDFs.
How would you even do a boolean operation over two distances ?
Inigo Quilez (who is basically the CEO of SDFs in my book) has a page on this: https://iquilezles.org/articles/interiordistance/.
The goal isn't boolean operations over distances themselves, because as you point out that makes no sense. What you often want though is boolean operations over the surfaces the functions are returning the distance to. For example, you have one function that gives the distance to the surface of a sphere, and another that gives the distance to the surface of a cube, and you want to AND them, to get a function that gives you the distance to whichever surface is closer. That explanation probably doesn't make any sense, so just check out the page I linked which has some great visualizations.
It's important to use the correct names for things. Using the boolean lingo AND/OR/XOR to describe distance function operations just creates confusion. For example in this case, getting the distance to whichever closer surface is not an AND operation. It's a UNION operation, including the surfaces from both objects. Even if using the boolean lingo, it's more like the OR operation, cube OR sphere. It's best to use the set lingo UNION/INTERSECTION/DIFFERENCE.
I believe the "boolean" operations is really set operations - union, intersection, subtraction, etc.
> boolean operations for SDFs are not correct
They're not?
I mentioned it in another comment, but Inigo Quilez has a page on this: https://iquilezles.org/articles/sdfxor/.
They return approximations which can be very slow to iterate over depending on how far off of the actual value they are.