[kllrnohj]

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.

[theandrewbailey]

> 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?

[kllrnohj]

> 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?

A modern iPhone can capture at up to 48MP. If the performance scales linearly with pixel count, that would put tapping on a thumbnail to the full size being ready at over half a second. That's going to feel laggy. Now you can throw storage at the problem and pre-compute a downscaled intermediate, sure, but that doesn't fix it when you send the photo to someone else or whatever.

And competitive phones are doing 200mp captures (which is stupid in its own right but phone manufacturers and doing stupid things, name a more iconic duo)

[rescbr]

At least JPEG contains downscaled thumbnails embedded into it as part of the EXIF stream. There's no need for the receiving device to rescale it again.

Pretty sure these newer formats do the same.

[kllrnohj]

That thumbnail is for grid-size, it's generally 50kb or less in size which ends up being around 300x240 or up to 500x500 on newer codecs.

It'll be visibly low-res and blurry until the full size decodes for full screen. Hence why I said "when tapping on a thumbnail"

[rescbr]

Oh, I missed the “tapping on” part.

[jcelerier]

> 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.

[sdenton4]

That's fine reasoning for video, but if someone is actually looking at a still picture for more than 1/240th of a second, the fine detail matters a bit more. These are different applications, with different sweet spots in the time/quality trade-off.

[kg]

Think about the scenarios where people are viewing slideshows. If you're on a mobile device, that 150ms spent decoding each image is time where the CPU and/or GPU of the mobile device are running at full tilt, draining the battery. Suddenly applications that would normally be fast and efficient like a photo gallery app become laggy and drain your battery. Not great.

[gforce_de]

Yeah, thats slow - but the approach is at least interesting:

I tried to compare it with other encoders for the sample (girl/face painting): https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...

The PICO-result claim to achieve 0.268 bpp (bit-per-pixel): Even webp (version 1) can do that good enough.

I understand, that one needs really advanced hardware to decode this. Not sure if this is worth the hassle.