About Image compression, streaming, the meaning of life...

F

Fafalada

Veteran
That XBox thread was closed but I figure it's no harm done to continue this particular tangent (if not, mods can always close this too).

_phil_ said:
Goood tools exist, like ImageStudio (http://www.webtech.co.jp/eng/istudio/index.html)
Click to expand...
Like Archie mentioned, there are tools that practically embarass ImageStudio quantization (even when comparing it on IS's own PR examples).

Squeak said:
Why not? A 256x256 8bit only take up ~ 65Kb. Even if you only have, say 4Mb per frame, that's sixty-three high resolution textures in one frame!
Click to expand...
Common texture allocation in PS2 games is around 3-4MB of texture per scene (although this isn't based on a statistic of hundreds of games, I am going by examples of a few high-profile titles that I happen to know this data for).
Regardless, working with a texture pool sized 10-15MB per scene, I can tell you from personal experience that we were always juggling between using either lower resolution or more of 4bit (and this includes the use of JPeg and 2bit Luminance compression for certain texture types) - and the latter usually prevails.

From what I can see S3TC or DXTC, only has significant advantages if the source material is a large photo or similar.
Click to expand...
Actually that isn't quite true either, but rather then debating it I've coerced Archie to let me post samples on his web :p
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic01.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic02.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic03.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic04.png
These pics are rather large (Jpg's would defeat the purpose of comparison) so I can only post links.
Just to give you an idea where we are starting from, source image has 143000 colors.
I put up source, S3TC, VQ, and 8bit, but I leave it to you people to guess which is which first :p Just idle curiousity - and opening the image in photoshop and counting the colors doesn't count as a valid guess!

Streaming? Oh that's a subject matter for the next post.
 
If Halo were streamed from a DVD, you certainly wouldn't be able to go back to a section of the level as fast as you can now (under one second), nor would the DVD drive be as free to access more data or play back music. I'm sure the HDD is not inconsequential to the allowance of the texture and data set size used by Halo's maps.
Click to expand...

This is utterly false... First of all, the sustained throughput of the HDD on both Xbox and the PS2 isn't all that hot to begin with (roughly twice as fast on Xbox. On the PS2 the difference a little better because of the slow optical drive and faster HDD). HDD's *can* burst data random data much faster of course, which make them fine for caches, but if you're constantly streaming data, the benefit isn't anywhere near what one would think.

First of all, if you're streaming through a level there's going to be a certain amount of linear access (depends on the freedom of navigation within the game, entry points to other parts of a level, etc.)... With predictable access patterns seek times on an optical disc are easier to minimize. Also with predictable patterns you can more easily layout the data across the disc (obviouly moving as much as possible to the outer tracks).

Also, since you bring up HALO, the manner in which they traverse a level is the ideal method (e.g. moving through tunnels) to chunk your data. It's BAD that they still get the pause, since they're in an ideal situation to stream the data using the tunnel as a data loading mask...

That was never in question. What was baseless was the claim that the HDD didn't enable Halo to perform streaming beyond that of the example brought up, Jak2. Most obviously, the HDD allows you to jump back to a separate section of the level within one second, not possible with Jak2. If you've ever re-entered the level you were last in while playing Halo, especially after having turned the machine off, you realize this.
Click to expand...

I don't really think you can say HALO is streaming (other than music)... In any case unless you're talking about warping a character around, the part about bringing a character back to a separate section is somewhat unrelated to streaming since that's more of a function of level design layout.

Oh and the meaning of life is 42....
 
Another thing...

Obviously the hardware has *theoretical* limits, but getting anywhere near them (much like with graphics) is an art in itself... I've seen data loads (often in a title in early development) range anywhere from 60sec to 1sec on the same level/scene (without getting into an exotic streaming architecture) simply by managing your data structures more efficiently (of couse the extremely long times are examples of early stage development).

Of course not all streaming is implimented are implimented for smooth level transitions either... Quite a bit of streaming (and by that I mean audio, video, data simultaneously) is used to virtualize the hardware's storage (ADX's streaming tools being a pretty common example of 3rd party streaming tools being used in a lot of Sega's titles)
 
Re: About Image compression, streaming, the meaning of life.

Fafalada said:
I put up source, S3TC, VQ, and 8bit, but I leave it to you people to guess which is which first :p
Click to expand...
Blow up the following for my guess

Looks like source, 8bit, S3TC, VQ to me. I'm not convinced the S3TC compressor you are using is the best, the blocking artifacts are much worse than I expected. I'll check the MSE and see what kind of results I can get tomorrow. There also appears to be a small DC shift on palettised and a worse one on the VQ.
 
From a very quick look, I would say

pic01=Source
pic02=#8bit#
pic03=#s3tc#
pic04=#vq##

I would say the images are are ordered from best to worst.
 
I don't want this to drag down Fafalada's topic.

archie4oz, it was already covered that Halo doesn't stream its level in continuously like, for example, Jak2. It puts all the separate sections of a level on to the hard drive and then swaps the section currently in memory when you hit a checkpoint.

For a game like Halo that's set up to use loading screens and not set to stream in its level continuously (it's not even attempting to be seamless... the devs apparently gave diferent priority to their resources), this HDD streaming it does prevents it from having to go back to its longer loading screen when re-entering the level or warping around. Much of this could be accomplished with an engine that continually worked ahead intelligently and a level that was laid out in accordance, but the HDD certainly enhances streaming potential or adds a form of it (over just using the DVD drive) to games that otherwise don't try. If they had tried to build Halo out of continuously streaming levels, your points would apply.

A hard drive is great as an intermediary cache. A noticeable benefit is had from managing such large amounts of data and keeping them relatively local when you need them.

As for the pictures in the compression example, I guess this order:
***spoiler guess (don't know how to shrink text)***
*
*
*
source, 8bit, S3TC, and VQ.
 
Whoppie! Guess the mess time! On first look, it be looking like S3TC, VQ and 8bit BUT knowing Faf, i be think 8bit, VQ and S3TC. :LOL:

Is PS2 using 4bit most of the time? Can we have a 4bit one? OF coz, if only we can see such quality picture coming out in real world instead of the USUAL. :)
 
4 bit would suck on a picture this size...

But you could be creative - Make a polymesh following the major colour areas ( Hair/ Hands / Bikini Top etc ) and generate multiple set's of cluts..
 
Which compressor were you using? I can definitively say that whatever DXTC compression tool you used is pretty poor :)

I recommend The Compressonator. http://www.ati.com/developer/tools.html

If you can, recompress with the compressonator, reshuffle the numbers, and then let's have a real competition ;).

It does seem that the compressonator introduces a very slight DC greening shift into that image, which I have seen before (our best guess is that the asymmetry in the 565 colourspace causes this). One interesting point is that the Compressonator's MSE seems to be slightly worse than the other poor image (maybe because of the DC shift?), but it's clearly an order of magnitude better in quality.

Now I look again, there are some 'orrible JPEG ringing artifacts surrounding most of the high-contrast edges. This edge-sharpening effect does make the task somewhat more difficult for any compressor; I'd suggest repeating the test with a previously uncompressed image if you have one available. (It also explains why on earth the 'poor' compressor was generating overbright blocks).

It does make that image a rather aggressive test for block-based compression, while not affecting palettised compression significantly :)
 
Re: About Image compression, streaming, the meaning of life.

Texture Compression! Now we're talking!

I think I now might understand why you perceive S3TC to be worse than it actually is....
Fafalada said:
From what I can see S3TC or DXTC, only has significant advantages if the source material is a large photo or similar.
Click to expand...
Actually that isn't quite true either, but rather then debating it I've coerced Archie to let me post samples on his web :p
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic01.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic02.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic03.png
http://homepage.mac.com/archie4oz/.Pictures/Fafalada/pic04.png
These pics are rather large (Jpg's would defeat the purpose of comparison) so I can only post links.
Just to give you an idea where we are starting from, source image has 143000 colors.
I put up source, S3TC, VQ, and 8bit, but I leave it to you people to guess which is which first :p
Click to expand...

From a first glance in my browser (and Mozilla's tabbed browsing feature is wonderful for this), I would rate the quality, ignoring storage costs, as "Excellent", "Good", "bad" and "worse".

Now for the real comments:
  1. I assume that the first picture is the original (I zoomed in and it appeared to have some JPEG artefacts - in fact it has some very strange ringing artefacts).
  2. The second is probably 8bpp palettised: If you zoom in on, e.g., the lips, you can see obvious dithering. The RMS error between 01 and this is 8.6 which is reasonable.
  3. In the third there is considerable evidence of 4x4 pixel blocks. I suspect that this has used S3TC BUT whoever wrote the compressor should be fired immediately. That picture, compared to pic01, has an RMS error of 13.5 . That is not very good for S3TC.

    If you use a decent compressor, you'll get an error of 7.2 which is better than 8bpp palettised and also less than 1/2 the size.
  4. I'm therefore guessing that the last one is VQ compressed but I've no idea at what bit rate. The RMS error is 14.5 which, for such a smooth source image, is not great but I'm assuming the compression ratio is much higher than the other test images.

    Using the Dreamcast VQ compressor, this image gets a slightly better RMS score of 12.8 at an approximate cost of 2bpp. It does look a bit noisy though.
Out of curiousity I ran an old** version of the PVR-TC compressor on the image as well. (** I'm in the process of rewriting large chunks of it and so the quality is a bit off at the moment).

At 4bpp the RMS is 6.5, while at 2bpp it scores 10.1 which isn't bad for that compression rate.
 
I believe that Dio has correctly identified the pictures.

Howver, the DXTC quantiser used to create the DXTC image sucks in a big way - I tested it with my compressor here and got much better visual results - the terrible blocking around the right hand side of the chin is largely eliminated, and the blocking noise in the image generally can be massively reduced by a high quality quantiser. It is hardly fair to claim the benefits of a high quality palette quantiser, and then use a terrible DXTC quantiser.

In addition to this the palettised image is clearly relying on dithering to improve the apparent image quality, which is fine when viewed at 1:1 pixel:texel ratio, but when the same image is bilinearly enlarged (as typically happens with textures) the dithering naturally becomes highly noticable - just check out the lips or the large orange areas (;)) for good examples of this, and look at the 'graininess' as they are enlarged. You can't introduce highly-ordered high-frequency noise into an image and then expect it to remain unnoticable when that image is enlarged.

If you were to use this image as a texture then a DXT version kicks the palettised one's arse in terms of overall quality (assuming that you actually use a good DXTC quantiser)
 
Dio said:
One interesting point is that the Compressonator's MSE seems to be slightly worse than the other poor image
Click to expand...
From Simon's testing, it does seem possible that the Compressonator's MSE calculation is cream crackered (again).

Simon F said:
At 4bpp the RMS is 6.5, while at 2bpp it scores 10.1 which isn't bad for that compression rate.
Click to expand...
That certainly is pretty good. I'd be interested to see the results?
 
src, clut, s3tc, vq

re level streaming - i've played halo enough not to have a particularly high esteem of its 'streaming' capabilities. which is not surprising, knowing it started as a PC-targeted engine.

and finally the easiest part - the meaning of life, of course, is to make of it whatever you can
 
Dio said:
Dio said:
One interesting point is that the Compressonator's MSE seems to be slightly worse than the other poor image
Click to expand...
From Simon's testing, it does seem possible that the Compressonator's MSE calculation is cream crackered (again).
Click to expand...
Don't feel bad... the printed result in my old VQ compressor never worked properly :). I now use a standalone image difference program that is correct.

Simon F said:
At 4bpp the RMS is 6.5, while at 2bpp it scores 10.1 which isn't bad for that compression rate.
Click to expand...
That certainly is pretty good. I'd be interested to see the results?
Click to expand...
Well I don't have access to my home page at work so I can't post it at the moment and, besides, I'm always cautious about the copyright.
Faf': can you tell us what the copyright status is? Failing that, I suppose I can email it.

BLEAGH!! I've just noticed that there are some hideous bugs in the 2bpp version. I'm amazed it scored as low as 10.1 Looks like I'll have to add this picture to my test suite... Curse you, Fafalada!!! :?
 
cybamerc said:
I just used S3's own compressor on the original... the result is a whole lot better than the mess Faf created :p
Click to expand...
That's also what I used. Although ATI's compressenator gives almost identical results, it unfortunately won't run on my steam powered PC.
 
You must log in or register to reply here.
Back
Top