[CF-Devel] pngs, sorry don't send all of the last msg

[Michael Toennies]

Hi

I have done some work with pngs and i run in some glitches.

As the png lib writes, the transparent color of a png can be accessed
in a special way, i don't remember exact.

You must get the transparent index, and this shows of a table of numbers
which present the transparent colors ( or so).

The point is, as i implement it first time, it don't worked. Not with the
pngs
from the cf arches, not with paint shop from windows.

As i search, i find out, that the transparent index not would handled as an
index,
it was the number of the transparent color. As i handled it in this way, all
worked fine.

Now tells me AV, that there was problems with my png in linux clients. Also
program
von image magick (good picture tools) tells me some absolut different.

if i use the tool identify from it and use it on the behold_eye.png from the
cf lib (original)
i got this:

Image: behold_eye.111.png
  Format: PNG (Portable Network Graphics)
  Type: true color with transparency
  Class: DirectClass
  Geometry: 32x32
  Depth: 8
  Matte: True
  Colors: 13

       126: (  0,  0,  0)  #000000  black
        14: (  0, 49,  0)  #003100  #003100
         2: (  0,  0,127)  #00007f  #00007f
       695: ( 18, 52, 86)  #123456  #123456         <- ** this is the
background color **
        43: ( 99, 50, 29)  #63321d  #63321d
        16: (127,127,127)  #7f7f7f  gray50
         1: ( 45,138, 86)  #2d8a56  #2d8a56
        20: (175, 47, 95)  #af2f5f  #af2f5f
         9: (159, 81, 44)  #9f512c  #9f512c
        30: (249,127,113)  #f97f71  #f97f71
         6: (205,133, 63)  #cd853f  peru
        17: (191,191,191)  #bfbfbf  gray75
        45: (255,255,255)  #ffffff  gray100
  Filesize: 307b
  Interlace: None
  Background Color: gray100                  <------------- ??????????
  Border Color: #dfdfdf
  Matte Color: gray74
  Delay: 100
  Compression: Zip
  Signature: d04658dbef4acf6af0d88817099137e5
  Tainted: False
  User Time: 0.0u
  Elapsed Time: 0:01

Because this is the original, the transparent color is the #123456 one.
The linux client should find this out, my paint shop also knows this as
right color,
also my client use #123456.

But the image magick refer gray100?
Is the background color = transparent color? If yes, why the tool refer it
false? If no,
why are the transparent color is not list?

Now some strange come.
I find out, that many of the "full color" tiles like the mountains, which
not have any visible trans-
parent color, are broken for me.

- they are 16 or 256 palette pics with false color key (like swamp.111.png i
included)
- they are 16m true color pics. My client, but also paint shop etc. can't
find a transparent
  color, even the png refers no one.

Because it is a set format for textures and game pictures, in true color,
color 000 RGB = black
is transparent as default. Because there are more and more use for alpha
pictures, stencil mask, etc.
this is very useful. Also, many 3D cards works not in any case ok, when they
got fancy color keys in
true color textures.

For cf, in later years true color pics will come more and more. At the
moment there is no color key
we give them for there pics. That can cause some problems, if people start
to render pictures. They
have often more than 256 colors and can't saved as palette pictures. So we
need a default color key
for true color pictures.

Shown with image magick, this comes out.

At this point, its interesting to look what identify from IM gives me for a
true color pic
from the original cf lib:


Image: mountain_2.311.png
  Format: PNG (Portable Network Graphics)
  Type: true color
  Class: DirectClass
  Geometry: 32x32
  Depth: 8
  Matte: False
  Colors: 9

       174: (  0,  0,  0)  #000000  black
        30: (  0, 49,  0)  #003100  #003100
        67: ( 99, 50, 29)  #63321d  #63321d
         5: ( 99, 68, 18)  #634412  #634412
       237: (127,127,127)  #7f7f7f  gray50
        19: ( 45,138, 86)  #2d8a56  #2d8a56
       447: (191,191,191)  #bfbfbf  gray75
         5: (254,191,202)  #febfca  #febfca
        40: (255,255,255)  #ffffff  gray100
  Filesize: 1025b
  Interlace: None
  Background Color: gray100
  Border Color: #dfdfdf
  Matte Color: gray74
  Delay: 100
  Compression: Zip
  Signature: 94e2dee0ad7e65509c17e62257f5d153
  Tainted: False

But gray100 should NOT the color key... It can't be above too.

For this mountain picture with 8 colors, it absolutly nonsense to safe them
as true color!!!
they have about 1.100 bytes as true color, saved as 16 bit palette they have
about 500!!

There are many pngs in the arches which have the false format.

Some pics are simply broken. Many of the walls are use false color keys, no
colors keys are are
simply bug transformed, using background color = 0 and black as paint color.

A sample for a false set color key is swamp.111.png. 16 colors, but
transparent key is set as color
number 0, which is a blue. This is a bug, happens as the picture was
transformed from xpm, setting
color number 0 as transparent, but there was none, so it set it false.

I included some of my pngs i transformed. Please test them with your linux
client, copy them into
your cache. report when they are not loaded or strange thing happens.

At a result i find, thats not a hard work to make the pngs looks better than
xpm. Most bad views
come from a couple of bad pngs, some false set transparent color keys and
some strange pictures.

I have drawn about 125 new and you will see that the whole screen looks 3
times better.
With a little affort, we can make the change from xpm to png in a week,
believe me.

MichToen