![](/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) |
On Sun, 23 Apr 2000 20:01:21 -0700, Ken <tyl### [at] pacbell net> 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
|
![](/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...
> >> COLOUR Colour;
> >
> >raw (unclipped) floating-point values
>
> Is this value anti-aliased? I would think it would be.
Yes, this value is anti-aliased.
> What sort of range do the values have in a "typical" scene?
As Ron pointed out, usually 0..1. However, phong and specular highlights
can send these values _very_ high (in the hundreds, at least).
-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) |
Glen Berry wrote:
> I'm not sure yet if the human eye responds to light intensity values
> in a similar non-linear way, but I think it does. I know that human
> hearing is non-linear in its perception of dynamic range, but I can't
> say for sure about human vision yet.
The human eye responds in a fashion that is non-linear but dependent
upon the response of neighboring photosensitive elements. If one
photosensitive element (rods, I'm pretty sure) fires, it inhibits its
neighbors from firing. The result: when you look at something bright,
many of your rods are turned off, and you don't perceive it as being too
bright, and when you look around in darkness, pretty much all the rods
are turned on, but they're probably not seeing much, because it's dark.
This allows people (and other animals, but I'm not sure how widespread
this is) to move from bright light to darkness or combinations of those
fairly easily.
The textbook example of a scene that is affected by this is a daytime
interior with large windows. Using conventional photography, it's
pretty much impossible to make the room look the way the human eye
perceives it. If you adjust for the actual lighting in the room, the
outside looks too bright. If you adjust for the lighting of the outside
as seen through the window, the inside looks too dark. The only
workarounds involve lighting tricks: add more light to the interior, or
wait until twilight so the ambient light levels are better balanced.
Simple post-processing doesn't work so well here; one must apply
different processing to different parts of the scene to make it look
right. There's a paper at SIGGRAPH from last year that discusses this:
"LCIS: A Boundary Hierarchy for Detail-Preserving Contrast Reduction" by
Tumblin and Turk from Georgia Tech.
-Mark Gordon
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 <3903B901.58BBF765@pacbell.net>, lin### [at] povray org
wrote:
> 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.
I believe that is called a "convolution matrix"(?). It should be pretty
easy to do, and is one of the approaches I have been trying with my
pattern blurring patch. However, it doesn't really have anything to do
with the stuff currently being discussed.
--
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 <6rEDOSgUj1saLWQcNmMbValfG6+w@4ax.com>, Glen Berry
<7no### [at] ezwv com> wrote:
> My first idea was the more general method of supplying custom
> parameters to achieve a given result.
Yeah, what I had in mind was something like a "brightness" filter where
things like sienna photos could be done by specifying two "end colors"
for a monochrome gradient. Like in my z_buffer patch, which allowed you
to specify two colors to blend between.
> Perhaps to even include a "formula parser" that would allow the
> end-user to enter a unique formula for the effect desired.
I really think the isosurface functions would be good for this. I don't
see a real reason to "reinvent the wheel". The code for these already
exists...it would just have to be modified to support the extra
variables.
--
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) |
Chris Huff wrote:
> I believe that is called a "convolution matrix"(?). It should be pretty
> easy to do, and is one of the approaches I have been trying with my
> pattern blurring patch. However, it doesn't really have anything to do
> with the stuff currently being discussed.
It applies in as much as it is related to post processing.
--
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) |
In article <3903cb3b@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
> 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).
Hmm, I think both could be useful...though maybe there should be two
versions: one which is the distance to the first object with
filter/transmit != 1 or with an ior or interior attenuation(these two
conditions should avoid bumping into media containers), the second would
be the distance to the first opaque 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:
> ...
> 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.
Hmm, it would be nice to have this use the "label" feature, having a new
"index" feature seems to make for a total of 3 different ways to specify
an object. The labels could probably be represented internally as an
index, though...but I have another idea:
Why not just make this an object pointer? You could add some
post_process flags to the object, maybe including an ID number(or a
string, light groups style), and having the pointer to the object
accessible could also come in handy. It would point to the object at
Depth, not necessarily the first object.
> 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.)
Again, it could be nice to have anti-aliased as well as non anti-aliased
versions, although that would double the memory usage...maybe just
include code that could do that if it is needed in the future, and
comment it out for now.
--
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 <39046D46.F8394DEF@pacbell.net>, lin### [at] povray org
wrote:
> It applies in as much as it is related to post processing.
It is related to post processing, but not to film types, response
curves, antiqueing effects, etc.
If I attempt a post_process filter, I will probably try to make one of
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 Mon, 24 Apr 2000 07:29:58 -0500, Mark Gordon <mtg### [at] mailbag com>
wrote:
>The textbook example of a scene that is affected by this is a daytime
>interior with large windows. Using conventional photography, it's
>pretty much impossible to make the room look the way the human eye
>perceives it. If you adjust for the actual lighting in the room, the
>outside looks too bright. If you adjust for the lighting of the outside
>as seen through the window, the inside looks too dark. The only
>workarounds involve lighting tricks: add more light to the interior, or
>wait until twilight so the ambient light levels are better balanced.
There is a technique used in traditional photgraphic printing called
"unsharp masking." This is *not* to be confused with the same term as
applied to Photoshop. The term used in Photoshop refers to a method of
manipulating an image's sharpness. What I ame going to describe, is a
method to control the tonal range or contrast of an image - not a
sharpness adjustment.
When printing color slides onto photographic paper, the slide usually
has a much larger dynamic range than the paper. The result is that
highlights tend to wash out, and shadows can turn into solid black.
The first step to correct this, is to prepare an intentionaly
blurred, B&W *negative* copy of the slide. This negative copy is
processed to be very low in contrast, with no areas of the negative
allowed to go pure black. In other words, it's a very "thin," and
transparent negative image.
Next, the original color slide and this blurred negative copy are
sandwiched together in perfect registration (their images are
perfectly over-lapped.) This combination is then printed to the photo
paper.
The result is that the contrast range of the two sandwiched images is
less than the contrast range of the original color slide. In areas
where the slide is more transparent, the negative compensates by being
more dense.
The reason for blurring the negative is to avoid artifacts that might
be created on sharp edges in the original photo. Artifacts could also
appear around each individual grain or dye-cloud in the image. The
blurring avoids this as well.
I think a similar method could be implemented as a post-process effect
in POV-Ray.
1) Take the raw, unclipped image and create a monochrome RGB copy.
2) Convert the copy to a "negative" image.
3) Blur the negative somewhat heavily.
4) Adjust the density range of the negative to prevent any values
from being too dark (this is done by setting the "black-point" to a
very high value and rescaling all the values in the negative.)
5) Combine the images together and subtract the negative from the
positive.
6) Convert this floating point image to the final color space
desired, ie 24bit color. Optionally, one could also apply "film curve"
type effects at this stage.
This should have the effect of reducing the highlight areas that would
have otherwise recorded as a washed-out area of white.
********************
I hope that everyone can follow my explanation. Perhaps I should refer
to the process as "Reverse Unsharp Masking," to avoid confusion with
the Photoshop plugin. (The "reverse" aspect coming from creating a
"reversed" or negative image during the process.) Perhaps we can
simply refer to it as RUM in the future?
Let me know what you think. All comments are appreciated.
Thanks,
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) |
In article <nm8EOXFTD8R+DNvuTiKVKnuQNAlg@4ax.com>, Glen Berry
<7no### [at] ezwv com> wrote:
> There is a technique used in traditional photgraphic printing called
> "unsharp masking." This is *not* to be confused with the same term as
> applied to Photoshop. The term used in Photoshop refers to a method of
> manipulating an image's sharpness. What I ame going to describe, is a
> method to control the tonal range or contrast of an image - not a
> sharpness adjustment.
This sounds like a very interesting feature, but one thing...
> 3) Blur the negative somewhat heavily.
Is this stage necessary for a filter? It seems that it is only done in
"real life" to avoid problems with slight misalignment or with film
grain, these wouldn't exist in a computer generated image.
--
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) |