3 ms·

Prediction-Encoded Pixels image format

53 points by msephton 1y ago

vintermann 1y ago
So from what I understand, it predicts the next pixel by looking at the two previous pixels and counting what has appeared in that context earlier in the image. I'm not 100% sure, but I think it processes the pixels line by line. It then encodes with arithmetic encoding. Along with the palette, I think that does most of the heavy lifting in the compression, an adaptive model looking at just two pixels of context shouldn't make especially good predictions. PNG (sort of) looks at 4, the three above and the one to the left.
msephton 1y ago
I've put together a quick CLI for macOS and a very naïve benchmarking suite to see what the gains are like. Compared to optimised PNG, it's worse most of the time but the interesting thing is when it is better. I'm not sure there's a hard and fast rule, at least not that I've found so far.
- mrbluecoat 1y ago
  Link?
  - msephton 1y ago
    pepr on GitHub https://github.com/gingerbeardman/pepr https://github.com/gingerbeardman/pepr (macOS-only) Also I posted some results earlier today: https://twitter.com/gingerbeardman/status/1959934222572851613 https://twitter.com/gingerbeardman/status/195993422257285161... And I already added support to my pixel art app, Dottie, just for kicks https://twitter.com/gingerbeardman/status/1959987962306769151 https://twitter.com/gingerbeardman/status/195998796230676915...
gforce_de 1y ago
I really needs more benchmarks, especially decompression time. Also the sizes are interesting for very small images, but for real images, there are maybe better lossy variants: nz_scene - PEP = 73.542 bytes, lossy-PNG = 43.557 bytes, lossy-WEBP = 26.654 bytes, lossy-mozcjpeg = 15.716 bytes So it's not about filesize here, it must be decompression speed.
- msephton 1y ago
  The creator says that the PEP image format is meant for small, limited colour images and of course it does lossless compression.
  - gforce_de 1y ago
    Thanks for making that clear. But is it worth the hassle? https://nigeltao.github.io/blog/2021/fastest-safest-png-decoder.html https://nigeltao.github.io/blog/2021/fastest-safest-png-deco... PNG decoding seems to be fast enough: tree1 - PEP = 0.412 ms PNG = 0.25 ms font - PEP = 0.602 ms PNG = 0.663 ms nz_scene - PEP = 32.121 ms PNG = 3.069 ms Anyway, PEP is interesting!
    - fph 1y ago
      It's a lossless format optimized for file size rather than decompression speed; the README seems clear enough. Made by a pixel art game dev, for compressing sprites in pixel art games, so I assume it fits a useful niche.
    - msephton 1y ago
      I don't see any hassle, really. It's just another image format: good for some use cases, bad for others. No one file format is perfect. It was interesting enough for me to give it a couple of hours to implement a cli and add support to my pixel app.
tobinc 1y ago
Endesga is always cooking up something interesting.
Zecc 1y ago
If someone makes a presentation about this format, it will be a PEP talk. </philosoraptor>

53 points by msephton 1y ago

So from what I understand, it predicts the next pixel by looking at the two previous pixels and counting what has appeared in that context earlier in the image. I'm not 100% sure, but I think it processes the pixels line by line. It then encodes with arithmetic encoding. Along with the palette, I think that does most of the heavy lifting in the compression, an adaptive model looking at just two pixels of context shouldn't make especially good predictions. PNG (sort of) looks at 4, the three above and the one to the left.

msephton 1y ago

I've put together a quick CLI for macOS and a very naïve benchmarking suite to see what the gains are like. Compared to optimised PNG, it's worse most of the time but the interesting thing is when it is better. I'm not sure there's a hard and fast rule, at least not that I've found so far.

mrbluecoat 1y ago
Link?
- msephton 1y ago
  pepr on GitHub https://github.com/gingerbeardman/pepr https://github.com/gingerbeardman/pepr (macOS-only) Also I posted some results earlier today: https://twitter.com/gingerbeardman/status/1959934222572851613 https://twitter.com/gingerbeardman/status/195993422257285161... And I already added support to my pixel art app, Dottie, just for kicks https://twitter.com/gingerbeardman/status/1959987962306769151 https://twitter.com/gingerbeardman/status/195998796230676915...

gforce_de 1y ago

I really needs more benchmarks, especially decompression time. Also the sizes are interesting for very small images, but for real images, there are maybe better lossy variants: nz_scene - PEP = 73.542 bytes, lossy-PNG = 43.557 bytes, lossy-WEBP = 26.654 bytes, lossy-mozcjpeg = 15.716 bytes So it's not about filesize here, it must be decompression speed.

msephton 1y ago
The creator says that the PEP image format is meant for small, limited colour images and of course it does lossless compression.
- gforce_de 1y ago
  Thanks for making that clear. But is it worth the hassle? https://nigeltao.github.io/blog/2021/fastest-safest-png-decoder.html https://nigeltao.github.io/blog/2021/fastest-safest-png-deco... PNG decoding seems to be fast enough: tree1 - PEP = 0.412 ms PNG = 0.25 ms font - PEP = 0.602 ms PNG = 0.663 ms nz_scene - PEP = 32.121 ms PNG = 3.069 ms Anyway, PEP is interesting!
  - fph 1y ago
    It's a lossless format optimized for file size rather than decompression speed; the README seems clear enough. Made by a pixel art game dev, for compressing sprites in pixel art games, so I assume it fits a useful niche.
  - msephton 1y ago
    I don't see any hassle, really. It's just another image format: good for some use cases, bad for others. No one file format is perfect. It was interesting enough for me to give it a couple of hours to implement a cli and add support to my pixel app.

tobinc 1y ago

Endesga is always cooking up something interesting.

Zecc 1y ago

If someone makes a presentation about this format, it will be a PEP talk. </philosoraptor>