Talking about compression

[Simon F]

Well, then have the compressor calculate an error rate, and punt back to S3TC or uncompressed.

An uncompressed option for a block? How is that supposed to work? It's best to keep a constant bit rate and that's surely not going to work.

How about a 4x4 lossless integer DCT combined with a DXTC-style interpolation method. Compute the DCT, calculate a lookup table of interpolants for the coefficients.

I think you need to consider the magnitudes of the cooefficients. Most, post-quantisation, are zero and so you want to store those with as few bits as possible. Managing a variable bit rate, even within a block, is not pretty.

You start with 16 32-bit pixels, or 512-bits of data. Subsample chroma at 4:2:0 in YUV. Apply 4x4 DCT. Output is 10-bit precision integer coefficients. Quantize. Afterwards, we'll have 480-bits of information. ..............

I won't stop you having a go. I'd be interested to see the results

So we end up with a 2:1 compression from 512->256bit.

That's not very aggressive. You should aim for at least 4bpp ~ 6-8:1 to be competitive with the current solutions.

 

[ims]

Could someone explain the importance of JPEG2000 the the average internet user. I can see why its of great use for digital photography.

Ims

 

[London Geezer]

http://www.jpeg2000info.com/what/index.html

 

[MfA]

Most blocks of pixels can be accurately described by 2 planes and edges between those planes, this is why S3TC was such a good idea. Simon improved upon that by letting the 2 planes be gradiated, S3TC can encode a gradient but not a combination of 2 gradiated planes, and he removed redundancy between the blocks (too often the coded colors of neighbouring blocks will be near identical, that correlation is a bit too short range to ignore). S3TC was very good, and PVR-TC is essentially S3TC++. I dont think that for fast decodable fixed compression codes you are going to be able to do much better ... especially not with transforms, Id sooner try my hands at forms of VQ with a fixed codebook.

 

[Simon F]

Most blocks of pixels can be accurately described by 2 planes and edges between those planes, this is why S3TC was such a good idea.

I tend to think of S3TC as just trying to take advantage of the typical linear distribution of colours in a block. Plotting the pixels in a 4x4 block in an RGB cube, the pixels frequently are grouped along a line segment and hence two colours are chosen to represent that segment.

What I thought was missing from S3TC was that, apart from the localised blocks, it didn't try to use any correlation between UV coordinates and the colour values.

 

[MfA]

I tend to think of S3TC as just trying to take advantage of the typical linear groupings of colours in a block.

That might very well be what it tries to do, but the fact that at the same time it can efficiently deal with oscillations/edges between 2 colors is a great bonus.

What is the state of the art in creating the subsampled images for PVR-TC now if you are allowed to say? (I always thought it curious that you didnt simply try dilation/erosion morphological operators for a naive first try BTW ... seems to me the most obvious approach, more obvious than wavelets at any rate.)