change overview maps from bmp to png format

[Alberich]

A while ago we made some custom maps for our guild and saved the file by accident as png file with the ending bmp and to our surprise they loaded just fine.

 

I tried this again and converted a map to png and renamed the ending and it still works with the new client.

So why not change the maps to png and save some mb download in future packages?

 

At the moment IMG_Load_RW from the SDL_image package is used to oad images.

This is a simple library to load images of various formats as SDL surfaces.

This library supports BMP, PNM (PPM/PGM/PBM), XPM, LBM, PCX, GIF, JPEG, PNG,

TGA, and TIFF formats.

...

JPEG support requires the JPEG library:

IJG Homepage

PNG support requires the PNG library:

PNG Homepage

and the Zlib library:

Zlib Homepage

...

png is included by default due PNG_SCREENSHOT and Zlib anyway, so I see no reason why not.

Edited July 16, 2008 by Alberich

[Entropy]

Why png and not jpeg? I never liked the PNG format, for some reason. Yeah, I know, it's open and all that, but I still don't think it beats jpeg.

[rauch]

Because of quality?

 

Portable Network Graphics (PNG) is a bitmapped image format that employs lossless data compression.

JPEG typically achieves 10 to 1 compression with little perceivable loss in image quality.

[Roja]

If compressed well you will not notice a difference in quality. And I don't think making all the graphics png will help much with download size.

[Alberich]

If compressed well you will not notice a difference in quality. And I don't think making all the graphics png will help much with download size.

Yes, you're right.

zipped bmp maps are 6.44MB

zipped png maps are 6.40MB (i know it's useless to zip them)

 

I though because png libs are already included why not use them, jpg would need libjpeg.

But jpg maps would need only about 2.5MB (depends on quality).

[Florian]

cd $DATA_DIR
find . -name '*.bmp' -exec gzip {} \;
find . -name '*.elm' -exec gzip {} \;

 

This will give you a significant speed up on map change and the initial load.

[Entropy]

PNG with losless compression is garbage..

[Ermabwed]

cd $DATA_DIR
find . -name '*.bmp' -exec gzip {} \;
find . -name '*.elm' -exec gzip {} \;

 

This will give you a significant speed up on map change and the initial load.

Shouldn't this be done prior to distribution of the files then? (or in the case of the elm format be included in the definition/format)

[Learner]

cd $DATA_DIR
find . -name '*.bmp' -exec gzip {} \;
find . -name '*.elm' -exec gzip {} \;

 

This will give you a significant speed up on map change and the initial load.

Shouldn't this be done prior to distribution of the files then? (or in the case of the elm format be included in the definition/format)

Doing it before distribution increases the size of the distribution.

[LabRat]

How about a bit of both - include gzip (and the license text if required) and run the command immediately after installation completes?

[Ermabwed]

This will give you a significant speed up on map change and the initial load.

Shouldn't this be done prior to distribution of the files then? (or in the case of the elm format be included in the definition/format)

Doing it before distribution increases the size of the distribution.

So, speeding up a one time/rare event is more important than "significantly" speeding up every single map change? I must be missing something...

[Link]

cd $DATA_DIR
find . -name '*.bmp' -exec gzip {} \;
find . -name '*.elm' -exec gzip {} \;

 

This will give you a significant speed up on map change and the initial load.

Shouldn't this be done prior to distribution of the files then? (or in the case of the elm format be included in the definition/format)

Doing it before distribution increases the size of the distribution.

 

How about just offering two different distributions?

One large one for fast loading, One small one for slower connections

[Roja]

Guys...when you download files from our servers, well we PAY $$$$ for you to be able to do that. It's not free. So the smaller the file sizes you have to download, the cheaper it is, the better it is for everyone.

[Entropy]

So, speeding up a one time/rare event is more important than "significantly" speeding up every single map change? I must be missing something...

Well, since you are so generous with stuff others pay for, how about you fork over some moola to pay for the bandwidth?

[bkc56]

So, speeding up a one time/rare event is more important than "significantly" speeding up every single map change? I must be missing something...

Would it be possible to include a couple scripts with the distribution (like the above one for unix/linix) that people could run after installation to compress all the files? That would allow for a compressed download and compressed maps at runtime.

 

For windows (perhaps linux too) the script could be in the maps directory so all one would have to do is go to that directory and run the script. If it could be run from the installer, that would be even easier.

[Ermabwed]

So, speeding up a one time/rare event is more important than "significantly" speeding up every single map change? I must be missing something...

Well, since you are so generous with stuff others pay for, how about you fork over some moola to pay for the bandwidth?

Sure. I don't know what amounts we're talking but I send you 200 USD, hope that helps.

[Entropy]

Great, thanks (I confirm getting the moola).

Well, I guess we can do that starting with the next update.

[trollson]

JPEG vs PNG

 

The (lossy) encoding used by JPEG (discrete cosine transformation) is great for natural images (photo-like). It is very good at encoding gradients and smooth transitions. In these cases it can be preferable to PNG, producing smaller files (depending on your encoding engines).

 

However, if your image contains significant detail in lines or edges (eg, text, diagrams, screenshots), then JPEG with any compress will rapidly make that information illegible. Before PNG we'd use a lossless encoding such as GIF or TIFF for these¹.

 

Maps contain significant detail in lines and edges, so PNG is more appropriate than JPEG.

 

If EL's in-game maps are intended to contain details of this type as well, then use PNG rather than JPEG².

 

 

 

Illustration from Wikipedia entry on JPEG:

This image shows the pixels that are different between a non-compressed image and the same image JPEG compressed with a quality of 50%. Darker means a larger difference. Note especially the changes occurring near sharp edges and having a block-like shape.

Illustration from Wikipedia entry on PNG:

Composite image comparing JPEG and PNG: notice artifacts in JPEG versus solid PNG background.

Footnotes:

1. The only lossy encoding which keeps detailed lines would be wavelet based, which would be non-standard and comparatively expensive to encode/decode.
   
2. Alternatively, there is no need to use any published format for an image/texture only intended to be consumed by the EL client; just a gzip'ed dump of the byte array used internally bypasses any need to deal with image formats. Then a couple of simple tools to convert to/from established formats for internal use. First descriped in "Texture Masking".
   

Edited July 21, 2008 by trollson

[amedee]

PNG with losless compression is garbage..

Is it possible that you are confusing PNG and JPEG?

Shouldn't that be: "JPEG with lossy compression is garbage"?

Losless means you don't loose any quality, and lossy means that you do loose quality.

 

My two cents.

[Entropy]

What I am saying, the losless compression is not required for most of the things, and the jpg with a high compression rate looks almost identical as the original image, but at a much better file size.

Anyway, with the new engine we are going to use natively compressed textures, which means that they will be compressed in the same format the videocard compresses them.