-----BEGIN PGP SIGNED MESSAGE-----
Paul Surgeon schrieb:
> On Saturday, 29 January 2005 12:54, Christian Mayer wrote:
>>Manuel Massing schrieb:
>>>>I do have a few questions though :
>>>>Does the current code that you have handle texture paging?
>>>Yes, textures and geometry are paged and decompressed asynchronously in
>>>the background (seperate thread). The engine supports image compression
>>>to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression.
>>>The first maybe quite taxing on the CPU, so we usually only use JPEG for
>>>the finest detail level textures, which account for most of the data, and
>>>S3TC for the lower detail levels.
>>Do you know:
> There's still no open source alternative to jpg when it comes to storage size
> and storage is the major issue when dealing with lots of satellite or aerial
> I did a test with the 18 century crop texture :
> JPG : 1024x1024 @ 85% quality = 508.4 KB
> PNG : 512x512 @ level 9 compression = 630.4 KB
> Four times higher resolution with hardly any noticable loss in quality (even
> when zoomed in) and it still comes out with a smaller footprint than a PNG
> that is 4 times lower resolution.
> Sometimes size does count.
> What do you suggest as a replacement to JPG that will give a similiar
> footprint size?
(I haven't read the Jpeg2000 stuff, so I don't know if it fixes the problem)
The trouble with JPEG isn't that it's lossy (you need that for hight
compression ratios) but that it uses an algorithm that is tuned to the
For normal photographs that's great - for textures that get scaled,
projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore.
An extreme example: when you use a very high compression rate you'll see
the blocking artefacts. So you use a not so high compression and are
hapy with the result. If you zoom into the picture you'll start to see
the blocking again as the pixels got large enough.
When you use that picture as an texture and fly low enough you are
basically zooming into the "picture". Same problem as above.
So JPEG isn't usefull.
So what's the solution?
1st: I don't know.
2nd: Use an compression that doesn't introduce visible artefacts (i.e.
artefacts that can be shown by zooming, projections, lighting, etc.)
One solution that might work could be wavelets. (This is where JEPG2000
gets interesting again). But the wavelets used would need to be choosen
You could also try your own compression format (i.e. one that is
simmilar to the wavelet approach). Roughly do:
Convert your image/texture to HSV, convert the whole picture (not small
blocks like JPEG) to frequency space (i.e. fourier transformation). Then
discretisize that values. In our case the high frequency are very
important (-> high resolution) and the low frequencies hardly matter (->
just a few bits).
But doing this is an project of its own. Epecially when you need
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Flightgear-devel mailing list