5 ms·
Naive Image and video codecs are quite fun to make, I have done a bunch of them over the years and it's quite easy to get within cooee of established formats.
by Lerc 4y ago
Naive Image and video codecs are quite fun to make, I have done a bunch of them over the years and it's quite easy to get within cooee of established formats. And even surpass them under certain conditions. I made a lossy image format that achieves 20-25 PSNR at around 200:1 compression, which is better than most lossy formats because that's in a quality/data-size that most image formats consider out of scope.
QOI https://qoiformat.org/ https://qoiformat.org/ is a good example of a practically useful simple format.
It's still quite a leap to get to the best new codecs, suddenly you are in a world of head hurty math.
It's also worth noting that it is easy to beat the old formats all-round with off-the-shelf parts, both JPEG and PNG can be bested by changing the outer level of compression for something that was invented after the formats were made. For instance using LZMA or zstd as the final stage. Quite often that's enough to put them on a par with more radically different newer formats.
- repple 4y agowithin cooee : within hailing distance : not unapproachable
- andrewflnr 4y agoI did guess something like that eventually, but given the context my first thought was "let's see, COefficient Of, uh, hmmmm..." :D
- bob1029 4y ago> It's also worth noting that it is easy to beat the old formats all-round with off-the-shelf parts, both JPEG and PNG can be bested by changing the outer level of compression for something that was invented after the formats were made. The heart of JPEG is in The DCT and its energy compaction properties. One crazy thing about the DCT is that it doesn't just let you make trade-offs for high/low frequency features. It also lets you make tradeoffs for horizontal and vertical features. If you customize your quantization matrix to your specific application, you can potentially achieve compression ratios far exceeding anything available today - even if you leave in the crusty old RLE+Huffman coding. If you want to get up to your elbows in this sort of thing, there is an entire book on it by Rao & Yip that is about as comprehensive as it gets - https://www.abebooks.com/products/isbn/9780125802031/31198865463 https://www.abebooks.com/products/isbn/9780125802031/3119886...
- deaddodo 4y agoThis is the primary reason that custom DCTs and a whole slew of predefined DCTs are included in the standard. The common 8x8 default works in most cases, but you can optimize heavily for edge case images (in which case, baking in the DCT is made up for by the decreased data size).
- skywal_l 4y agoThe Computerphile channel has a nice series of videos on JPEG and one focusing on DCT [0]. It's a nice and easy intro to the subject. [0]: https://youtu.be/Q2aEzeMDHMA https://youtu.be/Q2aEzeMDHMA
- userbinator 4y agoFor instance using LZMA or zstd as the final stage. Quite often that's enough to put them on a par with more radically different newer formats. If you do that with a video codec, you lose the ability to seek within the stream, which makes it useless for streaming video. For images, the amount of memory required to decompress may become excessive. It's similar to why zip (deflate) is still widely used, but is far from optimal in compression efficiency; everything that does better (in some cases much better) is going to be slower, bigger, or both. See https://en.wikipedia.org/wiki/PAQ https://en.wikipedia.org/wiki/PAQ for an example of extreme lossless compression.
- traverseda 4y agoI use zstd in my btrfs filesystem as a transparent file compression. I can still seek inside files.
- heavyset_go 4y agobtrfs does compression at the block level, whereas video compression would do it at the stream level. Files themselves are not compressed on btrfs, it's the blocks that get compressed.
- formerly_proven 4y agoVideo streams are generally compressed in blocks called group of pictures (GOP) as well. That's how seeking in a video stream works - skip to the beginning of the GOP the desired timestamp is in, start decoding from there and show images once the timestamp is reached.
- traverseda 4y agoWell that was kind of my point, why assume that the above poster would go for the most naive possible implementation when thinking about it for more than a minute yields several obvious solutions, and there are known implementations that have already solved that problem? ZSTD also has some fun "dictionary" operations so that even if you're chunking your data you can still take advantage of cross-chunk redundancy by "training" across all your chunks before the compression stage.
- WalterBright 4y ago
- ninepoints 4y agoFiling a patent "for fun" and then posting about with details about the patent contents on a technical forum should be outlawed.
- WalterBright 4y agoI don't have any financial interest in it, if that's what bothers you.
- ninepoints 4y agoMany of us, myself included, do not want to read about patent encumbered IP in general. It doesn't matter who owns the patent, or how you purport to wield it on this particular day, in this particular year. You are essentially doing the equivalent of traversing the internet, planting mines as you go.
- WalterBright 4y agoI clearly identified it up front as a patent, and if you don't want to read about it, just skip it.
- ninepoints 4y agoThat's like saying "movie spoiler ahead" and then writing it out in cleartext. C'mon man...
- rasz 4y ago>achieves 20-25 PSNR at around 200:1 compression, which is better than most lossy formats because that's in a quality/data-size that most image formats consider out of scope. according to https://cloudinary.com/blog/contemplating-codec-comparisons#speed_depends_on_quality_setting https://cloudinary.com/blog/contemplating-codec-comparisons#... google leaned hard on AVIF ability to produce small garbage in its comparison against jpeg xl