Thank you very much for this writeup!

I've had my rM2 since 2020 and enjoyed the hacking community a lot. I've since lost track - at some point I updated the firmware because I wanted the automatic shapes feature from upstream and couldn't use the framebuffer anymore.

You've summed up a lot of findings that I've made again and again trying to pick up where I left but it's become very confusing.

Looking forward to your next update! No pressure, though :)

I've just remembered: Check out KOreader if you haven't. I think it doesn't rely on QT and it runs on rM2 tablets with recent firmware if you launch it via ssh after stopping xochitl.

I noticed one of the cited bluesky posts was all in French, so one might argue that technically it didn't find the English word "mouch", but rather a different French word that happens to be spelled the same. But trying to sort that out seems unrealistically challenging. "Mouch" is only in the dictionary as an alternative spelling to mooch, so probably a pretty rare word to see in English.

Japanese too. Once you get past the alphabet being different, there are an enormous number of loan words (mostly from English). I bet walking around Tokyo you could read half the signs if you spent a couple of days just learning katakana.

In short: no, it shouldn't be.

The Netflix post is sort of bizarre. They claim to be optimizing for minimum mean-squared error (MSE) given a conventional (bicubic) upscaling process [0], but... that should have an analytic closed-form solution, as this post states? You definitely do not need multiple layers of neural networks to achieve it. Then they present VMAF results, but VMAF is very much not equivalent to MSE, so you have no idea if they even improved the metric they optimized for. Subjective results are similarly unpersuasive: it isn't clear if "the deep downscaler was preferred by 77% of test subjects" means they thought it was closer to the original or simply "better" than Lanczos[1]. Netflix may not care: longer watch times are longer watch times. But as an engineer you might want to know if that is because you actually achieved the thing you were optimizing for, or it is due to an artifact of the process that might go away the next time you change something to actually improve what you were optimizing for. You can famously make people prefer one audio track over another by making it louder, and video has similar things around sharpness and contrast (and now, thanks to ML, hallucinated detail).

I agree that you can do better than Lanczos for large downscale factors [2]: you need to do something area-based, like you suggest (I have not looked at OpenCV's implementation, but it could be fine). The biggest thing to get wrong is handling gamma incorrectly, but the right thing to do depends on whether you intend to display the result at the downscaled size or upscaled back to the original size as seems to be assumed here (and whether or not your upscaler is gamma-aware, which it probably isn't).

As an aside to those struggling to see the visual differences, make sure you are looking at the image in its original (1874x1596) resolution: https://redvice.org/assets/images/netflix-downscaler-compare... (or right-click, View Image on the original page). Otherwise you also have your browser's resampling algorithm in the mix. To my eyes on my display there is also a pretty big color shift in the featureless pink background of the painting on the right wall, but when I look at the actual pixel values, that appears to be an optical illusion. Subjective comparison is hard!

[0] Unlike the post, I think this is reasonable. In the past, we did experiments that showed that optimizing for bilinear when nearest-neighbor is used (for chroma) is worse than optimizing for nearest-neighbor when bilinear is used. I suspect something similar will be true for bicubic and bilinear, but these days it may be safe to assume that you will get at least bicubic upscaling (for luma), because bilinear luma looks really bad. I haven't done a recent survey of actual playack devices, though.

[1] It's also not how you report subjective test results: what was the statistical significance? There are standard protocols for these kinds of tests and it would have been helpful to cite which one was used.

[2] Nobody ever says what downscaling factors are being tested here. The example graph shows 1080p to 342p, or ~3.16x, but Netflix goes as low as 144p (from, e.g, 2160p), so they can get pretty large (15x) in practice. A 6-tap filter is not going to cut it.

Aside:

I am want to know people who use anything other than the very basic git checkout, fetch, push, merge, rebase, stash, status commit, reset.

What are you doing?

I think I have used cherrypick once? Generally I open two copies of the same repo, copy paste the code I need and commit as a new commit - the former invariably ends up as a whole mess which takes longer than copy paste efforts of the “feature” I wanted to retrieve.

This is a genuine question not rage bait. I have been in the game for 15 years. Surely there are mega complex things using git internals / obscure commands to run analytics in CI systems or hosted git solutions. But I want to know what you are doing in your workflow that requires “more” of git.

    @  ptswumyk 2025-02-12 13:16:36 de46f8c1
    │  messy working copy
    ○  slwozrlr 2025-02-12 13:16:22 feature-branch@origin d3d246a1
    │  feature implementation
    ◆  tssssuzr 2025-02-12 12:34:28 master* 8a9bab0f
    │  generate flake registry from inputs
    ~