bmh

What if you're formatting your own SD cards for Raspberry Pi, and need control over the partition layout, filesystem, etc. Surely there are some best practices that this tool embodies, which one can follow to achieve the same level of robustness and performance?

The latest Pi OS writes all logs to RAM, which might change your experience.

I agree 100%

They decided to use the silicon space for other things. The Pi5 CPU is powerful enough to decode most h264 streams in software. The Pi5 has an h265 hardware decoder.

You need active cooling if you want to extract all the performance out of it. The standard cooling kits sold by Raspberry Pi are neat and cheap though, so not a problem in my experience. They have two options: A case with a fan on top, and a small heatsink + fan combo. The fans run at variable speed, so generally pretty quiet.

Who actually uses multipath?

It's interesting that the standard "K" (number of elements with a shared scale) is 32. That seems to imply that the neural network will somehow learn to group weights at those 32-element boundaries. Does anybody understand how that works? I mean, what is the mechanism that naturally causes the model to group weight scales into those K-element clusters?

Haha. I first read that headline as "Hans Niemann dies using vibrating sex toy"

"Modulation can be turned off on alternate scans to identify velocity using unmodulated carrier frequency shift. This allows range and velocity to be found with just one radar set."

quote from https://navtechradar.com/explore/fmcw-radar/#:~:text=Frequen....

The short answer is:

Yes, you must disable CPU frequency scaling in your BIOS if you're doing this kind of work (i.e. building cryptographic primitives that don't leak information via timing).

See https://timing.attacks.cr.yp.to/overclocking.html

TL;DR: The December 5th experiment was about proving to ourselves and our adversaries that we still understand how to build and validate nuclear weapons, despite the ban on testing.

It's conceivable that within a year or two, Copilot will be good enough to make the pain of the CMake language much more bearable.

Apparently it's a known issue: https://github.com/Djdefrag/QualityScaler/issues/21

Windows Defender says that the binary has Trojan:Win32/Wacatac.H!ml inside it.

This is an extremely accessible blog post, and very interesting, even if you're not deep into transformers.

Yes, this would definitely work, so long as the two cameras have sufficient overlap. If you were to use OpenCV's stitching code, then you could run the first few phases of that on your initial photo pair, which determine the camera angles, and then save those angles.

Then, for every video frame, you could skip the photo angle computation, and just run the imagine stitching logic. The stitching_detail code is very readable, and quite easy to hack for experimentation.

I'm convinced after the work I did on panoramas that one shouldn't need to involve user input. Maybe for very strange situations... but generally it shouldn't be necessary. This is especially true if you have access to the IMU on a phone, which helps constrain the potential angles of each of your images.

If your images are just a random bag of jpegs that came in from the cold, then it's harder for sure.

I started from the OpenCV stitching_detailed example, and worked from there. That example runs pretty much out of the box on Android.

A panorama is built by stitching together many images taken from the same viewpoint.

The 1st critical thing you need to know, is that the camera may not move. It may only rotate. If the camera moves a tiny bit, that's generally OK, but there will be stitching artifacts. To be really precise, the entrance pupil of the camera shouldn't move, but this is quite hard to get right.

The 2nd thing, is that the stitching algorithms need to match images to each other, and in order to do this, the images must have large overlapping portions. This usually means that if you want to create a 360 degree panorama where you spin your camera all the way around, you'll have at least about 12 images. The minimum number of images depends on how wide your lens is.

This is a great overview of panoramas: http://6.869.csail.mit.edu/fa17/lecture/lecture14sift_homogr...

One more thing: It really helps to apply lens correction to your camera images, if you're trying to create a high quality panorama.

Microsoft seems to have discontinued ICE a long time ago. As far as I know, the state of the art in panorama stitching is PTGui.

I was working on mobile panorama stitching last year, and one of my datasets had a kitchen wall that was almost purely white, so very little detail for the classic feature algorithms such as SIFT and ORB to cling to. The OpenCV stitching pipeline, which is built on these (and RANSAC), didn't do very well when matching these walls.

But PTGui was amazing on this data - it would find just a tiny number of very high quality feature points to match (eg 3 or 4), and produce a perfect panorama. In addition, it's really fast. I was very impressed.

Nice feature: You can adjust brightness of multiple monitors simultaneously.

Every night I set brightness of both monitors to 15, and every morning I raise it back to 30.

I've been hoping for a tool like this for years.

Thanks! I see the <cut> operator is actually explained in an older HN post: https://news.ycombinator.com/item?id=20502032

I love PEGs, but their error messages are usually vague, because it will backtrack out of a deep tree (where it should have discovered the actual error), and then presents an error much higher up ("computer says no").

Is there a mechanism that works well for improving errors in PEGs (i.e. something like a non-returnable node), and how does one practically implement that?

I've tried to setup a 4K and a 2K monitor side-by-side, with one at 200% and the other at 100%.

How exactly do you make this work? Whenever I try and use different scaling on my different monitors, the OS (Ubuntu 20.04) ends up setting them both to the same setting.. or something else weird happens. I have tried a lot, and never managed to get Ubuntu 20.04 to set 200% on one monitor, and 150% on the other.

I'm actually about to embark on exactly such a project. My plan is to use OpenCV's "stitching_detailed.cpp" example, and improve it from there. OpenCV's stitching is quite good out of the box, but I think I can improve it by adding knowledge from the phone's IMU. What do you need this for?

A toy illustrative example, summing two arrays:

  CUDA
    c[i] = a[i] + b[i]
    i += 1

  Triton
    c[i:i+16] = a[i:i+16] + b[i:i+16]
    i += 16

The 16 in this example is the "block size", and could be anything. But this notion of expressing computation over blocks of dense data seems to be the big difference from other approaches.

A very exciting result of the incredible performance that Triton achieves, is the ability to fuse NN operations such as Matrix Multiply + LeakyReLU + Batch Norm. Previously, you needed to rely on cuBLAS for fast hand-written Matrix Multiply kernels, and then your LeakyReLU would need to read that result out of memory, and then your Batch Norm would read the LeakyReLU out of memory again.

The ability to write very fast kernels, and especially being able to fuse them together, to avoid unnecessary memory round-trips is a big deal!

This sits BELOW the automatic differentiation layer.

No, this is a DSL that allows people who normally write CUDA, to do so with less lines of code, and end up with a faster kernel. By embedding it inside Python you don't need to write your own lexer/parser.

Training a GAN is an interesting approach!

But one thing that I'm not sure you're aware of - is that you can get very good results without resorting to this.

The trick is basically to get Freetype to render the glyph with hinting enabled, but at increased horizontal resolution (eg 4x is enough). By stretching the glyph horizontally, you basically get rid of the vertical hinting. Because you're rendering for LCD sub-pixel display, you triple the 4x again, so you actually render horizontally at say 3*4 = 12x pixel width. This wipes out the effect of hinting horizontally, but preserves the vertical hinting, which gives you the best of both worlds. You get crisp horizontal edges, and the ability to place glyphs with sub-pixel precision on the X axis. Of course for mono-spaced fonts this doesn't matter, and for maximum crispness, you might as well just render LCD sub-pixel glyphs with full hinting, which gives results that looks similar to the example at the top of your page.