Prediction-Encoded Pixels image format

(github.com)

31 points | by msephton 2 days ago ago

9 comments

  • gforce_de 2 days ago 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 2 days ago 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 19 hours ago ago

        Thanks for making that clear. But is it worth the hassle?

        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!
        [-]
        • msephton 4 hours ago 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.

  • msephton 2 days ago 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.

    [-]
  • Zecc a day ago ago

    If someone makes a presentation about this format, it will be a PEP talk.

    </philosoraptor>

  • tobinc 2 days ago ago

    Endesga is always cooking up something interesting.