Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider radial basis functions for smoother interpolation #7

Open
raphlinus opened this issue Aug 3, 2019 · 5 comments
Open

Consider radial basis functions for smoother interpolation #7

raphlinus opened this issue Aug 3, 2019 · 5 comments

Comments

@raphlinus
Copy link

At Libre Graphics this year, I had a number of excellent brainstorming discussions, which led to the thought that radial basis functions could be a better foundation for variable interpolation than the current piecewise multilinear approach. I've expanded on this in a document, and have also done some code prototyping; see the rbf-interp repo in particular. I have started an interactive demo of these ideas, and hope to have it soon, but not just yet.

A major motivation of this work is to capture similar design intent as Higher Order Interpolation, but hopefully in a manner that is both easier and more intuitive for designers, and also more efficient to encode into binary fonts. I believe it's worth exploring adding smooth basis functions to the OpenType spec, so these more efficient fonts can be delivered to end users.

Another consideration which I think is relevant to standardization is the requirement that basis functions be zero at the default value. Since most radial basis functions are not designed this way, I propose a "bias" term that makes it so by construction. Then, I believe, the default can be moved around fairly freely, preserving encoding of the basis functions and letting the base font be encoded the same as an instance.

Obviously this proposal is not backwards compatible; clients would need to be upgraded to be able to interpret variable fonts using these new mechanisms.

I make a number of claims in the proposal, particularly a more intuitive design process and a more economical encoding of sophisticated design intent. I don't yet have solid empirical data to back these claims, but expect to roll out prototypes and demos in the coming weeks, as I build up the Runebender toolset. But since the maximum benefit depends on changes to the OpenType font format, I wanted to start the discussion relatively early. If it turns out that I can't substantiate these claims, then I will withdraw the proposal with egg on my face. Hopefully we will have learned something, though.

I'm happy to discuss the proposal further. Editorial suggestions are probably best left as comments on the Google doc, but discussion of the merits and drawbacks of the proposal are probably best done here.

@justanotherfoundry
Copy link

justanotherfoundry commented Aug 4, 2019

Reminds me a bit of a proposal I made in 2007, on Typophile. See my (Tim Ahrens) comments in this thread. I just re-activated the link to the PDF there.

@justanotherfoundry
Copy link

justanotherfoundry commented Aug 4, 2019

This sounds very intriguing. I’d like to understand better what exactly the aims of your system are, and why this is a better solution.

Would it create visually different (improved) results, i.e. glyph shapes? If so, in which scenarios? Would it generate different shapes if only two masters are used as an input? Or, does it require additional or different input altogether? Or, does it just determine the amount of influence of each master (i.e. the coefficients) differently?

Could we see any side-by-side comparison of a glyph shape (or a test word) generated using the current interpolation practice, vs your proposed system? If there is any visible improvement I believe everyone would be convinced quite quickly!

@raphlinus
Copy link
Author

A few quick answers. First, yes, it should produce very similar results as the "partial extrapolation" PDF you linked, given similar inputs.

Second, with only two inputs (given one variation axis) it's just linear interpolation. In fact, with three inputs and two variation axes, it's bilinear interpolation also.

Third, I do expect better results in pretty much the same cases that justify Higher Order Interpolation. A classic example is when an element rotates; with linear interpolation you'll get a crude approximation at best, but with these smooth basis functions it should be very close even with three masters.

A key difference from existing interpolation schemes is sparseness. If you're thinking in terms of masters, then one way to model that is that some masters may be missing values for some points, meaning that those values will be filled in by interpolation of the remaining masters that do have values. My hope is that this sparseness reduces both the design burden and the file size (the delta for the corresponding basis function is zero, which can be encoded very efficiently).

I don't have visual examples yet, but am working on it. I have the slight challenge of building my own tools as I go (all the new stuff is in Rust), but that's kinda my style.

@justanotherfoundry
Copy link

Thanks for the explanation!

I’ll try an analogy: In the early times of digital fonts, there were systems that allowed only polygons as glyph contours. Naturally, this requires a lot of corners if you want to draw curved shapes. Then come “true” curves with much fewer control points, i.e. Bezier or whichever alternatives we have (systems with only on-curve points are probably the more accurate analogy here). Fewer points to control the shape, faster and more convenient from a design perspective, even better results, and more efficient in terms of data size. Seems what you are proposing is a bit similar but on a different level?

@raphlinus
Copy link
Author

It took a bit longer than I was planning, but I now have a demo up that shows the idea with one variable axis. The algorithm works with any number of axes, and the "interpolation toy" tool with two, but so far I've only prepared a demo with one axis.

I recorded a screencast of the demo here, which I hope will explain the ideas: https://youtu.be/MUx9Rh-loqU

To run the demo yourself, the code is at https://git.sr.ht/~raph/interp-toy . It's not a polished tool, basically just what I'm using for experiments, but people might have fun playing with it. It should be possible to create test sets using Glyphs and then use the tool to preview different interpolation settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants