IFF ILBM Commpression Optimiser

[Trachu]

Hello

While doing graphics for Ryggar i have found interesting behaviour which would lead increasing or decreaseing commpressibility of standard AMIGA IFF files.

Lets take standard 16colour palette files.
We could have 16x15x14x13x12x11x10x9x8x7x6x5x4x3x2x1 combinations where each of the colour can be placed in different colour register creating in effect exactly the same picture (lossless) but different bitmap, which in the end lead to better or lower compressability of such picture.
I have included the examples for you to see. There si exactly 4621bytes difference between zip archive contain exactly the same graphics just with different colour registers used.

Such tool could be very usable for 64kB Intro makers, where every bit counts, but in generall use also.

Maybe someone know such tool and if not maybe someone could create one?

[Mrs Beanbag]

yeah! great trick! but how it works?

[Trachu]

its simple. Just swap colour positions:

alienvspredator640512-4c_output2.iff has such colours

0 0 17
68 68 119
204 221 238
119 136 170

alienvspredator640512-4c_output5.iff uses

0 0 17
204 221 238
119 136 170
68 68 119

Different colour positions is creating different 0 and 1 placement hence creating more or less compressible data.

[StatMat]

Interesting idea. Re-ordering the palette such that the RLE can be more effective on the actual bitmap data. Similar behaviour can be observed by re-ordering files in solid archives.

[thellier]

Nice idea

Perhaps the better palette can be predicted (vs try all palettes,pack,compare)
For each pixel count what kind of pixel change (from previous pixel) we have like color0 to color1,etc...

Then
we will obtain solmething like

color0 to color1 : 1300 pixels
color1 to color2 : 20 pixels
color2 to color3 : 400 pixels
color3 to color4 : 500 pixels
etc...

Then if the max occurrence is (say) color3 to color8 ==> adjust palette so that color3 and color8 would only differ on a single bitplane bit


Alain

[Cylon]

Interesting, indeed.
Well, for your own productions you can create an own IFF chunk for optimal compression. just need to adapt import/export plugins for e.g. PersonalPaint.

[Mrs Beanbag]

so ILBM performs run-length encoding separately on each bitplane? interesting...

so what is the algorithm for picking which colours to swap? is there an efficient way or just brute-force?

[Trachu]

Originally Posted by thellier

Nice idea

Perhaps the better palette can be predicted (vs try all palettes,pack,compare)
For each pixel count what kind of pixel change (from previous pixel) we have like color0 to color1,etc...

Then
we will obtain solmething like

color0 to color1 : 1300 pixels
color1 to color2 : 20 pixels
color2 to color3 : 400 pixels
color3 to color4 : 500 pixels
etc...

Then if the max occurrence is (say) color3 to color8 ==> adjust palette so that color3 and color8 would only differ on a single bitplane bit


Alain

Well for your information in case of version 2 which is the most compressible the situation looks like this

colour 0 (black) -147197
colour 1 (dark blue) - 89942
colour 2 (brightest blue - almost white) - 31913
colour 3 (middle blue) - 58628

in case of output6 which is almost as compressible

colour 0 (black) -147197
colour 1 (brightest blue - almost white) - 31913
colour 2 (dark blue) - 89942
colour 3 (middle blue) - 58628


i believe what you say is some option for optimisation, but it still depends which pixel is the neighbour of which, but i was thinking about normal PC program where speed is not an issue.