nanogui: Re: loadable JPEG + BMP support for nanox !
Subject:
Re: loadable JPEG + BMP support for nanox !
From:
Martin Jolicoeur ####@####.####
Date:
12 Jan 2000 23:46:35 -0000
Message-Id: <387D1008.679D9D04@visuaide.com>
Greg,
>
> 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.
>
I saw that call to GdmakePaletteConversionTable and I tried this on the
first shot, but this routine change the system palette (merge the
palette) and when it came to display another image at the same time on
the display, the other image, with a different palette what all fucked
up. For the testing, I was displaying a .jpg and a .bmp at the same time
on the display ... The jpeg routine was like it is right now and I was
trying a GdmakePaletteConversion call in the bmp routine ...
>
> 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.
>
Yes, the jpeg library can generate a palette itself (that's what it does
usually), just comment out the block:
/* Get system palette */
cinfo.actual_number_of_colors = GdGetPalette(0,si.ncolors,palette);
/* Allocate jpeg colormap space */
cinfo.colormap = (*cinfo.mem->alloc_sarray)((j_common_ptr) &cinfo,
JPOOL_IMAGE,
(JDIMENSION)cinfo.actual_number_of_colors, (JDIMENSION) 3);
/* Set colormap from system palette */
for(l = 0; l < cinfo.actual_number_of_colors; l++)
{
cinfo.colormap[0][l] = palette[l].r;
cinfo.colormap[1][l] = palette[l].g;
cinfo.colormap[2][l] = palette[l].b;
}
and replace it by:
cinfo.out_color_space = JCS_RGB;
cinfo.desired_number_of_colors = si.ncolors;
(much like my fast_grayscale output does)
and after the call to jpeg_start_decompress, copy the generated colormap
into a temporary palette and make the conversion:
for(l = 0; l < cinfo.desired_number_of_colors; l++)
{
palette[l].r = cinfo.colormap[0][l];
palette[l].g = cinfo.colormap[1][l];
palette[l].b = cinfo.colormap[2][l];
}
GdMakePaletteConversionTable(&palette[0],
cinfo.desired_number_of_colors, convtable, MERGEPALETTE);
Maybe you're right after all ... the image is much better ... As I told
you, I'm not an expert in color stuff ... Do you think you could hack
something better ? I would be happy ... I have only two requirements in
this area: I want to keep my fast_grayscale output for a color image and
I want to be able to display a .jpg and a .bmp at the same time on the
screen with proper display...
Improving each other's code, that's one thing open source is good for
;-)
Regards,
Martin Jolicoeur
GVT Project
####@####.####
