mattdesl

This is by Daniel Shiffman aka The Coding Train, source code:

https://github.com/Lumon-Industries/Macrodata-Refinement

Although the article is intimidating, the implementation appears pretty simple and flexible. Has anyone tried using this either in the Darktable app or in their own libraries? I might like to try porting it to JS to compare it for web based color picker GUIs.

It lets you to prove a program without having to execute it, and without needing to send the potentially private bytes over the wire.

Privacy and identity is one example; like having a proof of some record of your identity that you can submit to an app (ie: age, citizenship, # of followers on twitter), without the need to share your personal details.

Succinct proofs is another application. If you have a distributed compute environment (think folding@home), you may want receipts that proves a user in the network correctly executed a program. With ZK, the idea is that it can be cheaper to prove a program executed correctly, rather than re-execute it.

With latest LLMs I feel there is less and less need to be structured about authoring recipes.

I now jot down rough notes in Obsidian when I make a meal I like, and let AI re-format it if I want to share the full recipe with somebody. This also lets me control the output: if I’m sending the recipe to somebody who is new to cooking, I might ask for a more detailed output than if they were only interested in my flavour combinations or specific techniques.

Good idea – but it will probably take even longer than wiping with a paper towel.

That’s the kind of re-seasoning I mean: first I dry it (paper towel), then wipe with oil (more paper towel). It’s more work than cleaning a nonstick by hand and produces more waste.

I love my cast iron, but usually choose a nonstick for eggs and crepes/pancakes in the morning.

- I tend to re-season my cast iron every time I use it and it’s a chore to do this for my early morning meals.

- Non-stick is just more non-stick, with cast iron I am constrained to using a certain heat and/or fat content to create the non-stick property which I might not want for a certain dish.

I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.

I’ve implemented[1] some of these algorithms into @texel/color, a modern JS color library, and it also supports gamut mapping to certain wide gamut color spaces (Display P3, Rec2020, Adobe 1998) rather than just sRGB.

https://github.com/texel-org/color

Many popular color libraries (Colorjs.io, culori) attempt to match CSS gamut mapping spec, which is an order of magnitude slower than the approach in Ottosson’s blog post, and also less accurate (CSS gamut mapping may not fall neatly on the gamut boundary).

[1] “Ported” might be a better term as I used a combination of Ottosson’s own JS OKHSL picker, Colorjs.io code, and Coloraide (Python), and adjusted it for performance, more gamuts, and smaller bundle sizes.

Not quite—you can choose a ramp that will remain in-gamut for sRGB, eg try shifting hue here:

https://oklch.com/#72.67,0.121,240.19,100

Even if you were to use a more saturated ramp, I suspect that discontinuities due to gamut mapping with a good algorithm[1] should be less than the discontinuities due to lightness and chroma shifts in HSL, but I could be wrong.

[1] https://bottosson.github.io/posts/gamutclipping/

Pure RGB primaries gives an easy target for “red” and “green” endpoints but that’s about it. Ideally the test should consider two endpoints with uniform lightness and chroma, and just shift the hue to form in-betweens. The transition from blue to green in RGB (or HSL) is not linear in these attributes.

Surely this should be using a perceptually uniform color space like OKLab rather than HSL!

To play devils advocate:

- if your app has a number of messages (eg: “image downloaded” or “message sent” or whatever) then there is a consistency in using toasts as they all appear in the same predictable manner

- often “appear away from focus” is one of the intended goals of a toast; it’s a message that is present, but more in the periphery (the user can ignore in most cases, and it doesn’t obscure main content)

Really fascinating. After reading a little more, I learned that while Laine proposed the inversion layer hypothesis in 2016, the Auroral Acoustics group he headed was informally started in 2000. The reason the linked article is coming out now is due to Laine’s latest paper that details the triangulation of the sounds[1][2].

Would love to try and record this myself. I’ve been recording some VLF “sferics” for some time now for an art project[3]; it seems the auroral sound recordings often peak in the same frequency range (and perhaps there is overlap without me realizing it).

[1] http://research.spa.aalto.fi/projects/aurora/index.html

[2] https://www.researchgate.net/profile/Unto-Laine/publication/...

[3] https://www.mattdesl.com/sferics

For the “terrain contours” is there something specific you’ve done to make it feel more cartographic? Or is it basically just marching cubes / iso lines on some data points?

Looks fantastic. Very cool project.

Much simpler than the paper, but I have a 3D screen space implementation here[1].

[1] https://mattdesl.svbtle.com/drawing-lines-is-hard

Looks great. How are you encoding the video into MP4? Ffmpeg with wasm? Or WebCodecs?

I’ve struggled to find a pure client-side encoder that is as fast, lightweight and high quality (in terms of lossiness) as what I had going with mp4-h264[1]. I suspended the project out of legal concern but it seems like the patents are finally starting to run their course, and it might be worth exploring it again. I’ve been able to use it to stream massive 8k near-pixel-perfect MP4s for generative art (where quality is more important than file size), compared to WebCodecs which always left me with a too-lossy result.

[1] https://github.com/mattdesl/mp4-h264

Looking forward to using this. Curious about how far away WebGPU/WASM support might be, it could provide a single cross-platform backend.

Nice intro!

Readers may also appreciate my post “Pen Plotter Art & Algorithms” here:

https://mattdesl.svbtle.com/pen-plotter-1

Digital ID that I’m describing would be a way to avoid the current awful status quo of uploading your passport online (which, in the UK, has become common for things like banking, immigration, and other services). I’m not sure what your issue is.

having a cryptographic government-backed digital ID could really be a great and privacy-preserving feature of modern society. for example: ZK proofs are now practical, and could improve upon the status quo of sending a digital JPG of a scan of your passport to a third party for some arbitrary verification.

The post reads a little bit overblown.

Not quite the case anymore—rollup fees are often below $0.05 per transaction.[1]

[1] https://www.gasfees.io/

In Sweden they sell bucketloads of saffron for basically a euro or two per pack. The equivalent in UK stores would have a 10x markup at least. It seems like an industry that somebody could easily capitalize on, unless there is some trade or monopoly restrictions we don’t know about.

You are right. I was mistakenly thinking that the alternative (naive approach) would be to write the promise-creating tasks within the for loop, but if they are not part of the loop, the functionality is basically equivalent to Promise.all.

  // A -- Async and parallel
  const results = await Promise.all(data.map((i) => delay(i)));

  // B -- Functionally equivalent to the above
  const promises = data.map((i) => delay(i));
  const result = [];
  for (let a of promises) {
    const r = await a;
    result.push(r);
  }

  // C -- Problematic and naive approach: much slower
  const result = [];
  for (let i of data) {
    const r = await delay(i);
    result.push(r);
  }

To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all.

As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements.

It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster.

  images = Promise.all(uris.map(loadImage))

Lots of that advanced math research finds its way into practical engineering (cryptography, digital media, compression, physics, AI, and so on). The average layperson does not care about mathematics, period.

You may see a similar situation one day: some application might move to settle their economic value on Eth L2 rather than Stripe, eg for more control or lower fees. To the average layperson, they wouldn’t know/care about how the app works under the hood.

RSS isn’t a social media protocol with follows, comments, usernames, etc.

If that was the cost of decentralization I am sure a lot of users and especially content creators would consider it. I would rather pay 5c per year on Twitter and own my social graph, rather than pay 0c and leave the platform in the hands of the highest bidder.

Have you seen the fees on Ethereum rollups lately? It can be very low compared to trad payment processors.

https://www.gasfees.io/