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