The daimonin.p0 (daimonin.0 on server side) is simply spoken all png images of the collected arches concenated together (with a additional header for each image)

A PNG file consists of serveral different chunks. Some of them are crucial (like header, imagedata, palette...) some of them are only extensions, (like timestamp, text-annotations....).
The imagedata itself is compressed in a two step process. The second step simply compresses the data from step 1. The compression ratio is determined by the data to be compressed.
Data like 1,3,4,5,6,7 is really bad for compression (with the deflate used in png), so the in step one, the data is filtered with some lossless reversable filters, like a difference filter, which leads to data like 2,1,1,1,1, which is much much better to compress.
For PNG exists different filters, with different quality of 'good-to-compress' output. The thing is, not all graphic programms have all the filters, esp the Paeth-Filter, which is most of the time the best.
Note: indexed images normally don't use any filter, but we are on the way to true color, so this will become more and more important.

But back to the chunks.
I have looked in some of the arch images, they were around 250 bytes in size, and contain a text-annotation chunk with the creation time as string with a lenght of around 50(!!!) bytes.
While such annotations in the source pngs are not bad, they are absolutely nonrelevant for the client. But since the the editor simply uses the source images in the collection progress, we have a bit overhead in data which is absolutely useless for the client.
I think with chunk-stripping that file could be around a fifth smaller.

There are some commandline tools which can remove such chunks, and also recompress the image with a different/better filter, like crushpng, optipng...

I would like to see that the editor can optionally handle the arch collection with that tools.

I know that would create external depencies for the editor, thats why i said optional.
A MapWizard don't need a small daimonin.p0 file, but a server-admin (which has the knowledge to install such a tool) which want's to release a client update/release.

So who wants to do that?

It seems no one wants to to it, so i will write a quick and dirty programm that goes through the arch folder and recompress all png it can find

I know nothing of gfx, so I'd just mess it up.
I agree daimonin.0/daimonin.p0 size should be reduced if possible.

i also agree that this should be done and that creation time is fairly useless, but even being an somewhat-artist, i have no idea of how to do this.

Ditto to planes

Unislash

i just let a pngoptimizer run over the trunk/archs dir and it saved around 1,2MB from 7,2MB imagedata.

It won't make a client release that much smaller, because the music is big, but its a start.

EDIT: if anyone wants to try it (linux):

Download pngout from here: http://www.jonof.id.au/index.php?p=kenutils
(its not OS, but free to use for comercial as well non-comercial things)
then a simply
from inside the arch folder should do it (haven't tested it)
NOTE: all pngs get overwritten, so better make a backup.

EDIT: for windows:

get pngout from http://advsys.net/ken/utils.htm

open the commandline, cd in the arch dir
type
(you need to have pngout in your seachpath)
or make a .bat for
Here also the images are overwritten

Nice job Alderan.

What would be the ultimate goal?

AFAICS:[list=1]

• We want PNGs to keep their comments, etc. in the uncollected arches, ie in SVN, to maintain credits, etc.
• Ragnor was not keen to put such a feature into Gridarta (which collects the arches because the server can't/there isn't a standalone collector.[/list:o]
  
  Looking at the wikipedia entry for PNGOUT, I'm not clear. This doesn't remove comments, etc. anyway? It (just) compresses the image data more?

1.) yes the uncollected arches should'nt be modified.
2.) i know thats why i said as optional feature, but we can also do this local, and afterwards collect the arches from the recompressed stuff, for release packages, and so on.
Also the bw needed for missing faces which are send to the client would be smaller

Beside the LOSSLESS recompress (PhotoShop for example is one of the programs that store pngs very inefficent) it can (and do as default) remove all unneeded chunks, like comment chunks, from the png file.