|
![](/i/fill.gif) |
In article <zYkDOZ6hKlr2Xr8dlLPSSqLahxcl@4ax.com>, Glen Berry
<7no### [at] ezwv com> wrote:
> This sounds like the idea I have, except you are suggesting creating
> some "presets" to cover the more common applications.
Actually, I was thinking of putting almost everything into a "film_type"
post process filter, which would do different things depending on it's
parameters. However, it might be better to make several separate but
similar filters...
> My primary wish was to roughly simulate a film's response curve,
> ignoring color values. All three color channels would be manipulated
> according to the same formula.
Yes, that is pretty much what I had in mind.
> If we want to get more advanced (and I think we should), we could
> process each channel independently, and achieve a much broader range
> of effects. Including:
>
> 1 Blue, Gold, Selenium, Sepia, or Split Toning (and many others)
> 2 Reciprocity Failure Simulation
> 3 Solarization
> 4 Posterization
> 5 Conversion to a Negative
> 6 Simulation of Antiquated or Alternative Photographic Processes
> 7 Simulation of Specific Film Stocks (the most ambitious goal)
That's quite a list... :-)
Maybe a specialized sort of isosurface function could also be useful. It
would have additional variables(r, g, and b at least), and the filter
would take 3 of them, one for each channel. Maybe the syntax could also
be set up so if only one is specified, it is used for all 3 channels.
Hmm, some of these could also be good effects for textures...what do you
think of that idea? "texture_process"? :-)
> Note: To obtain the toning effects (normally a B&W photographic
> process), we would need to first convert the full-color RGB image into
> a monochromatic RGB image. Then we simply alter the curves of the RGB
> channels independently. While a typical POV image can currently be
> manipulated like this in an image editor, it would be better to
> perform such level manipulation on the raw floating point values, to
> better preserve the dynamic range of the original scene.
I think this is the total information available to post_process filters,
and I think everything can be accessed for every pixel in the image,
regardless of the current pixel being processed:
DBL Depth;
The distance the ray went before it hit anything, I guess.
COLOUR Colour;
Clipped or unclipped? I don't know...
VECTOR IPoint;
The intersection point.(What is this for background pixels?)
VECTOR INormal;
The unperturbed surface normal at the intersection point.(Again,
what is this for background pixels?)
VECTOR PNormal;
The surface normal at the intersection point, perturbed by the
texture normal.
UV_VECT Iuv;
UV coordinates for the intersection point, I guess.
int Object;
An index for the first object hit?
There are some interesting possibilities with these...
--
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) |