clipka <ano### [at] anonymousorg> wrote:
> I had thought about a gamma of 2.2 (to closely match sRGB), or the 
> File_Gammma INI setting (so that previously rendered images will be read 
> in properly). But you're making a point there, too.

  It would also automatically fix the current problem with image maps
without the user having to specify anything in the scene file itself.

-- 
                                                          - Warp

Post a reply to this message

To make life easier that's the libpng call for getting the
sRGB chunk information. For the sole purpose of gamma correction you can 
safely ignore the value that is returned as sRGB_intent.


int sRGB_intent;

if (png_get_sRGB(png_ptr, png_inf, &sRGB_intent) != 0)
{
	/* sRGB chunk is present, so we can ignore any gAMA chunk */

	[,,,]

}



-Ive

Post a reply to this message

Ive schrieb:
> I really do not see why not simply respecting the W3C/PNG recommendation 
> as every contemporary browser (meanwhile even including IE) and every 
> not totally brain-dead image viewer does.

Um - misunderstanding here:

The default gamma for input files would be intended to kick in *only* 
for files where no gamma information is to be had (or where 
sophisticated gamma / color profile handling hasn't been implemented yet).

For PNG files, the gAMA chunk information would still take precedence. 
(And as for sRGB chunks, if I'm asked the only legitimate reason to 
continue ignoring them is lack of the manpower needed to implement the 
proper handling; the same goes for full-fledged color profiles, by the way.)

To override the decoding gamma for files with explicit gamma information 
or a fixed gamma, the user would have to explicitly specify a decoding 
gamma on a per-file basis.

Post a reply to this message

Warp schrieb:
>   It would also automatically fix the current problem with image maps
> without the user having to specify anything in the scene file itself.

What current problem?

Post a reply to this message

Ive schrieb:
>> This is actually a problem I see with most of POV-Ray's file input 
>> code, as data is typically stored no wider than 8 bits per channel 
>> unless the encoded data is wider already.
> 
> I completely agree and actually for exactly this reason I did recommend 
> the conversion from JPEG to 16-bps PNG files to overcome the current 
> problems with image maps.

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?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   It would also automatically fix the current problem with image maps
> > without the user having to specify anything in the scene file itself.

> What current problem?

  I can't believe you have already forgotten the superlong thread about
the subject. Are you honestly saying that you can't remember what the
problem with input images in POV-Ray 3.7 currently are? Really?

  Anyways, in short, if the input image has no gamma information, and the
user has not specified any assumed gamma for that particular input image,
then if POV-Ray used an assumed gamma equivalent to File_Gamma (or perhaps
Display_Gamma), there would be no need for this:
http://bugs.povray.org/task/10

-- 
                                                          - Warp

Post a reply to this message

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

Ive wrote:

> And my recommendation would be to reject JCS_CMYK because...

Err, this should be "...reject JCS_YCCK..."

-Ive

Post a reply to this message

clipka wrote:

> Um - misunderstanding here:
> 
> The default gamma for input files would be intended to kick in *only* 
> for files where no gamma information is to be had (or where 
> sophisticated gamma / color profile handling hasn't been implemented yet).
> 

to cite myself:

"If no gAMA chunk and no sRGB chunk is present the PNG/W3C 
recommendation says to handle the file in the same way is if a sRGB 
chunk were present."

So for PNG the gamma is always defined!
Or did I miss something else in the discussion?

-Ive

Post a reply to this message

Ive wrote:
> 
> did I forget something, GIF? not much to say there but usually gamma 
> corrected in between 1.4 and 2.4 - its a matter of guessing again.
> 

Oops. it seems I'm a bit biased against GIF so to be fair there is also 
the usual W3C recommendation to assume GIF to be in sRGB but I have an 
old GIF collection since good old Compuserve days that are obviously not.


-Ive

Post a reply to this message