[HN Gopher] Sub-pixel distance transform (2023)
___________________________________________________________________
Sub-pixel distance transform (2023)
Author : ChadNauseam
Score : 179 points
Date : 2024-12-26 20:48 UTC (1 days ago)
(HTM) web link (acko.net)
(TXT) w3m dump (acko.net)
| bun_terminator wrote:
| > 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
| like_any_other wrote:
| > boolean operations for SDFs are not correct
|
| They're not?
| skykooler wrote:
| They return approximations which can be very slow to iterate
| over depending on how far off of the actual value they are.
| ChadNauseam wrote:
| I mentioned it in another comment, but Inigo Quilez has a
| page on this: https://iquilezles.org/articles/sdfxor/.
| edflsafoiewq wrote:
| What do you mean by "boolean operations for SDFs are not
| correct"?
| kevingadd wrote:
| Most of them are approximations instead of exact, so they can
| produce incorrect SDFs.
| msk-lywenn wrote:
| How would you even do a boolean operation over two distances ?
| ChadNauseam wrote:
| 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 wrote:
| 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 wrote:
| I believe the "boolean" operations is really set operations -
| union, intersection, subtraction, etc.
| doublerabbit wrote:
| 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.
| airstrike wrote:
| The h is silent
| Bjartr wrote:
| it's in "tHe"
| dandellion wrote:
| "...tHe..."?
| taspeotis wrote:
| Please join us in the future where you can use CTRL+F to ask
| the computer to search for text for you.
| saghm wrote:
| 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 wrote:
| How long ago did you see it? I didn't start using it until
| recently and it seems it uses other placeholders today.
| dang wrote:
| Discussed at the time:
|
| _Sub-pixel distance transform_ -
| https://news.ycombinator.com/item?id=36809404 - July 2023 (31
| comments)
| skalarproduktr wrote:
| 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).
| derf_ wrote:
| 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 wrote:
| 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.
| kurthr wrote:
| 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.
| ska wrote:
| Empirically, people can't manage even gamma properly, so
| imagining device dependent spatial orientation aware xforms
| seems like a stretch.
___________________________________________________________________
(page generated 2024-12-27 23:02 UTC)