How about adding CMYK support and allowing POV to export to a CMYK format,
like EPS (DCS 2.0) or TIFF?* :)










*Yet another idea from "off-the-top-of-my-head-I-just-came-up-with-it"
productions, an Anthony Bennett company... ;)

Post a reply to this message

TonyB wrote:
> 
> How about adding CMYK support and allowing POV to export to a CMYK format,
> like EPS (DCS 2.0) or TIFF?* :)
> 

RGB to CMYK conversion is not a trivial process, since the two operate on
different principles and in different gamut space. In my opinion it's best left
to specialised image editing programs a la Photoshop, where you can preview and
tweak the result.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

On 3 May 2000 10:15:11 -0400, ron### [at] povrayorg (Ron Parker)
wrote:

>Also, how do you propose to wedge, say, a CMYK color into a COLOUR?
>Or are you just planning to not implement CMYK?

Aren't CMYK>RGB and RGB>CMYK difficult conversions? If I understand it
correctly, there are skilled photographers who own Photoshop and still
send files to professional service bureaus for such conversions, in
preparation for high-quality printing. I think that these bureaus
often have to make manual corrections, to optimize the conversion. I
think it has to do with the idiosyncracies of printing inks and
printing technology.

This leads me to a question. If one is not needing CMYK for a printing
application (the most common need for CMYK), what other crucial use
does it have?

Just in case anyone doesn't know, not all printing processes are
optimized for CMYK. There are also high quality processes that operate
in RGB color space.

Later,
Glen Berry

( Remove the "7" from 7no### [at] ezwvcom to email me. )

Post a reply to this message

In article <391026EB.BFD05720@aetec.ee>, Vahur Krouverk 
<vah### [at] aetecee> wrote:

> I didn't knew about them either, but with help of CG Bible (by Damn,
> Fool et al;-) and colorspace FAQ from POV-Ray CD it appeared to be not
> too hard to implement.

Is this colorspace FAQ available online?


> For color space conversion filter and transmit have no value, so
> probably those functions could use vector type as well.

Well, they shouldn't be affected by the conversion, but if someone feeds 
a color containing filter or transmit through rgb2hsl() and then through 
hsl2rgb(), the result will be the same color but stripped of the filter 
and transmit values. Not an extremely serious problem, most of the time 
you won't notice it, but it is a problem.


> This means, that conversion vector<=>colour should be available (is 
> it?).

Colors are 5-dimensional vectors. If used as vectors, filter and 
transmit are ignored. Vectors can be used as colors, filter and transmit 
are set to 0 in this case.


> > The post_process versions wouldn't require any parameters.
> I'm not sure I that understand this, (I haven't observed post-processing
> evolvement very closely), care to explain?

I mean with the functions, you feed it a color and get a color in 
return. With the post_process filter, you just specify a conversion 
filter-it takes the image as input and replaces it with the output. You 
could then use add, subtract, multiply, etc to manipulate each "channel" 
and convert back to rgb.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Ron Parker wrote:
> 
>On Wed, 03 May 2000 08:10:44 +0200, Vahur Krouverk wrote:
>>I think that in order to limit number of functions, "orthogonal"
>>approach should be used, i.e. conversion functions only from/to rgb
>>should be implemented (this is how my conversion currently works).
> This limits the range of colors to the gamut that's supported by RGB.
> I suppose that shouldn't be a problem, since output is in RGB anyway,
> but it's worth thinking about.
> 
This shortcut allows me to get away with 10 conversions instead of 30. 

> Also, how do you propose to wedge, say, a CMYK color into a COLOUR?
> Or are you just planning to not implement CMYK?
> 
No, I'm not going to support CMYK. There is number of reasons:
Firstly, because RM SL does not support it (it supports 6 above
mentioned color spaces, AFAIK) and I want to make this patch as
compatible with RM as it would be possible.
Secondly, I don't think, that CMYK is needed for POV-Ray. If someone
wants to print picture, then it would be better to leave this process to
dedicated software, I don't want to see POV-Ray as bloatware, supporting
42.
In total there is dozens of different color spaces and I don't think,
that they all should be supported. Color conversion is tricky thing and
I don't want to spend too much time on this. I don't think, that this
color conversion is used very much anyway, perhaps sometimes
RGB<->HSL(HSV), but no more.

Post a reply to this message

Chris Huff wrote:
> 
> In article <391026EB.BFD05720@aetec.ee>, Vahur Krouverk
> <vah### [at] aetecee> wrote:
> 
> > I didn't knew about them either, but with help of CG Bible (by Damn,
> > Fool et al;-) and colorspace FAQ from POV-Ray CD it appeared to be not
> > too hard to implement.
> 
> Is this colorspace FAQ available online?
> 
Yes, there->
http://www.faqs.org/faqs/graphics/colorspace-faq/

Post a reply to this message

Glen Berry wrote:
> 
> Aren't CMYK>RGB and RGB>CMYK difficult conversions? 

No, basically this are as easy as that (RGB->CMY):
C = 1 - R
M = 1 - G
Y = 1 - B
In case of CMYK K is computed as minimum from C,M,Y and each component
(CMY) is reduced by this value.
This "easy" conversion works in theory, in practice it's much more
complicated (see below).
> If I understand it
> correctly, there are skilled photographers who own Photoshop and still
> send files to professional service bureaus for such conversions, in
> preparation for high-quality printing. I think that these bureaus
> often have to make manual corrections, to optimize the conversion. I
> think it has to do with the idiosyncracies of printing inks and
> printing technology.
> 
You are correct. colorspace FAQ has more detailed explanation for it,
basically it comes down to the fact, that ink spectral absorption curves
overlap and thus this easy CMY = 1-RGB doesn't hold. Other problem is
non-linearity by dot gain, causing similar problems as gamma in case of
monitors.

Post a reply to this message

In article <3911596B.FB7BB83F@aetec.ee>, Vahur Krouverk 
<vah### [at] aetecee> wrote:

> > Is this colorspace FAQ available online?
> > 
> Yes, there->
> http://www.faqs.org/faqs/graphics/colorspace-faq/

Thanks!

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <39115C75.19BC1A37@aetec.ee>, Vahur Krouverk 
<vah### [at] aetecee> wrote:

> No, basically this are as easy as that (RGB->CMY):
> C = 1 - R
> M = 1 - G
> Y = 1 - B
> In case of CMYK K is computed as minimum from C,M,Y and each component
> (CMY) is reduced by this value.

Ok, then there already exists a filter which can do most of the 
conversion: invert. You could then get K using the "min" filter.(which I 
haven't written yet)

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

[Vahur Krouverk <vah### [at] aetecee>]
| No, I'm not going to support CMYK. There is number of reasons:
| Firstly, because RM SL does not support it (it supports 6 above
| mentioned color spaces, AFAIK) and I want to make this patch as
| compatible with RM as it would be possible.
| Secondly, I don't think, that CMYK is needed for POV-Ray. If someone

Too bad POV-Ray doesn't support colors outside of the RGB-cube, like
the LAB-format, which contains all colors visible to the human eye,
like blacklight and other neat colors your monitor can't display.
Of course, since no commercially available display exists to show the
darn image, and certainly no printer that can print it, it's rather moot.

-- 
A penny for your thoughts.
Mine are more expensive.

Post a reply to this message