In article <zYkDOZ6hKlr2Xr8dlLPSSqLahxcl@4ax.com>, Glen Berry 
<7no### [at] ezwvcom> 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] 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