Sub-pixel distance transform (2023)

 (acko.net)

182 points | by ChadNauseam1 day ago

6 comments

  • derf_21 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.

  • mapt18 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.

    • chrismorgan7 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.
    • ska17 hours ago
      Empirically, people can't manage even gamma properly, so imagining device dependent spatial orientation aware xforms seems like a stretch.
    • kurthr17 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.
  • dang1 day ago
    Discussed at the time:

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

  • skalarproduktr23 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).
  • doublerabbit1 day 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.

    • taspeotis1 day ago
      Please join us in the future where you can use CTRL+F to ask the computer to search for text for you.
    • saghm21 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.
      • KTibow14 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.
        • saghm9 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.
    • airstrike1 day ago
      The h is silent
    • Bjartr1 day ago
      it's in "tHe"
    • dandellion1 day ago
      "...tHe..."?
  • bun_terminator1 day 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

    • edflsafoiewq1 day ago
      What do you mean by "boolean operations for SDFs are not correct"?
      • kevingadd1 day ago
        Most of them are approximations instead of exact, so they can produce incorrect SDFs.
    • msk-lywenn1 day ago
      How would you even do a boolean operation over two distances ?
      • ChadNauseam1 day 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.

        • ww5201 day 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.
    • ww5201 day ago
      I believe the "boolean" operations is really set operations - union, intersection, subtraction, etc.
    • like_any_other1 day ago
      > boolean operations for SDFs are not correct

      They're not?