[Plplot-devel] Progress on colour images for plimage

[Alan W. I. <ir...@be...>]

I have a nice example of a colour image displayed by plimage, but I haven't
checked anything into cvs yet because some rough programming edges still
need to be smoothed.

One problem is that the cmap1 palette is indexed continously in the range
from 0. to 1, while a colour palette from any typical image is in
pseudo-random order.  (and it is not clear how you would sort it since the
colour palette typically corresponds to points pseudo-randomly scattered on
the colour sphere rather than some line.) Thus, you must be extremely
careful of off-by-one problems when translating internally within the plplot
core back from the 0. to 1. range to indices from 0 to ncol1-1.  Once those
off-by-one problems are solved (and there are plenty of them), then in the
xwin driver (which is the one I have used exclusively because it is the only
fast implementation we have at the moment) there is a further interpolation
from the range 0 to ncol1-1 to the range 0 to 199.  I suppose there is a way
to do that properly, but I haven't found it so it always makes a colour mess
with one exception; ncol1 = 200 works like a charm (since it effectively
bypasses that last interpolation).

Right now I can use the netpbm package to (1) transform any sort of image to
pnm, (2) transform that to an image with 200 colour palette values, (3)
convert that to png, and finally (4) make a nice looking colour result with
plimage.  Combined steps 1-3 are much faster than step 4 (partially due, I
suspect to the index problem I identified for the first part of step 4.) As
I mentioned before, there is a libgd function to translate true-colour png
format to paletted form, but the colorswanted argument is unfortunately
currently a noop with libgd 2.0.1, and it always produces a colour palette
with 256 items rather than the number you specify with colorswanted.  So I
will have to wait for that parameter to start working in say libgd 2.0.2
before I drop step 2 in favour of that method.

Anyhow, that is the status for the moment, and I welcome further discussion
(especially of the 200-point limitation of the X colour palette). I will
probably check all this in under plplot/examples/extended/gdimage tomorrow
or Monday, and at that point you will get a chance to look at the colour
display for plimage yourself.

Alan

P.S. I have looked a bit further into the indexing situation with a lot of
different google searches and to summarize the description of the image
scans that occur for libp[bgm]m and libgd it is stated that they are in the
writing order of most western languages, that is the start at the top left,
scan from left to right for the first scan, then drop down to the next row
and continue scanning.  I found that tiff also has this scan order by
default (but all other possibilities are allowed as well).  bmp is a MS
image "standard" that confirms my sterotype of that company; there is no
public specification written for bmp format!  However, one web site I read
did indicate the bmp scans were along rows in agreement with the Tiff
default and the rest.  Finally, I looked at fits format (beloved by
astronomers). There, it is up to the individual application transforming raw
image data into fits format whether the scans are along rows or columns, and
the guy I talked to knew of each kind of app!

So the score is fits can (and does!) scan along rows or columns, tiff can do
the same although rows are the default, and the rest (that I have looked at)
scan along rows.  So it is looking more and more like I will be making the
change in index order (although I have yet to hear from Allesandro on this
question).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________