pngcrush
Forum rules
This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.
Its current use is for the continued development of the server and game it has always served: TMW Classic.
Re: pngcrush
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 ...)
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 ...)
Former programmer for the TMWA server.
Re: pngcrush
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.
For now this means we could use pngcrush(great idea) in update.zips by adding it to the procedure for packaging content.
Head of the TMW Illuminati
Re: pngcrush
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:Looks like you forgot to include the alpha channel.o11c wrote:Speaking in hard numbers, plant.pnm, 12109 bytes uncompressed and 1126 bytes gzipped.
Former programmer for the TMWA server.
Re: pngcrush
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.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: 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.
TGA can be uncompressed, though it has the same color space/gama correction features as PNG, and so does not solve the issue.o11c wrote: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:Looks like you forgot to include the alpha channel.o11c wrote:Speaking in hard numbers, plant.pnm, 12109 bytes uncompressed and 1126 bytes gzipped.
A list of image formats