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

On Sun, 23 Apr 2000 20:51:08 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>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 first idea was the more general method of supplying custom
parameters to achieve a given result. Perhaps to even include a
"formula parser" that would allow the end-user to enter a unique
formula for the effect desired. 

A list of parameters or formulas that are known to produce interesting
results should be included with the patch, just to get people started.
They can always try their own values or formulas, after experimenting
with the samples provided with the patch.

Later,
Glen Berry

Post a reply to this message

Glen Berry wrote:

> My first idea was the more general method of supplying custom
> parameters to achieve a given result. Perhaps to even include a
> "formula parser" that would allow the end-user to enter a unique
> formula for the effect desired.
> 
> A list of parameters or formulas that are known to produce interesting
> results should be included with the patch, just to get people started.
> They can always try their own values or formulas, after experimenting
> with the samples provided with the patch.

Someone once suggested a filter matrix similar to the one used by paint
programs such as the one available in PSP.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote...
>
> Unfortunately, Darren's webpage detailing the "Infinite Light Patch"
> and his "Dispersion Patch" is no longer online. He has two websites,
> and I visited them both. However, the link to the aforementioned web
> page does not work.
>
> I had seen the "Infinite Light Patch" in the past, and recall that it
> attempted to solve at least some of the same issues, but I don't
> remember it in enough detail to comment on it properly. At the time, I
> had the impression that his implementation wasn't modeled in a
> physically accurate manner, but I could be easily mistaken. I'm also
> not sure if he had effectively modeled a film response curve, or if he
> was simply working on preventing highlights from "blowing out." I
> suppose I'll be emailing him soon to find out more.
>
> If taken to its limit, I think my idea is a bit more ambitious and
> versatile.
>

True.  If I recall correctly, Daren's was not designed to model any physical
film or eye response.  However, the way in which it was implemented might be
good to notice.  He implemented it by replacing the "gamma_correct" and
"clip_colour" functions in POV, instead of using post process.

Also keep in mind that the actual viewing of the image will be based both on
the functions used to convert the floating point value into a limited-range
RGB value AND by the gamma settings of the viewing device (LCD, plasma, or
CRT).  Of course, if you're printing to a device that is capable proper
color matching, then this could be a very useful feature for high-quality
realistic output.

-Nathan

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
>   DBL Depth;
>     The distance the ray went before it hit anything, I guess.

yes.  Currently if the ray hits a clear object, it will give the distance to
the clear object.  This could be changed so that it returns the distance to
the first opaque object that is hit (the code exists to allow that, which
could be useful for media container objects).

Also, this value is currently NOT anti-aliased.  It would be great if it
could be, but I'm not sure of a good way to do that.

>   COLOUR Colour;
>     Clipped or unclipped? I don't know...

raw (unclipped) floating-point values

>   VECTOR IPoint;
>     The intersection point.(What is this for background pixels?)

I don't remember what it is for background (probably garbage or <0,0,0>).  A
programmer writing a post_process filter should check Depth first.

>   VECTOR INormal;
>     The unperturbed surface normal at the intersection point.(Again,
> what is this for background pixels?)

again, I don't know what it would be for background pixels - most likely
garbage.

>   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.

yes.  AFAIK, this currently will be garbage if uv_mapping is not used for
the object.

>   int Object;
>     An index for the first object hit?

Currently not fully implemented.  The goal is to eventually allow the user
to specify an index for an object, like this:

object{
  myObject
  index 12
}

And then in the post_process section, they can apply an object-specific
effect, like this:

global_settings{
  post_process{
    object_glow { colour rgb<0,1,0> effect_size 3 index 12 }
  }
}

This object_glow effect would then produce a green glow around the object
with index 12.  (Of course, you wouldn't be able to 'see' the object through
any other object (such as a clear media container), since the
post-processing buffer would contain the index to the media-container object
instead of the object that was beyond it.

All of these values currently suffer from the fact that they are not
anti-aliased.  Please note that while it would be relatively easy to simply
anti-alias the raw values that are stored, it may not produce the desired
results.  (I do hope to test that eventually, to see if it would work.)

-Nathan

Post a reply to this message

Chris Huff wrote in message ...
>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"? :-)


How about a post-process that will run a pov-script macro?  It would allow
the user to create any custom post-process filter that they need, and would
be completely platform-independant.  The disadvantage to this is that it
wouldn't be very fast, but,for most post-processing, that wouldn't matter.

Mark

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote in message
>Sorry, I made a mistake there. Both ends of the response curve are
>typically compressed, or lower in contrast. Black and near-black
>values are brought closer together. Likewise, white and near-white
>values are also brought closer together.


This sounds like it would solve the problems I've been having with
implementing wavelength-dependent Rayleigh scattering.

Mark

Post a reply to this message

On Mon, 24 Apr 2000 00:18:04 -0400, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>>   COLOUR Colour;
>
>raw (unclipped) floating-point values

Is this value anti-aliased? I would think it would be.

What sort of range do the values have in a "typical" scene? 

What sort of min/max limits might be imposed on the values? (Simply
the limits of floating point notation?)

Are these values ever negative?

Thanks,
Glen

Post a reply to this message

On Mon, 24 Apr 2000 00:45:49 -0400, Glen Berry wrote:
>What sort of range do the values have in a "typical" scene? 

In a scene with no funny textures or light sources, it is usually
in the range of 0 to 1, but lots of bright lights can cause areas
that are washed out.  Assuming that all of the objects have diffuse,
specular, reflection, filter, ambient, and transmit values that sum 
to 1 or less, it shouldn't ever be more than the sum of the values
of all the light sources in the scene, plus the largest ambient
value in the scene.

>What sort of min/max limits might be imposed on the values? (Simply
>the limits of floating point notation?)

Before they're clipped, yes.

>Are these values ever negative?

They can be, if you specify negative light sources or negative 
finish properties.

-- 
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

On Sun, 23 Apr 2000 20:01:21 -0700, Ken <tyl### [at] pacbellnet> wrote:

>Someone once suggested a filter matrix similar to the one used by paint
>programs such as the one available in PSP.

I was one of the people in favor of that idea, but that technique is
more suited to effects involving spatial pixel-displacement. I don't
need to move any pixels here, just alter their intensities and/or
color values.

Of course, it would be great to have both types of effects available
in the post-processing stage.

Later,
Glen Berry

Post a reply to this message