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

Re: Binary standards for images and sounds



 This is not a direct reply to the image format posted by Carl, but
a few notes.

 XPM files can handle up to 24 bit colors (I believe) per image.
It can change the number of characters for each each pixel.  By default,
it uses 1 character per pixel (About 96 colors I think).  But 2 charcter/
pixel, 3, etc, are all allows.

 Also, the XPM image format is somethign like this for colors:

(charcter) c (color name) m (monochrome name) g4 (4 bit greyscale) 
g (normal greycale)

 So an example might be something like:

A c blue m black g4 grey30 g grey 50
B c blue m white g4 grey90 g grey 90

 So on color, both the A and B pixels woudl be blue.  On monochrome,
the A pixels would be black, B pixels white.  And so on fro the
greyscale.

 While this does not really allow color to monochrome conversion, it allows
the drawers of the images to set the monochrome names to be used on
those systems.

 Very few of hte XPM images in crossfire have been set so, but I have
done (and checked) that all the potions work as expected.

 By default, XPM will, if monochrome or greyscale is not specified, convert
the color name into the closest equivalant (such that browns would be
turned into blacks, but yellows and oranges will be turned into whites
on greyscale.  And I would imagine that the approximate grey levels would
be done.)

 The real point is that more the one image format really does not need
to be stored on the server to handle different display depths.  It
would be (I suppose) up the client to convert the XPM data it gets
into whatever format it uses (and even for the same client, it could
be different depths (ie, on unix, some people have color, others
monochrome.  A client installed on the same site may be supporint
different display types).

24 bit color: While XPM will support this (even in one image), there
is not 24 bit color field in the XPM images.  1 color field for all color
types (8 bit, 24 bit, and any other ones that may be out there).

 The reason the about 30 colors was chosen for XPM images as it is now
it to not overflow the colormap on 8 bit images.  The XPM library does
have some facilities for close color matching if the color table is filled
up, but with default loading this could have problems, like the first
image using a lot of the same general colors (for example, and woods or
grass area, using ltos of greens).  Depending on the loading, this could
mean that the colors allocated are not a broad sample (maybe you ahve
120 greens, 80 blues, and just a handful of the rest of the colors).

 The solution for 24 bit bit could be for the client to allocate a color
table (possibly private) with a broad array of colors, and have the
loader use this color table, with color closeness.

 However, I don't think 24 bit will happen in the immediate future.  It is
takign a little while just to convert the images to '5 bit' (30 colors or
so) images.  Conversion of 24 bit would certainly take a lot longer, and I
am not sure how much of a gain there would be.

 Also, for client/server, the XPM images will be stored in non montage
format for sending to the client.  So if the client just wants the
picture of the ogre, just those 24x24 XPM files get sent, not he entire
montage.  This has the advantage that new pixmaps can be added and sent
down the wire quickly - you don't need to send the entire montage.  As
I stated before, the client coudl store these however it wants (perhaps
making a montage if it speeds up loading).

 --Mark