Also possibly of interest to HN, the decoder[2] is written in a new low level language called symbolasm[3], which seeks to combine the advantages of assembly language (it's possible to reason about and optimize performance with few limits) with some of the affordances of C, especially named variables and struct fields.
[1]: https://github.com/raphlinus/vic-2350
[2]: https://github.com/raphlinus/vic-2350/blob/main/image.sy
Don’t you get this from most macro assemblers? I know I’ve seen some very old and crusty ASM that nevertheless does structured programming and even limited OOP through macro-ASM facilities.
(That being said, symbolasm looks 1000x more ergonomic and “also communicates developer intent”-laden than any macro ASM ever did; and also is probably something you could learn once, while a project’s macros are specific to said project.)
Ycombinator is owned and driven by nepotistic Jewis* p3dophiles, to trick people into giving ownership of startups and giving talent away for peanuts, instead of having their own startup accelerators or financing. No wonder that Ycombinator has a literal Epstein on their board. Remember to kill every single p3dophile.
I feel like one of the main tasks in front of us as an industry right now is to figure out how to use LLMs well, how to create quality and resist slop. As part of that, I'm taking care to write the prose myself.
I totally understand how any LLM usage can be a turnoff, though. I've felt that myself.
2) BCx essentially does the same codebooking/paletting but more efficiently by allowing you to interpolate between two palette entries for an even larger compression
Sure - muuuuuch less than Jpeg, but how many would you assume for JPEG on average? How low could you go by misusing jpeg?
Typically, you would plot graphs with Bitrate / quality / speed. Maybe even with default jpeg settings and getting just a single data point for your new algorithm.
this decodes at HDMI line speed, 6 opcodes per pixel
Edit: I should say, I find it surprising (but cool) that it apparently works so well. I would have expected errors to accumulate since the decoder has to un-delta-code. I saw mention of Floyd-Steinberg dithering and presumably that's what it's for; seems hard to get it working across multiple colour axes simultaneously, but the complexity is all in the encoder, so.
As for tracking error across multiple color axes, I would naively assume it's a 3-vector (maybe in a linearized perceptual color space, or maybe RGB) and the error term the encoder minimizes is just the vector magnitude?
Very cool. I think it's best understood as a coding exercise for the embedded CPU vs a 'real' video format, but no less impressive IMO
I guess you could also call Amiga's HAM graphics mode a compression method. Getting 12-bit (4096 colors) with just 6 input bits, with the original Amiga chipset, often called as "OCS".
Or later 262144 colors with 8 input bits, with the AGA chipset.
I think this radio model could map the problem space for a centralized system that maintained a list of items and their prices which needed to be broadcast to the retail outlets on a regular basis.
Or a common cache storage to make some complex data manipulation calculations centrally performed available to a large number of satellites who just need the end results but do not have the need to do local calculation.
But I do agree, the comment smells "AIsh." It may not be, however, if this is his standard writing style. I have been accused of being a "bot," for stuff I wrote ten years ago. It's my observation, that people tend to accuse any lengthy comments of being LLM-generated.