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

MDenham wrote:

> 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?)
> 

You are confusing things here. Negative luminance is just impossible 
while having one or two negative RGB components (with at least one 
positive) is perfectly valid and is indeed needed to describe colors out 
of the gamut of the current RGB color system. In practice this means 
e.g. colors that are not displayable on your CRT/LCD monitor but do 
exist in the real world. Usually such colors are highly saturated 
'neon'-colors.

The transformation from YCCK to RGB would require 2 steps.
First transform from Y/Cb/Cr to CMY in the same way as the YCbCr -> RGB 
conversion is done (but actually you will get CMY values if 
jpeg_color_space is JCS_YCCK ) either by using a set of pre-build lookup 
tables like libjpeg does for speed reasons or by actually calculating 
the transformation in place.
Leave the K untouched and you get CMYK.
But the transformation from CMYK (being a color separation) to RGB is 
impossible without also knowing the used CMYK color space definition as 
defined e.g. within an ICC profile. POV-Ray does currently not support 
such color profiles.
And I know that there exists this simple 'formula' for converting CMYK 
to RGB but believe me, this 'formula' should have never existed in the 
first place. It once even found its way into the wikipedia article about 
CMYK that was a mess at this time anyway and it was quite some fighting 
involved to remove it. This happened a few years ago and meanwhile the 
article is a quite good one. So if you are interested you may want to 
look at the CMYK to RGB conversion section there for more details.


> Am I reading stuff from people who are grossly misinformed?

Might be ;)

-Ive

Post a reply to this message

clipka wrote:
> Ive, do you happen to know anything about IFF?
> 
> (Maybe "not worth bothering about because it is definitely long obsolete 
> by now"?)

Besides some sweet memories, an Amigo 500 was the fist machine I did use 
POV-Ray with, I do also remember that I have a format specification 
somewhere but as this might even be on some old 3.5" disk chances are 
not very good that I will ever find it again.
But I do remember that the IFF/ILBM format was tailored to tightly fit 
the Amiga hardware so I would be surprised if there was anything else 
used as the actual system gamma of an Amiga. But I do not remember what 
this might have been.
But while thinking about it, as the format was later even used on Atari 
and Mac systems I might even be mistaken in this respect.

-Ive

Post a reply to this message

clipka wrote:
> 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)?
> 

No. Libjpeg does not support a YCCK -> RGB transformation and it does 
not support CMYK -> RGB transformation. So if the jpeg_color_space is
JCS_YCCK you can either get JCS_YCCK or JCS_CMYK from the library and 
have to deal with color separations for yourself anyway.

-Ive

Post a reply to this message

Ive schrieb:
> No. Libjpeg does not support a YCCK -> RGB transformation and it does 
> not support CMYK -> RGB transformation. So if the jpeg_color_space is
> JCS_YCCK you can either get JCS_YCCK or JCS_CMYK from the library and 
> have to deal with color separations for yourself anyway.

No thanks - not for starters at least :-)

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> MDenham wrote:
>
> > 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?)
> >
>
> You are confusing things here. Negative luminance is just impossible
> while having one or two negative RGB components (with at least one
> positive) is perfectly valid and is indeed needed to describe colors out
> of the gamut of the current RGB color system.

Eh, negative luminance + positive Cr/Cb = <+,-,+> potentially (forgive the
massively bastardized variation on standard color syntax ;-D) - and negatives
on green are, from looking at normal "RGB vs. real coloring" gamut diagrams,
probably the most common colors that exist but aren't displayable.  Also, the
engine already handles "impossible" colors (components all negative,
hypersaturated colors that extend outside the gamut in the opposite direction,
&c.) so it's not like that's necessarily an issue other than the obvious "it'll
look weird and may not behave entirely correctly".

> In practice this means
> e.g. colors that are not displayable on your CRT/LCD monitor but do
> exist in the real world. Usually such colors are highly saturated
> 'neon'-colors.
>
> The transformation from YCCK to RGB would require 2 steps.
> First transform from Y/Cb/Cr to CMY in the same way as the YCbCr -> RGB
> conversion is done (but actually you will get CMY values if
> jpeg_color_space is JCS_YCCK ) either by using a set of pre-build lookup
> tables like libjpeg does for speed reasons or by actually calculating
> the transformation in place.
> Leave the K untouched and you get CMYK.
> But the transformation from CMYK (being a color separation) to RGB is
> impossible without also knowing the used CMYK color space definition as
> defined e.g. within an ICC profile. POV-Ray does currently not support
> such color profiles.
> And I know that there exists this simple 'formula' for converting CMYK
> to RGB but believe me, this 'formula' should have never existed in the
> first place. It once even found its way into the wikipedia article about
> CMYK that was a mess at this time anyway and it was quite some fighting
> involved to remove it. This happened a few years ago and meanwhile the
> article is a quite good one. So if you are interested you may want to
> look at the CMYK to RGB conversion section there for more details.
Isn't the "formula" for CMYK->RGB essentially specific to an "ideal" ICC
profile?  If so...  *goes off to figure out a good syntax for true spectral
lighting and pigmenting, which is probably more in the realm of additions to
4.0 or later but would allow for "true" conversions both ways as well as other,
odder effects*

Post a reply to this message