 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoftorg"> wrote:
> Ive wrote:
>
> > And my recommendation would be to reject JCS_CMYK because...
>
> Err, this should be "...reject JCS_YCCK..."
>
> -Ive
From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
subtracting K from Y. (Yes, this means you'd need to potentially support a
negative luma component in the process of generating the colors at any given
spot... but shouldn't the internal calculation not have an issue with that
anyway, given that negative channel values can crop up in OpenEXR files
already?)
Am I reading stuff from people who are grossly misinformed?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> Or did I miss something else in the discussion?
No, I did - I had only skimmed over the information you provided, and
missed that detail then.
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?
>
> 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?
Sorry, I misread your message to read "height fields" instead of "image
maps".
Looks like I seriously needed to get some sleep...
(Speaking of height fields: After having dug through the code, I can
state with confidence that for height fields, even PNG files are always
read in as encoded, without taking the gAMA chunk into account, so at
least for those you don't need to "amputate" the gAMA chunk.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MDenham schrieb:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> Ive wrote:
>>
>>> And my recommendation would be to reject JCS_CMYK because...
>> Err, this should be "...reject JCS_YCCK..."
>>
>> -Ive
> From what I'm reading elsewhere, Y/Cr/Cb/K can be folded down to Y/Cr/Cb by just
> subtracting K from Y. (Yes, this means you'd need to potentially support a
> negative luma component in the process of generating the colors at any given
> spot... but shouldn't the internal calculation not have an issue with that
> anyway, given that negative channel values can crop up in OpenEXR files
> already?)
>
> Am I reading stuff from people who are grossly misinformed?
Don't know, but the first google result I found on "YCCK" gave this
information:
"There are a number of issues here. The K channel is an extension of the
Y channel. The question is what is the nature of the the CMYK data?
Is it linear in percent dot? If that is the case, the image you see
should be negative. If the CODEC unfolded the data and reversed it you
have to check if it has also applied gamma correction. If it has, then
you need to apply a gamma 2.2 to the Y and K channels, sum them, and
then apply a gamma .45 to the resultant sum. This is only an
approximation."
So apparently the YCCK color space is to CMYK what YCbCr is to RGB.
Given that CMYK has something to do with how much ink should be printed
of which color, which is subject to various conditions such as how much
bleeding occurs in the paper and all such things, I guess this "just
subtract K from Y" is more of a kludge than a proper handling.
BTW, I presume that out_color_space will default to JCS_CMYK for such
files; in that case, POV-Ray will reject those files anyway at present.
Ive, would it be a solution for such cases (but only those) to override
the out_color_space with JCS_RGB, and have the library do the whole job
(at the cost of precision)?
As for negative color components, POV-Ray does appear to handle these in
some sane fashion in *most* cases, but - as it appears to me - not all.
In particular, I recently saw some indication that shadows cast by
semi-transparent stuff needs to be revisited on this issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive, do you happen to know anything about IFF?
(Maybe "not worth bothering about because it is definitely long obsolete
by now"?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
