On Saturday, 29 January 2005 13:49, Paul Surgeon wrote:
> On Saturday, 29 January 2005 12:54, Christian Mayer wrote:
> > Manuel Massing schrieb:
> > > Hello,
> > >
> > >>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:
> > http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html
> 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 photos.
> 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 am corrected once again ...
Norman just pointed JPEG 2000 out to me which is open source (and royalty free
for GPL projects) and far better than the standard JPEG most of us use.
It uses state-of-the-art wavelet compression and some of the comparisons I've
seen are incredible. It supports both lossless and lossy compression.
Some comparisons :
It could be worthwhile looking into if we need to store large images.
The SDK with source code is available at http://www.ermapper.com
Flightgear-devel mailing list