What is the best routine for graphics compression?

[Lethargeek]

black-flag-deck:

I couldn't find this by name, but i suspect it's half empty or overly regular. As i planned to make a compressor for an arbitrary rectangular area and the decompressor was big enough already, i never optimized for "lighter" screens (and RLE is only for attributes). On a big selection of screens LgK is usually much better (hundreds of bytes) for about 90% and very close (maybe a bit worse) for the rest.

Theres are also a few pathological cases (see R-Tape's avatar here or a low-res imitation like Alien Syndrome)) with much worse ratios compared to "byte compressors", the result of very limited number of unique bytes for most of the screen area and less (if any) correlation between the adjacent pixels.

Also pics with less regular dithering (like Floyd-Steinberg) may go either way, but usually the chunky method is good enough. .

[catmeows]

black-flag-deck:

I couldn't find this by name, but i suspect it's half empty or overly regular.

Indeed, it is.

As i planned to make a compressor for an arbitrary rectangular area

Ah, it is pitty you didn't. The benchmarks for full screen Are intetesting but I think for in-game graphics, smaller pictures are more relevant. And LZ variants have really hard times with small screens, especially when they have fixed offset sizes.

Also pics with less regular dithering (like Floyd-Steinberg) may go either way, but usually the chunky method is good enough. .

I understand but random dither are hard to pin in general, so I don't sebe it as a problem.
To be honest I'm quite surprised how well LGK works.

One thing I would really like to try one day is proper context -> prediction -> range coder packer.
I mean using pixels on west, north-west,north to form a 3-bit context and kind of range coder. It would be inevitably slow (I did some estimations and for 8-bit probabilities multiplying 16-bit limits I got liitle less than 1000 t-states per pixel -> about 400 ~ 500 bytes / sec) but it would really catch the cases where you have small illustration + text on screen.

[Lethargeek]

Ah, it is pitty you didn't. The benchmarks for full screen Are intetesting but I think for in-game graphics, smaller pictures are more relevant. And LZ variants have really hard times with small screens, especially when they have fixed offset sizes.

maybe i will address this in future versions, but right now i have too little free time when my brains are in working condition

I understand but random dither are hard to pin in general, so I don't sebe it as a problem.

fun fact: once i found one particularly bad dithered specimen and later it turned out the source was a greyscale picture with 8x1 wide pixels
and another: serious pc arithmetic coding software failed at the EFMB title screen (an example of "abnormal correlation") even worse

To be honest I'm quite surprised how well LGK works.

and it still suboptimal very much!

[Lethargeek]

One thing I would really like to try one day is proper context -> prediction -> range coder packer.
I mean using pixels on west, north-west,north to form a 3-bit context and kind of range coder. It would be inevitably slow (I did some estimations and for 8-bit probabilities multiplying 16-bit limits I got liitle less than 1000 t-states per pixel -> about 400 ~ 500 bytes / sec) but it would really catch the cases where you have small illustration + text on screen.

do you have any estimates about the possible zx decompressor size?

[catmeows]

One thing I would really like to try one day is proper context -> prediction -> range coder packer.
I mean using pixels on west, north-west,north to form a 3-bit context and kind of range coder. It would be inevitably slow (I did some estimations and for 8-bit probabilities multiplying 16-bit limits I got liitle less than 1000 t-states per pixel -> about 400 ~ 500 bytes / sec) but it would really catch the cases where you have small illustration + text on screen.

do you have any estimates about the possible zx decompressor size?

Not much, I guess. 200 - 250 bytes perhaps.

[Nienn Heskil]

What about megalz packer?

https://github.com/emmanuel-marty/lzsa/ ... /README.md

Here is quite handy chart showing compression/speed ratio.

Necropost: what's 'Pletter5d'? Is there a newer version after 0.5c1?

[catmeows]

I d

https://github.com/emmanuel-marty/lzsa/ ... /README.md

Here is quite handy chart showing compression/speed ratio.

Necropost: what's 'Pletter5d'? Is there a newer version after 0.5c1?

Good question. I don't know.

[introspec]

Necropost: what's 'Pletter5d'? Is there a newer version after 0.5c1?

It is not an official version. When I was writing my own decompressor for Pletter, I realized that I can slightly change the format and allow for longer match buffer (up to 16K instead of the up to 8K in the Pletter 0.5c1). It worked fairly well, so I labeled it "Pletter 5d" and left it on the diagram. I am not really planning to release it, because it seems to be a bit of a dead-end technology. LZSA2 would work better for big(ger) data files with a lot of long matches, MegaLZ works better for data with a lot of small matches (e.g. graphics files). I do not think Pletter is particularly competitive.