nanogui@linuxhacker.org

Martin,
	I have looked at your submission for the jpeg
and bmp support for Nano-X.  It's a great job.
I have a couple of questions regarding the palette
management aspects of it, and want to get 
your opinion.

The GdDrawImage routine takes a IMAGEHDR
struct, which includes the intended display
image's palette.  The first thing that happens
is that GdDrawImage calls GdmakePaletteConversionTable
which merges the requested palette into
the server's physical palette.  I use a gr_firstuserpalentry
variable to specify what entries in the physical
palette can be replaced by new entries in the
IMAGEHDR struct.

Your code just calls GdFindColor to map
a conversion table from the image palette
to the unmodified current physical palette.
Now, for BMP's it would be relatively easy
to make the GdMakePaletteConversionTable
call.  Of course, for truecolor systems, none
of this matters.  And the std 256 color palette
that I supply is a equidistant RGB spanning
palette so any image should display halfway
decently.

But my real question has to do with jpeg: can the
jpeg library come up with a palette, or do we always
have to pass it a preferred palette?  If we pass a palette,
then it will always get the equidistant palette, which
doesn't really look that hot for all pictures.  If we
let it come up with one, then we might be able to map
that one into our current physical palette the way
that GdDrawImage works.

Regards,

Greg