Optimising Nexuiz files

[Ed]

progressive jpegs crash q3a engines too and choke the q3map compilers

This may well arise because not everything correctly handles JFIF. It is not that well standardised across different applications. My phone won't show black and white JPEG's for instance.

If it causes problems for level builders then it would be ebst to avoid progressive JPEG. Even so, all of the other optimisations should save 20Mb from the download.

[xcooling]

ed would you mind forum posting or sending me the scripts.

(with progressive jpeg removed, i know from quake1 retexturing, progressive jpg's create a huge overhead).

I agree they should make a big difference, and a smaller download means players can download the game faster and get playing quicker.

Also not to mention the reduced resource usage.

Maybe the next release of nexuiz could be optimised, who knows.

[tChr]

What are you talking about. orogressive jpegs should not be smaller than baseline ones.. baseline optimized is another matter.

[xcooling]

jpegtran -progressive -outfile $a $a #.prog $a

ie.
if you decide to post your shell script publically, post your shell script with that line removed

[Ed]

@xcooling: AFAIK Nexuiz 2.0 did use a lot of these optimisations. Div0 implemented it I think. This is why Nexuiz 2.0 isn't that much bigger than 1.5 despite having a lot more stuff in it.

I'll try and post my Tinynex building script some time which uses all of this stuff. Right now I've got to work out how to convert TGA's to JPG's while getting rid of the .tga file extension.

Have a look at the TinNex 2.0 thread in Nexuiz > General for some other stuff like this.

@tChr: Baseline > Progressive is truly lossless and vice versa. Sometimes one can be smaller, sometimes the other. This is why I've done this:

Code: Select all

jpegoptim --strip-all --quiet $a   # Optimise JPEG's losslessly
jpegoptim --strip-all -m95 --quiet $a   # Cap JPEG's at m%
jpegtran -progressive -outfile $a $a
jpegoptim --strip-all --quiet $a   # Optimise JPEG's losslessly
jpegtran -progressive -outfile $a $a

This is confusing but as each jpegoptim process chooses the smallest file size, this will give the smallest JPEG whether it's baseline or progressive.

In my experience larger higher quality JPEG's are better in progressive form but when trying to make a Tinynex like build, it didn't help at all.

[xcooling]

progressive makes smaller files, but causes more cpu and game engine usage to handle and load the files.