Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: images & caching.

>No prob -- conversion can be automatic or interactive.  Some of the tools
>are scripted, so that we could use some of the special effects possible
>with PNG (such as translucency -- I think that would be GREAT).

I actually couldn't get any of those programs to do exactly what
I wanted so I wrote my own conversion program last night. It
is about 200 lines of code... 

Basically I wanted to convert the XPM's to PNG in such a way
that the PNG file used an indexable palette instead of
RGB triplets or RGBA quartets for pixel info. This way each
pixel entry is just a number between 0 and 2^bitdepth. 
Tranparency is dealt with using the special 'tRNS' ancillary
chunk that basically has the same number of entries as 
the pallette where each tRNS entry corresponds to a pallette
entry. The tRNS entry basically says weather pixels using that
index are transparent or opaqe.

>> As a note - how do space usage compare on xpm vs png images?
>
>Words cannot express the difference.  It's that bad.  XPM doesn't even
>pretend to try to be small.

Well, instead of tell you, I'll show up:

-rw-r--r--   1 smf      staff       1017 Mar  8 14:20 GreatDemon.png
-rw-r-----   1 smf      staff      25000 Mar  8 14:13 GreatDemon.xpm

-rw-r--r--   1 smf      staff        211 Mar  8 14:21 baby_drag.113.png
-rw-r--r--   1 smf      staff       1020 Mar  8 14:14 baby_drag.113.xpm

-rw-r--r--   1 smf      staff        171 Mar  8 14:20 halfling.111.png
-rw-r-----   1 smf      staff        828 Mar  6 23:46 halfling.111.xpm

We are looking at about an 80% decrease in size  on average using
my conversion program. Other conversion programs won't be as good though
since they are more general case...

However I was thinking about something last night. If a client was
written that used PNG images, it would end up doing a lot of work
with them.. Basically it would be constantly merging (stacking) images
to be painted onto the screen.. Since by default PNG images are compressed
this means uncompressing the image, merging, and writing out a new image
when is then compressed. Performace is bound to be faster if the
images are left uncompressed which I believe is legal under the
PNG spec. 

On the flip side there is a big advantage to using compressed images too.
If we assume the client won't have a local copy of the images
and the average image size is about 200bytes, it is possible
to pack about 6 images into one packet and not have that
packet fragment. Tcp/IP header overhead is like 128bytes right?
Anyway, being able to send 6 images at a time would speed things
up a bit..

Stuff to think about.

>Anyhow, my point is that the sheer size of XPMs relative to any logical
>standard makes them slower to convert to and from visible format, if only
>by loading time.  PNGs also have a disadvantage is they're used in
>compressed format, but that's why PNG is never _used_ that way (only
>transmitted).

This relates to what I said about.. I guess it is possible to recieve
an image over the wire, Uncompress it (which means extracting the image
data and saving into a new file or buffer or whatever) and using the
uncompressed version from then on...

>> If we go by that - current features of XPM:
>> transparency
>> alternate color information for greyscale & bw systems
>
>> I believe most other formats loose the second point.  Ideally, if we go to
>>another image format, it would be nice to only have 1 set of images needed 
>>(ie, get read of the bitmaps that are their now) - simplifies stuff all 
>>around, and means less space used.  Unfortuantely, for black and white 
>>support, alternate color information is really needed (or do we maybe 
>>jsut want to make color a requirement?)
>
>IIRC, most other formats can supply two images at the same time -- it's
>just that it's an enormous waste of space.  I'd far rather supply the
>images seperately.

I think it is rather trival to greyscale an image but going all the
way down to black and white... That is a little different. The PNG format
however has lots of optional 'chunks' and one of these might be usable
to store greyscaling and b&w information. Worst case, you can spec out
a PNG extension for that purpose.  But that means modifying all the
image tools to recognize the extention and read and write it out
properly.

>> I think I'll experiment a little bit with PNG in windows
>> a see how it goes...
>
>> I would be curious on how good/the number of tools under unix for PNG.  
>After all, that is where crossfire is still developed for the most part, 
>so good support under unix is fairly important.
>
>If I were a Windows-only user I would never have heard of PNG.  PNG is
>currently strongest (best supported) on Linux, since PNG is designed as a
>free alternative to a proprietary system (GIF).

Well.. I checked out a bunch of tools and there is a fair amoutn of
support. Even Photoshop has PNG support but I'll never figure out
how to use that program.. However I'm not to impressed with the way
these programs handle PNG. It is hard to get programs to do what I 
want them to do. Like saving a PNG with a pallette instead of as a 
truecolor RGBA image..

What do most people use for XPM editing? Pixmap right? I bet it would
be trival to modify Pixmap to save files in PNG format too.

I think www.cdrom.com/pub/png has a list of image editors for
various platforms.

PS: libPNG 1.0 was just released yesterday after 3 years of development..
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: