![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <390380D7.3DF36E34@videotron.ca>, pk <thi### [at] videotron ca>
wrote:
> Don't you think that encapsulating(system call) the code would be
> better?
> And, what if i want to program in basic or pascal or whatever...
> I think that you might want to add some feature directly in MegaPOV's
> code, but still offer the opportunity to use your own post-processing
> stuff on a single image, instead of doing a patch for one job...
Uh, what? I don't understand what you mean...I don't think you are
saying POV should have a built in C/Pascal/BASIC interpreter/compiler so
you could write post-process filters with those, but I don't see what
else you could mean...
POV is written in C, but that language doesn't have anything to do with
POV syntax. The syntax of these "film types" has already been designed
and implemented, it would just be another post_process filter. And the
code is probably pretty well encapsulated already, I think most of the
post_process stuff is in postproc.c and postproc.h. And what do you mean
by "system call"?
Are you trying to say that these filters should be implemented as
separate programs written in any language that are called by POV? I
doubt this is possible to do in a cross-platform way...and how would it
would it be an improvement over the current post_process patch? The
source is available already, you could just modify that. The C code
should be easy enough to copy and modify, even if you don't completely
understand it. And if you insist on writing a filter in a language other
than C, or don't want to put it in the POV-Ray program, you might as
well make it a stand-alone utility.
> > Also, I think the post_process stuff really belongs in the camera, not
> > global_settings. This is just personal preference, though...
> Well... it'd fit better there in most ways of thinking, but if you see
> it in a hierarchical way, where the cam is part of the scene, it'd
> belong in the global settings, i think....
If you viewed the scene that way, the camera should also be in
global_settings...which, of course, it isn't.
It just seems more logical to have things that directly affect the
output image part of the camera statement, rather than global_settings
(which seems to be intended more for settings than for specification of
special effects).
--
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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sun, 23 Apr 2000 20:51:08 -0500, Chris Huff
<chr### [at] yahoo com> wrote:
>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 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Glen Berry <7no### [at] ezwv com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] yahoo com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Glen Berry <7no### [at] ezwv com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 24 Apr 2000 00:18:04 -0400, "Nathan Kopp" <Nat### [at] Kopp com>
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |