[CF List] Re: png images

[Mark Wedel]

Jonathan Taporg wrote:

>
     
      > 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.
     
     >
     
     
     >
     
      Maybe, in that case, I'm just more sensitive to the difference.
     
     >
     
      And I'll grant you that maybe it is only for me that considers the
     
     >
     
      higher color graphics better.  But I think that we can agree that,
     
     >
     
      while there may not alone justify switching, I think that there is
     
     >
     
      enough evidence that a reason to allow full color is not
     
     >
     
      nonexistant.
     
     
 I certainly find it is the case that if you made the change, you are more aware
of the changes.  So I could certainly see you being more sensitive to changes
you have made to the images (since you know what changes you have made) you will
notice them more.


>
     
     
     >
     
      I made a point of checking what imlib does.  On 8-bit displays, the
     
     >
     
      loaded images are automatically dithered to a pre-defined palette of
     
     >
     
      common colors.  Furthermore, 8-bit imlib does not allocate a private
     
     >
     
      colormap, but merely takes whichever colors it can get.  To test it,
     
     >
     
      I ran the client in 8-bit mode, and many of the images were indeed
     
     >
     
      dithered and looked different than under 24 bit mode.  Thus, for the
     
     >
     
      GTK client, at least, it doesn't really make a difference if the
     
     >
     
      images are allowed to be 24 bit.  I'm not sure about the other
     
     >
     
      clients, though, ... once again, you'd probably know better than me.
     
     
 I don't know what the java and windows client do (or will do as I don't know if
they support png right now) in those cases.  Do you know if imlib allocates a
preset bunch of colors or just matches against other colors already allocated in
the color map?  Depending on what it does, they effects will change as more
images become truecolor.

 If for example it allocates a bunch of colors, that works fine.

 If instead is allocates colors and does color matching (and if it can't match,
then dither), then as more image become truecolor, the more problems you have
with image quality.  As described in my previous example, you could get a case
where the first couple images (if all are truecolor) consume the entire
colorspace.  Right now, just by pure luck you may get a representative color map
since most of the images use the crossfire representative color set, and in a
sense, that pre-seeds the colormap.

 Also, you did not say how the dithered (by imlib) truecolor image compares to a
standard image as we currently have it.  Is the result of imlib worse than what
we currently get with the images we have?

 As a sidenote, at some point, I would really like to get rid of imlib simply
because it is buggy, adds additional dependancies, and has lots of extra
overhead that is not really needed.  I would really like something like the Xpm
library for for png - a simple library that reads a png and converts it to a X
pixmap without having to save the data to a file.  Unfortunately, png still
seems to be in its infancy in terms of library support (even the referance png
library doesn't seem to have an operation to work on buffers, but instead wants
an actual file to work on, which seems really lame to me)

>
     
      The beauty is, while the entire color space would be 24 bit, 256
     
     >
     
      colors should be sufficent for any single 32x32 image, so images
     
     >
     
      could still be saved palettized.  There would be no size increase.
     
     
 I don't know much about the png structure, but I would note that right now, if
it supports a 4 bit image, that works fine for the current images we have.  If
you go to 256 (or actually, anything above 128), you are now an 8 bit image, and
have doubled the space for the image.  And certainly each color takes some
number of bytes.

 The easiest thing to do is compare the image sizes of some before and after
images you have done and see the size difference.  That is a much more accurate
way of trying to do it than figure out what png will do.