POV-Ray : Newsgroups : povray.unofficial.patches : Announce: SkyPOV 0.1 : Re: color definition (Re: Announce: SkyPOV 0.1) Server Time
31 Jul 2024 02:28:15 EDT (-0400)
  Re: color definition (Re: Announce: SkyPOV 0.1)  
From: Wlodzimierz ABX Skiba
Date: 7 Nov 2000 04:48:23
Message: <3a07cfe7@news.povray.org>
my english may be poor sometimes :-(

Chris Huff wrote in message ...
>> but you put sign "=" between meaning of "all" and "gray"
>> is it true in other color spaces ?
>
>The "=" operator isn't used in this patch...I don't know what you mean.

I mean that in your first post you don't know what is better
name - "all" or "gray" - but you don't precise what "all" should
represent - if the same as gray than what should be used for
all curves in other color spaces ?

>> >Your
>> >syntax will cause confusion("I can modify red and green at the same
>> >time, but not blue and saturation?").
>> it depends of implementation in your planned patch :-)
>
> No, it doesn't. For example, you can't manipulate red and hue
> simultaneously, you can only manipulate one color space at a time.
This
> is because saturation and hue affect red, green, and blue, and the
same
> goes for the reverse.

yes I know this

> My syntax will allow the addition of hsl, hue and
> saturation modes, yours won't, at least not in a way that makes sense.
> However, those shouldn't be necessary anyway, since you can just use
> other conversion filters before and after the curves filter to get the
> same result. So we are back to whether or not to use the color syntax
> for splines.
> What exactly is deficient in the syntax I chose? Why do you think
> specifying splines representing color channel curves with a color-like
> syntax is a better idea than specifying a channel and a spline to go
> with it?


I don't think that your syntax is wrong
but I think that there should be first discussion
about implement other color spaces in all ways where old colors
can be use, than how to extend it to use curves and than
use this curves syntax in post-processes
your way is to implement it to one usage but
perhaps it is hardly to extend in the future for rest of pov syntax

perhaps:
COLOR_DEFINITION:
  color SPACE_NAME value_for_all | SPACE_COORDINATES
SPACE_NAME:
  rgb | hsl | hue | etc ...
SPACE_COORDINATES:
  vector | COORDINATES_SPECIFICATION
COORDINATES_SPECIFICATION:
  COORDINATE_IN_SPACE value_of_coordinate
  [COORDINATE_IN_SPACE value_of_coordinate ...]
COORDINATE_IN_SPACE:
  red | green | blue | cyan | magenta | filter | transmit | saturation
...

as you see this is nearly the same like old definition
and not to much to change in old scripts

COLOR_MAP:
  color_map {
    curve { SPACE_NAME curve_identifier } /* for all coordinates in
space */
    curve { SPACE_NAME
      COORDINATE_IN_SPACE curve_identifier
      [COORDINATE_IN_SPACE value_of coordinate ...]
    } /* for specification */
  }

i'm not specialist, forgive me than if i'm wrong with something
and what's more important - since year I slowly but carefully
read archiv of news.povray.org, but still I have
46205 messages to read - perhaps there is discussion of our problem

ABX


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.