Comment by kllrnohj
2 hours ago
I find it very curious that their new image codec did not really compare itself against other image codecs, but instead primarily video codecs pretending to do images. As in, no JPEG or JPEG-XL.
150ms to decode 12mp is also incredibly slow. That's like PNG territory of slow. A more flagship 50mp image would be... oof.
> As in, no JPEG or JPEG-XL.
JPEG-XL is designed for archive-grade images. It hasn't been optimized (maybe not even designed?) for low bpp settings (less than 1 bit per pixel), and is awful below that, let alone 0.3 bpp or so. Plain old JPEG is much worse. Video codecs (and the image formats derived from them) have optimized for quality at low settings.
> 150ms to decode 12mp is also incredibly slow.
I think that's sufficiently fast. (Keep in mind that a 4k screen is about 8.5mp.) How fast do you want your slideshow to be?
> How fast do you want your slideshow to be?
we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.
For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.