 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello!
I'm currently implementing color space conversion for my shader patch.
It includes conversion between rgb, xyz, xyY, hsv, hsl and yiq spaces.
It seemed to be good idea to put this conversion function to color.c
file (err, coloUr.c). Now I'm wondering, whether it is good idea to
make those conversion functions available from POV-Ray as well? Is there
any use for them? One thing, that comes to my mind, is post-processing:
with conversion from rgb to hsl (or hsv) it would be easy to add or
reduce saturation, or change hue.
If this is good idea, then how should it be implemented? As functions?
Which form would be preferable:
rgb2hsv(COLOUR) or
COLOUR rgb2hsv(COLOUR)?
First modifies parameter given color, second returns converted color.
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).
P.S. I know that there are macros for conversion between rgb and hsv
(and/or hsl), but as this conversion code will be there for shader
patch, then it would be good idea to reuse it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <390### [at] aetec ee>, Vahur Krouverk <vah### [at] aetecee>
wrote:
> I'm currently implementing color space conversion for my shader patch.
> It includes conversion between rgb, xyz, xyY, hsv, hsl and yiq spaces.
> It seemed to be good idea to put this conversion function to color.c
> file (err, coloUr.c). Now I'm wondering, whether it is good idea to
> make those conversion functions available from POV-Ray as well? Is there
> any use for them? One thing, that comes to my mind, is post-processing:
> with conversion from rgb to hsl (or hsv) it would be easy to add or
> reduce saturation, or change hue.
I have been wondering about making these conversion functions for a long
time, the only thing stopping me is a complete lack of knowledge of
these color spaces and converting between them. I have also been
thinking a post_process filter which does this would be useful.
> If this is good idea, then how should it be implemented? As functions?
> Which form would be preferable:
> rgb2hsv(COLOUR) or
> COLOUR rgb2hsv(COLOUR)?
I would definitely choose the second syntax, the first would only cause
trouble. The function should take and return a color.(I used a vector
function for eval_pigment(), so it doesn't return an actual color. That
means it loses filter and transmit, but I didn't know how to add a new
class of functions which returns a color.)
The post_process versions wouldn't require any parameters.
A somewhat similar set of functions would be functions for conversion
between cartesian, cylinderical, and spherical coordinates.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
>
> I have been wondering about making these conversion functions for a long
> time, the only thing stopping me is a complete lack of knowledge of
> these color spaces and converting between them. I have also been
> thinking a post_process filter which does this would be useful.
>
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.
> > If this is good idea, then how should it be implemented? As functions?
> > Which form would be preferable:
> > rgb2hsv(COLOUR) or
> > COLOUR rgb2hsv(COLOUR)?
>
> I would definitely choose the second syntax, the first would only cause
> trouble. The function should take and return a color.(I used a vector
> function for eval_pigment(), so it doesn't return an actual color. That
> means it loses filter and transmit, but I didn't know how to add a new
> class of functions which returns a color.)
For color space conversion filter and transmit have no value, so
probably those functions could use vector type as well. This means, that
conversion vector<=>colour should be available (is it?).
> 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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Also, how do you propose to wedge, say, a CMYK color into a COLOUR?
Or are you just planning to not implement CMYK?
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
These are my opinions. I do NOT speak for the POV-Team.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
