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

MDenham schrieb:
> *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*

Yeah, that would be something nice to have.

Including fluorescence, please :-)

Post a reply to this message

MDenham wrote:
> 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".
> 

Jpeg's YCbCr is a 1:1 adaption of the European standard tv signal 
encoding (CCIR/ITU Rec. 601 IIRC) with the advantage that you can just 
drop the CbCr part. This did make people happy who couldn't afford a 
color tv. Sending a signal with negative Y would have made people quite 
unhappy 'cause you just imploded their brand new tv set ;)
Seriously, jpeglib uses a strict range checking anyway (to avoid such 
issues as the DCT compression might introduce some noise) and YCbCr is 
just not *designed* to represent anything outside the gamut of a tv 
monitor from this time. Thats not as bad as it sounds because, if I'm 
not mistaken, this gamut was even defined wider than the currently 
accepted sRGB gamut.


> Isn't the "formula" for CMYK->RGB essentially specific to an "ideal" ICC
> profile?

An "ideal" CMYK ICC profile is somehow meaningless and does not exist.
Therefor such a 'formula' cannot exist and this was from the very 
beginning my point ;)
What we have is a bunch of numerous international standards within the 
printing business and an ICC profile is used to make clear to what 
standard the CMYK separation does refer, tells something about the 
intended ink set, raster...  and *a lot* more things.


> *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*
> 

This is of course also something I would like to have, but as I'm not so 
patient I'll wait with such things until computing power evolves much 
more...


-Ive

Post a reply to this message

Ive wrote:

> 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.

http://www.wotsit.org/list.asp?al=I

Post a reply to this message

Ive schrieb:
> 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.

How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
that do the same job?

Another thing: The sRGB spec speaks of aiming to achieve an overall 
viewing gamma of 1.125; am I however correct in assuming that decoding 
sRGB-encoded material according to the sRGB decoding function will 
nonetheless reconstruct the /linear/ data?

Otherwise, if sRGB-encoded data was expected to already account for that 
desired viewing gamma, for raytracing purposes it would theoretically 
have to be compensated for, both when decoding and encoding.

Post a reply to this message

clipka wrote:

> How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
> that do the same job?
>

You are aware that you are breaking the poor mans idea of encapsulation 
by directly accessing the fields from png_inf ;)

And it's by no means time critical, so why not just use the API call?


> Another thing: The sRGB spec speaks of aiming to achieve an overall 
> viewing gamma of 1.125; am I however correct in assuming that decoding 
> sRGB-encoded material according to the sRGB decoding function will 
> nonetheless reconstruct the /linear/ data?
>

The sRGB viewing gamma of 1.125 is just another (poor mans) attempt of 
taking the environment illumination of some typical pc user into 
account. There are much more complicated attemps from the ICC and I 
really think we do not need to care about this.


-Ive

Post a reply to this message