New compression method. Can this be used for textures in N5?
- Thread starter PC-Engine
- Start date
Mmm, pretty hot. ^_^ If it pans out, I'm sure it'll be lusted after by MANY folks. 
I think they are showing a scaled down result (given that the original was 3MB!) . The text associated with the image saysGrall said:
I would think if you did crank up the compression rate of standard JPEG you would indeed end up with (pretty much) only the per-block DC components.
randycat99
Veteran
I'd say the compression factor of the wavelet compression, given the maintained quality, is pretty impressive (with subtle to medium increase in banding as the foremost artifact, IMO), but considering that the original image isn't exactly pushing the limits of image quality, maybe the whole truth isn't being represented here? (How's that for a run-on sentence?) Banding and color graininess is still fairly apparent in the reference image (for a 3 MB file), so this would tend to help out the wavelet sample image as far as not looking so different. Additionally, it appears the reference image has been given the "softening treatment" which would also ease the demands of downstream compression. If the reference image had not been so digital compromised to begin with (more like a high quality image), we would be seeing much more noticeable effects in the wavelet sample image. I'd go so far as to say that the reference image is much more like a current day jpeg image at a moderate to aggressive compression setting.
I very much doubt it. You can read how PVR-TC works if you want (a paper's on my website). It's quite different to VQ approaches; more vaguely along the lines of the BTC family (block truncation coding) family except that it really doesn't have blocks at all.Squeak said:
Two guesses are that maybe they've used a 2 stage approach where the errors from VQing are fixed by another stage of VQ, or perhaps they're using IVQ (interpolated VQ) where, again, the errors from a low quality image are corrected using VQ. <shug>
Actually, the banding might actually make it harder! I don't know what family of wavelets are used in JPEG2000 but if, for example, they are using linear wavelets, then banding or noise in the source image would make it more difficult to compress.randycat99 said:
The problem with JPEG is that, IIRC, every 8x8 block is 'independent'. With wavelets, you can easily share information between neighbouring regions of pixels (predicting pixels) which potentially saves a considerable amount of storage.
randycat99
Veteran
Simon F said:
True, if there is banding in the original image, then that is much like an "extra detail" that will have to be encoded. The compression algorithm typically cannot discern what is genuine high-frequency detail and what is just an artifact or noise that has crept into the original image. However, that would seem to stress an entirely different thing than encoding an image that is free of banding and then maintaining that level of continuity in the output image. If there is hope for the digital image/video future, I would hope that the "people in the know" are concerned with preserving continuity not finding better ways to represent banding.
All of this just makes their [the people who hosted the sample images above] choice of sample images all the more strange. I mean, what is so impressive about preserving banding artifacts from the reference image? If they were interested in showing how detail is preserved, why did they soften the reference image then? That way they would have the opportunity to let the continuity in the "real" reference image show through to the output image, as well. Altogether, it could have been a more representative sample of what is really possible with the compression standard. Of course, I don't know what their original intent was, so maybe that has a lot to do with this disparity.
Simon F said:
Long distance correlation isnt the issue so much IMO, although borrowing neighboring pixels is the solution ... the main problems of DCT are that it cant sparsely represent parts of an image with a simple constant gradient and blocking (by the time JPEG tries to apply DC&AC prediction the damage is already done really). Using a small overlap in block coding can solve both these problems at the same time, and there are reversible non expansive transforms which can accomplish this overlap so you dont even get an expansive transform.
Getting optimum memory locality out of wavelet transforms is an extremely painfull excercise, and afterwards it is of course still slow compared to block transforms. Given how much performance you can get out of the 8x8 DCT with extremely simple pre/post-filtering and better entropy coding (as shown here) wavelet coding just isnt worth it for images IMO.
Hell I think transform coding is not needed at all ... Simon should add VQ to PVR-TC (for the colour and modulation maps) and beat JPEG-2000 silly
MfA said:
I can't say I agree. If you use linear wavelets (e.g. CDF(2,2)), then you only need the last four rows of your image in the cache.
The bigger bottleneck IMO is still coding / predicting.
Shameless plug: Have a look at my wavelet-image compression which does this (but it's no JPEG2000 --- but therefore a whole lot simpler) and comes with source-code.
You are competing with a transform which only has to fetch data from memory once for the entire transform. If you limit the number of levels of decomposition to a smallish number you might be able to only need to fetch data into L1 once through "cache blocking" of the transform, but it will need more than simple interleaving of horizontal/vertical filtering steps for a single decomposition. To me that is a chore.
Encoding complexity is not a big issue, decoding moreso.
PS. are you still planning to work on a video codec? (I think your idea is a little too far out there, but Id love to see what you can do
Encoding complexity is not a big issue, decoding moreso.
PS. are you still planning to work on a video codec? (I think your idea is a little too far out there, but Id love to see what you can do
Simon F said:
Doesn’t the BTC family do vector quantization within the blocks? I don’t know how many other compression methods use VQ, but I would imagine that even waveform/DCT based compression methods would benefit from it.
I’ve read the two papers on PVR-TC, and to me it seems to be an advanced form of YUV compression? Is that right?
One thing I haven’t been able to deduce from the papers is why exactly you need two low res base textures (A and B). It seems to be the whole point of the scheme, otherwise it would “just†be hardwired doublepass textures?
I realise that somehow memory is saved, by blending two 16bit textures, but I don’t see how?
Haar wavelets are mentioned, but they only seem to be used for splitting high frequency from low frequency, not for actual compression.
I don't see that necessarily the case. For a small neighbourhood of pixels, each wavelet transform only requires a small foot-print of low frequency + delta values. You can cache a small set of these values from each "level" of the frequency heirarchy and maintain quite reasonable coherence - AFAICS. You just gradually update this data as you scan through the compressed image.MfA said:
Ha. I suppose we could throw BWT into the mixture as wellHell I think transform coding is not needed at all ... Simon should add VQ to PVR-TC (for the colour and modulation maps) and beat JPEG-2000 silly
AFAICS, the idea generally seen in BTC is to pack every block separately; CCC (colour cell coding) did drift a bit from this because it had a palette, but S3TC returned to the independent blocks. I suppose, in a sense, you are doing some VQ within a block but the palette is rather tiny (2 or 4 colours), but when I've seen VQ mentioned, you generally think of global systems.Squeak said:
Gosh no. It's independent of YUV although you potentially could use it to encode the two low-frequency images. (I did try it and decided it had just as many disadvantages as benefits).
Well you want two (or more) but that's not the point. Err I really don't think I could summarise the whole paper in just a few lines!
On the 4bpp mode you have 2bpp modulation plus and an average of 2bits of colour.
No, any mention of haar wavelets should refer to someone else's compression scheme. I've also only used linear wavelets as a means of implementing a low-pass filter that's close to "the ideal filter" for linear reconstruction but much cheaper.
Similar threads
