A Comparison of Several Texture Compression Schemes /PS2,XBOX .../

[Fafalada]

I don't think you can use the IPU to compress CLUT textures

I think he probably meant IPU can quantize unpacked textures for you.
Anyway in my experience you can get acceptable results with IPU JPeg at around 0.5bits/texel, so I'd say it's a pretty valuable compression when used right, especially when you have lots of animated stuff obviously.

On the whole you'd probably be better off getting the EE to unzip textures.

It may be lossless but it costs a lot of CPU time (which we never have ), and is roughly an order of magnitude slower. Granted in streaming environment you're bounded by slowass external drive, but you can still save CPU time regardless.

The problem is that GS decompression happens after synchronization with path3 and potentially can stall geometry xgkicks

Well there are methods that work as multipass rather then 'unpack before use'. Still a performance tradeoff either way, but effects will probably vary in each application.

 

[Simon F]

It's probably possible to compress 4 or 8bit CLUT data with jpeg.

I'd be stunned if you can tell us how! What would you compress? The LUT? That may stand a very slim chance if you arranged the 16 or 256 colours into 4x4 or 4 8x8 blocks and then ran a DCT + quantisation on them. In all honesty, I don't think there'd be enough coherence between colours to give a sensible result.

As for trying the same trick with the indices - well, you can't have lossy compression on those because being out by one bit in the index could be catastrophic for the image. For example, changing the LSB of an index that references dark blue could result in one that indexes lurid pink!

 

[Fafalada]

I'd be stunned if you can tell us how!

I think he phrased this badly
The idea is that you can give IPU a CLUT, and when it unpacks your I-Frame you get a quantized texture output instead of 16/32bit.

 

[MrWibble]

I think he phrased this badly
The idea is that you can give IPU a CLUT, and when it unpacks your I-Frame you get a quantized texture output instead of 16/32bit.

As I understand it, the IPU can only quantise 16-bit data down to a 4-bit CLUT image and you won't even get dithering. I doubt that would be useful in too many cases.

I did once toy with the idea of getting the IPU to decode heightfield data because I figured an average map at high-resolution would compress pretty well, and then decompress visible sections as necessary. Never got around to trying it though.

 

[Fafalada]

As I understand it, the IPU can only quantise 16-bit data down to a 4-bit CLUT image and you won't even get dithering. I doubt that would be useful in too many cases.

Well seeing as you need a CLUT before hand for this to work - you would only use it for a texture that was already converted to 4bit once (but you could still use the 32bit source to compress into I-Frame, the palette should match up well enough).
The real downer here is that IPU can't perform both operations in single pass (I-Frame decode + quantization) and that consequently foils attempts to do CPU free IPU chains. (although I did have this theory about using SPR with a looping DMA to do it...).

But yea, 8bit would be nicer either way, and 16bit worked well enough in the end for me.

I did once toy with the idea of getting the IPU to decode heightfield data because I figured an average map at high-resolution would compress pretty well, and then decompress visible sections as necessary.

It should likely work quite nice - I think most people failed to realize how fast this thing was, I've benched the realworld usage at up to 90MPixels/sec. That's enough for ~90 128x128 textures per frame at 60hz.

 

[MrWibble]

Well seeing as you need a CLUT before hand for this to work - you would only use it for a texture that was already converted to 4bit once (but you could still use the 32bit source to compress into I-Frame, the palette should match up well enough).
The real downer here is that IPU can't perform both operations in single pass (I-Frame decode + quantization) and that consequently foils attempts to do CPU free IPU chains. (although I did have this theory about using SPR with a looping DMA to do it...).

Ok, I just did a quick and dirty experiment - I took a 512x512 source image (the original Lena image, as used by Simon) and dithered it down to 16 colours. Then I converted it back to 32-bit and jpeg'd it, choosing a compression that output an image roughly half the size of the 4-bit CLUT version (I figured you'd want at least that much of a saving for it to be worthwhile). Then I reloaded the jpeg and converted it back to 16 colour using the original palette and with no dithering.

The result is passable, but it's lost a lot of detail over the original palettised one. Mostly any area where there was a lot of fine detail has been blurred out, especially anywhere the original 4-bit image was dithered.

Of course this texture isn't massively suited to being a 4-bit image in the first place, but I'm only comparing 4-bit results, not error back to the 32-bit version.

I think it might work better if the texture has more flat colour in it, rather than detail. Then again, a fairly simple run-length encoding would give you a win there too, and maybe for minimal impact on the EE... (but you're right, EE time is always the most valuable!)

 

[Squeak]

That is more or less the exact experiment I did once, to see if it was even possible to get an acceptable result.
Pictures with limited colour palette seemed to get the best result for me though.
At half the size compression, my picture looked virtually indistinguishable to the original non jpeged.