nanogui: Thread: GdJPEG for PF_TRUECOLOR patch

Hi All,

I made a few minor changes to the GdJPEG function to handle various
pixel types. I believe the jpeg lib will always return a 24 bit pixel
value unless requested to do otherwise. So, I think this patch is safe.
I've only tested it with 16bpp. I think there may have been a bug in the
original version. It seems that within the "while (destx++ != maxx)"
loop, k should be incremented outside of the if construct. Maybe I'm
missing something (not unusual :).

Kyle.

--- include/device.h	Sat Feb 12 23:28:09 2000
+++ include/device.h.new	Thu Feb 24 00:06:37 2000
@@ -105,6 +105,7 @@
 
 #if SCREEN_PIXTYPE == PF_PALETTE
 typedef unsigned char PIXELVAL;
+#define RGB2PIXEL(r,g,b)	(r)
 #define _SCREEN_PIXTYPE_OK
 #endif
 


--- engine/devimage.c	Mon Jan 31 20:46:11 2000
+++ engine/devimage.c.new	Thu Feb 24 00:03:50 2000
@@ -106,7 +106,8 @@
 	SCREENINFO si;
 	FILE *infile;		/* source file */
 	JSAMPARRAY buffer;	/* Output row buffer */
-	
+	int jpeg_pixelsize;
+
 	/* This struct contains the JPEG decompression parameters and pointers
to
 	 * working space (which is allocated as needed by the JPEG library).
 	 */
@@ -140,13 +141,12 @@
 	/* Get system information */
 	GdGetScreenInfo(&scrdev, &si);
 
-	/* Support only palettized for now ... */
-	if (si.pixtype == PF_PALETTE)
+	if (!fast_grayscale)
 	{
-		cinfo.quantize_colors = TRUE;
-
-		if (!fast_grayscale)
+		if (si.pixtype == PF_PALETTE)
 		{
+			cinfo.quantize_colors = TRUE;
+	
 			/* Get system palette */
 			cinfo.actual_number_of_colors = GdGetPalette(0,si.ncolors,palette);
 	
@@ -162,18 +162,19 @@
 				cinfo.colormap[2][l] = palette[l].b;
 			}
 		}
-		else
-		{
-			/* Grayscale output asked */
-			cinfo.out_color_space = JCS_GRAYSCALE;
-			cinfo.desired_number_of_colors = si.ncolors;
-		}
+	}
+	else 
+	{
+		/* Grayscale output asked */
+		cinfo.out_color_space = JCS_GRAYSCALE;
+		cinfo.desired_number_of_colors = si.ncolors;
 	}
 
 	/* Step 5: Start decompressor */
 	jpeg_start_decompress (&cinfo);
 
 	/* Make a one-row-high sample array that will go away when done with
image */
+	jpeg_pixelsize = cinfo.output_components;
 	buffer = (*cinfo.mem->alloc_sarray)
 		((j_common_ptr) &cinfo, JPOOL_IMAGE,
 		cinfo.output_width * cinfo.output_components, 1);
@@ -203,11 +204,14 @@
 		k = 0;
 		while (destx++ != maxx)
 		{
+			unsigned char *rgb;
+
+			rgb = &buffer[0][k];
 			if(clip == CLIP_VISIBLE || GdClipPoint(destx, desty)) {
-				psd->DrawPixel(psd, destx, desty, buffer[0][k++]);
+				psd->DrawPixel(psd, destx,
desty,RGB2PIXEL(*rgb,*(rgb+1),*(rgb+2)));
 			}
+			k += jpeg_pixelsize;
 		}
-
 		destx = minx;
 		desty++;
 		height--;

: I made a few minor changes to the GdJPEG function to handle various
: pixel types. I believe the jpeg lib will always return a 24 bit pixel
: value unless requested to do otherwise. So, I think this patch is safe.
: I've only tested it with 16bpp.

Kyle,
    Thanks for your patch.  The original version didn't work with
anything other than 8bpp.

Actually, your patch fails with 32bpp, and only works 16bpp because you
happened to compile Microwindows with a PIXELVAL size
of 16bpp (unsigned short)...  If the source and destination pixel
values don't match, you can't use the RGB2PIXEL macros, but
instead must find GdFindColor.  I have attached a working version
that works on 8pp and 24bpp, and 32 bpp.  It think the 16bpp still works
(it segfaulted with your patch) but, alas, 16bpp is the one bpp I can't
test, since the fb palette isn't setup properly for cards which
return FB_VISUAL_DIRECTCOLOR, which require a palette
mapping first.  (If anyone has input for the palette map for 16bpp
DIRECTCOLOR ATI cards, let me know)


 I think there may have been a bug in the
: original version. It seems that within the "while (destx++ != maxx)"
: loop, k should be incremented outside of the if construct. Maybe I'm
: missing something (not unusual :).

No, if you move the k outside the loop, the image fails...

I've attached what I think is a patch to your patch, and have
entered it into the tree. ;-)

Regards,

Greg

>
>
> I've attached what I think is a patch to your patch, and have
> entered it into the tree. ;-)
>
> Regards,
>
> Greg

Greg,

Fast_grayscale mode doesn't work anymore with your latest devimage.c. A
little mistake in the process ... Here is the patch :

Regards,

Martin Jolicoeur
GVT PRoject
####@####.####

--- devimage.c	Mon Feb 28 14:30:17 2000
+++ devimage_patch.c	Mon Feb 28 14:31:33 2000
@@ -165,6 +165,7 @@
 	else 
 	{
 		/* Grayscale output asked */
+		cinfo.quantize_colors = TRUE;
 		cinfo.out_color_space = JCS_GRAYSCALE;
 		cinfo.desired_number_of_colors = psd->ncolors;
 	}