The Mana World Forums

One sadness is that whenever a program like pngcrush is applied, it makes the repository bigger. And once it is accepted to use such programs at all, there tends to be a war over saving a few bytes (e.g. with optipng), despite the fact that this means the history can't be shared at all.

However, it would indeed be beneficial if we do it once, and possibly add a commit hook to prevent images. Sadly, commit hooks have to be enabled manually in the individual repositories ...

In the long term, I'd like to switch all the graphics to a minimal, uncompressed format (probably PNM), since uncompressed images are smaller both in the repository and in the update zips. Or is there anything stopping us from doing that now?

I do *not* think a hypothetical future client that accesses the images directly is sufficient reason to not switch to uncompressed versions. But HTTP offers transfer level compression anyway, and there *is* an nginx module that can be used to prevent recompressing the file every time on the server side.

Speaking in hard numbers, plant.pnm, 12109 bytes uncompressed and 1126 bytes gzipped.

(Note: even though most of our images are going to be PPM, I suggest using the pnm extension so that tools can automatically use PGM or PBM if appropriate. This is only non-beneficial if an image switches between the formats over time ...)

I would suggest that there be a development/production split. The repository can contain images in whatever format makes the most sense. When packaged for release (or hourly/nightly for development content) the files can be converted in scripts that build the release. This way nobody has to worry about running conversions/optimizations before every commit and nobody will have the ability to be sloppy. It will also prevent repository bloat.

For now this means we could use pngcrush(great idea) in update.zips by adding it to the procedure for packaging content.

cody wrote:

o11c wrote:Speaking in hard numbers, plant.pnm, 12109 bytes uncompressed and 1126 bytes gzipped.

Looks like you forgot to include the alpha channel.

Ah, I forgot that PNM doesn't support alpha (unless we use PAM, which is fuzzily supported). What does that leave for uncompressed formats?

cody wrote:Could we use pngcrush for ancillary chunk removal from all our PNGs? It reduces the file size and more important it makes the graphics look the same everywhere. An example for how different pictures are displayed is shown here.

The dyeing system used by TMW can turn even small differences into very visible pixel errors. This causes a problem for mana.js. For example:

Cobalt Plant

The pixel values differ depending on the OS and on the browser. With pngcrush the pixel values are the same everywhere and the file size of plant.png is reduced from 4532 bytes to 1289 bytes.

One of our artists ran into this a few months ago with graphics looking different in different programs/on different OSes because those chunks are completely optional so not every program will respect them. Getting rid of them was discussed.

o11c wrote:

cody wrote:

o11c wrote:Speaking in hard numbers, plant.pnm, 12109 bytes uncompressed and 1126 bytes gzipped.

Looks like you forgot to include the alpha channel.

Ah, I forgot that PNM doesn't support alpha (unless we use PAM, which is fuzzily supported). What does that leave for uncompressed formats?

TGA can be uncompressed, though it has the same color space/gama correction features as PNG, and so does not solve the issue.

A list of image formats