![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3 May 2000 10:15:11 -0400, ron### [at] povray org (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] ezwv com to email me. )
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <391026EB.BFD05720@aetec.ee>, Vahur Krouverk
<vah### [at] aetec ee> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
>
> In article <391026EB.BFD05720@aetec.ee>, Vahur Krouverk
> <vah### [at] aetec ee> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3911596B.FB7BB83F@aetec.ee>, Vahur Krouverk
<vah### [at] aetec ee> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39115C75.19BC1A37@aetec.ee>, Vahur Krouverk
<vah### [at] aetec ee> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
[Vahur Krouverk <vah### [at] aetec ee>]
| 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |