NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Sub-pixel distance transform (2023) (acko.net)
derf_ 20 hours ago [-]
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.

mapt 16 hours ago [-]
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.

chrismorgan 6 hours ago [-]
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.
ska 15 hours ago [-]
Empirically, people can't manage even gamma properly, so imagining device dependent spatial orientation aware xforms seems like a stretch.
kurthr 15 hours ago [-]
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.
dang 1 days ago [-]
Discussed at the time:

Sub-pixel distance transform - https://news.ycombinator.com/item?id=36809404 - July 2023 (31 comments)

skalarproduktr 21 hours ago [-]
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).
doublerabbit 1 days ago [-]
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.

taspeotis 1 days ago [-]
Please join us in the future where you can use CTRL+F to ask the computer to search for text for you.
saghm 19 hours ago [-]
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.
KTibow 12 hours ago [-]
How long ago did you see it? I didn't start using it until recently and it seems it uses other placeholders today.
saghm 7 hours ago [-]
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.
airstrike 1 days ago [-]
The h is silent
Bjartr 1 days ago [-]
it's in "tHe"
dandellion 1 days ago [-]
"...tHe..."?
bun_terminator 1 days ago [-]
> 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

edflsafoiewq 1 days ago [-]
What do you mean by "boolean operations for SDFs are not correct"?
kevingadd 1 days ago [-]
Most of them are approximations instead of exact, so they can produce incorrect SDFs.
msk-lywenn 1 days ago [-]
How would you even do a boolean operation over two distances ?
ChadNauseam 1 days ago [-]
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.

ww520 1 days ago [-]
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.
ww520 1 days ago [-]
I believe the "boolean" operations is really set operations - union, intersection, subtraction, etc.
like_any_other 1 days ago [-]
> boolean operations for SDFs are not correct

They're not?

ChadNauseam 1 days ago [-]
I mentioned it in another comment, but Inigo Quilez has a page on this: https://iquilezles.org/articles/sdfxor/.
skykooler 1 days ago [-]
They return approximations which can be very slow to iterate over depending on how far off of the actual value they are.
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 08:29:11 GMT+0000 (UTC) with Wasmer Edge.