nanogui: Thread: Re: loadable JPEG + BMP support for nanox !

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

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
####@####.####

: 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 ...
: 

Martin - the business of displaying two different images at the same
time, both with different palettes, is very tricky.  As you know, my
current solution is to merge palettes into the system palette,
using a "nextpointer" into the palette for the next entry to rewrite.
The nextpointer can be reset inbetween images, but images
drawn with the old palette must be redrawn then.   This was
my first design, that allowed one image per application with
different palettes, and the fg application would then get the 
physical palette.

Another solution is that I could bring in color quantization 
methods that an application could request, and always
use a standard uniform palette.  This would be passed to
the jpeg decoder, and bmp files would have to be quantized.

What do you think?


: 
: 
: 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...

The answer here depends on whether you're trying to display
an image that looks great, or just looks good.  Have you
tried just displaying using the uniform palette only?  That is,
no MERGE code.  Otherwise, we could assign priorities
from the application.

Regards,

Greg

Greg,

> The nextpointer can be reset inbetween images, but images
> drawn with the old palette must be redrawn then.   This was
> my first design, that allowed one image per application with
> different palettes, and the fg application would then get the
> physical palette.
>
> Another solution is that I could bring in color quantization
> methods that an application could request, and always
> use a standard uniform palette.  This would be passed to
> the jpeg decoder, and bmp files would have to be quantized.
>
> What do you think?
>

The second option looks better, but hey, from what I understand/know
about
colors/palette stuff, I'll let you decide ... :-)

>
> :
> :
> : 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...
>
> The answer here depends on whether you're trying to display
> an image that looks great, or just looks good.  Have you
>

Well, I was pretty satisfied with my original posting ... Don't forget
that I
use a 4bpp *grayscale* lcd for the project ... So on my side it was
pretty
good ...


> tried just displaying using the uniform palette only?  That is,
> no MERGE code.  Otherwise, we could assign priorities
> from the application.
>

What do you mean by uniform palette ? The system palette ?

Regards,

Martin Jolicoeur
GVT Project
####@####.####

: Well, I was pretty satisfied with my original posting ... Don't forget
: that I
: use a 4bpp *grayscale* lcd for the project ... So on my side it was
: pretty
: good ...

I've integrated your original posting into the source tree.


: 
: 
: > tried just displaying using the uniform palette only?  That is,
: > no MERGE code.  Otherwise, we could assign priorities
: > from the application.
: >
: 
: What do you mean by uniform palette ? The system palette ?

A uniform palette is one which contains a uniform distribution
of all RGB colors (well, 256 equi-spaced colors in the RGB
cube) that allows any picture to be displayed, although rarely
extremely well.  Many quantization routines map to this palette.
The stdpal8.c contains a 208 color uniform palette for just
this purpose.

Regards,

Greg