clipka wrote:
> BTW, does the jpeglib provide a way to get the raw YCrCb data out of JPG 
> files and do all the color math on floats?

Code fragment:

FILE	*File;
struct	jpeg_decompress_struct cinfo;

jpeg_create_decompress(&cinfo);
jpeg_stdio_src(&cinfo, File);


if (jpeg_read_header(&cinfo, TRUE) == 1)
{

	/*
	thats it, this will force jpeglib to return
	unconverted YCbCr (or only Y for JCS_GRAYSCALE):
	*/

	cinfo.out_color_space = cinfo.jpeg_color_space;

	/*
	now the decompression stuff
	*/	

	[...]
}



But note, the jpeg_color_space is defined as

typedef enum {
	JCS_UNKNOWN,		/* error/unspecified */
	JCS_GRAYSCALE,		/* monochrome */
	JCS_RGB,		/* red/green/blue */
	JCS_YCbCr,		/* Y/Cb/Cr (also known as YUV) */
	JCS_CMYK,		/* C/M/Y/K */
	JCS_YCCK		/* Y/Cb/Cr/K */
} J_COLOR_SPACE;


where JCS_RGB, JCS_CMYK are only used for the transformation and will 
*never* appear within cinfo.jpeg_color_space.

If cinfo.jpeg_color_space is JCS_UNKNOWN reject the file, could be anything.

If cinfo.jpeg_color_space is JCS_GRAYSCALE only one component (Y) is 
used and stored, the most simple case.

The most common case is off course cinfo.jpeg_color_space is JCS_YCbCr.

And my recommendation would be to reject JCS_CMYK because without color 
management and the usage of the ICC profile that usually accompanies 
such a file there is NO transformation to rgb possible.

To see how the YCbCr -> RGB transformation is done within jpeglib have a 
look at jdcolor.c"

-Ive

Post a reply to this message