Prediction-Encoded Pixels Image Format

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.

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.

  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

Endesga is always cooking up something interesting.

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.

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

</philosoraptor>