[CF List] Re: png images

[Mark Wedel]

Jonathan Taporg wrote:
>
     
     
     
>
     
      Anyways, I've done some experimenting, with the following results:
     
     >
     
     
      ftp://ftp.ifi.uio.no/pub/crossfire/incoming/images.png
      
      
     >
     
      In the image above, the first column contains the original highcolor
     
     >
     
      tiles.  The second column contains tiles quantized to the crossfire
     
     >
     
      palette that you've provided.  The third column is quantized to
     
     >
     
      3/3/2 RGB, logarithmically allocated, and the fourth column is also
     
     >
     
      3/3/2 RGB, but linearly allocated.  Some of the tiles have "holes"
     
     >
     
      in them, but that's only because the quantizing program mistakenly
     
     >
     
      quantized to the transparent color, so I wouldn't worry about it.
     
     
 I don't know if that link better proves your case of needing 24 bit palette, or
proves the case that the current colors are fine.

 I opened it up, and generally find it very difficult to notice any difference
between the columns.  And this is a situation where I am taking my leisure and
putting my nose 6" from the screen.  This is not something people are likely to
do while actually playing the game.  Maybe others can look at this and give
their opinion on the quality to remove factors of monitor or display card.

>
     
     
     >
     
      Anyways, I think the linear 3/3/2 is garbage compared to the others,
     
     >
     
      So I won't even bother considering it.  Both the crossfire palette
     
     >
     
      and
     
     >
     
      the logarithmic 3/3/2 are fine on some images, but they have problems
     
     >
     
      with others.  The crossfire palette, for instance does a poor job of
     
     >
     
      the mage's purple, as well as the dark browns of the viking's shield.
     
     
 Note that the crossfire pallette is not set in stone.  If you find large holes
in the pallette, in can be expanded.  But I will note that you also get a
different behaviour if you start with all the colors and try to reduce down to
the crossfire pallette compared to using the crossfire pallete for the initial
drawing.  In any case where you start with an infinite pallette, there will be
holes in a reduced pallette you can not map against.  but if instead you start
with a reduced pallette, you may say 'well, there is no really good purple, so
maybe I'll use some other color for that'


>
     
      I'd like to clarify what exactly would get broken here.  First of
     
     >
     
      all,
     
     >
     
      I'm assuming that the server is independent of color depth color,
     
     >
     
      because it would simply be silly otherwise.  Also, in my cursory
     
     >
     
      examination of the client code (at least the gtk version), it didn't
     
     >
     
      seem that anything within the code would limit the display to
     
     >
     
      being 8 bit.  Thus, if I am not mistaken, the only thing that would
     
     >
     
      be broken by the inclusion of full-color images would be the
     
     >
     
      platforms that run on 8-bit displays, correct?  And even in cases
     
     >
     
      where the display is 8-bit, the program would still function,
     
     >
     
      although
     
     >
     
      the images with extra color would be quantized to the local palette,
     
     >
     
      right?  Which, if necessary, could be set early if the server were
     
     >
     
      to send a pixmap containing its ideal colorset early on...
     
     
 Server does not care about graphics.  You could send windows pict files for all
it cares.

 I'm not sure what imlib does when you try to load an image which it can't
allocate colors for (like on an 8 bit display).  I can think of two behaviours:

 1) Generates an error which I don't beleive the client currently catches, which
would crash the client.
 2) Does some color matching scheme against colors already allocated.  Note that
if all the images are true color, this can end up being really terrible, as the
first couple dozen images could fill the entire 256 color pallette, and all
subsequent loads would match against those colors.  Since the first bunch of
images are from the map, the characters starting location would largely dictacte
the color balance.  For example, if the player resumed underground, it is very
possible that color map will get allocated a lots of greys and browns, so when
you head outdoors, there may be only 1 or 2 greens allocated, so all the forest
& plants get allocated to that one color.

 In either case, better support is needed in the client.  One method is to
allocated a preset colormap to match against.  either the 8/8/4 (number of
colors) method of the 6/6/6 color method.  Neither produces really good results,
and may not be all that representative.  And from past experience with using
'xv' in a 6x6x6 color cube for 24 bit images, the results are really terrible.

>
     
      No disagreement here.  And I think that you'll notice in the
     
     >
     
      test image listed above, some of the tiles look pretty much the
     
     >
     
      same  when quantized down.  However, some of them don't.  And I'm
     
     >
     
      not sure that it's reasonable for artists to always have to check
     
     >
     
      if the color scheme that they want to use is well developed.
     
     
 Crossfire has been doing it that way for the past 7 or 8 years.  This may not
be the right thing to do, but it has worked out.

>
     
     
     >
     
      To take the argument a step further, I think it's necessary for the
     
     >
     
      default palette to do a good job with common stuff, such as walls,
     
     >
     
      characters, and common monsters, which I think it does.  Beyond that,
     
     >
     
      however, I would also say it seems acceptable if an artist is to make
     
     >
     
      a more exotic monster look good on a full color display, and for
     
     >
     
      users with 8 bit displays to see a quantized version which is
     
     >
     
      "good enough".
     
     
 I would be curious to see what the true color does to the actual image sizes
themselves.  I think that is also a consideration, as there is also a tradeoff
between nicer looking images and the increased space & bandwidth they cause.