![](/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 Mon, 1 May 2000 11:29:11 +0200, "Simen Kvaal"
<sim### [at] student matnat uio no> wrote:
>Another post-process (or is it postprocess?): The ability to make a r/b or
>g/r or whatever anaglyph for use with those 3d-glasses.
That sounds like a nice idea. However, one does need two seperate
images to create a red/cyan 3D image. I'm not sure the best way to
approach this.
I wonder if it would be practical or possible to have multiple cameras
in the same scene? One could be assigned the left eye position, and
the other could be the right eye position. Then post-processing could
merge the two images into a single red/cyan 3D image.
Multiple cameras could also have other uses as well. Perhaps it might
speed up rendering the same image geometry from different view points?
I know that someone mentioned an idea like this a long time ago, but I
can't remember the reaction it got.
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwv com to email me. )
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 <390B5DFD.FD77D229@stud.ntnu.no>, Sigmund Kyrre Aas
<as### [at] stud ntnu no> wrote:
> Yes, and by allowing the parameters to be vectors you can adjust the
> colour
> too. Just forgot something on the previous post: "Auto Levels" in
> Photoshop
> would be equal to levels{ 0,1 absolute}. The setting I'd prefer would be
> levels{1,1 relative}
>
> Don't mind asking, I'd really like to see this feature.
I guess I still don't get exactly what you mean...
I would have the syntax be like this:
levels {outMin, outMax, inMin, inMax}
where outMin and outMax specify the range of the result(destination)
colors, and inMin/inMax specify the range to take those values from. All
4 of these can be colors, but inMin and inMax are optional. If you don't
specify them, it will "autorange", and calculate inMin as min(inR, inG,
inB), and inMax as max(inR, inG, inB), and scale each color channel
equally.
--
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 <390d4e69$1@news.povray.org>, "Simen Kvaal"
<sim### [at] student matnat uio no> wrote:
> I saw your test images of the find_edges-filter. That one is very
> useful, although what _I_ personally miss is the ability to make the
> image look more like a wire-frame-model. I have developed an
> algorithm (well... not actually... actually not at all...) that might
> work: One takes the depth information and interprets that as a graph
> of the two coordinate-axes, thus implying a function depth(x, y). The
> natural place to put such a "wire-frame-line" would be where this
> function have "breaks", kinda like discontinuities. (For example in
> the intersection between two spherers.)
Up to this point, it is very similar to the depth edge calculation
method. I take the average difference in depth from the center pixel,
and check for rapid, sharp changes in depth by marking pixels where the
average difference is above a certain threshold. I do something similar
for normals and colors.
> If one takes the gradient of depth(x, y) one obtains a
> 2-vector-field, and taking the norm of that gives g(x, y). Taking the
> norm og the gradient of that function, gives h(x, y). Where this h(x,
> y) takes on very large values, we have a discontinuity in the image.
You lost me here though...somewhere around "taking the norm of a
2-vector-field". And something about taking the gradient of the gradient?
> Another post-process (or is it postprocess?): The ability to make a
> r/b or g/r or whatever anaglyph for use with those 3d-glasses.
As someone else said, this would probably require separate images to be
rendered. The color tinting could be done using color_matrix, and the
images could be combined by using add and multiply with an image_map.
I think something that would be more interesting would be a random-dot
stereogram, or "Magic Eye" stereogram. I have no idea how to do it
though...
--
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 guess I still don't get exactly what you mean...
> I would have the syntax be like this:
> levels {outMin, outMax, inMin, inMax}
> where outMin and outMax specify the range of the result(destination)
> colors, and inMin/inMax specify the range to take those values from. All
> 4 of these can be colors, but inMin and inMax are optional. If you don't
> specify them, it will "autorange", and calculate inMin as min(inR, inG,
> inB), and inMax as max(inR, inG, inB), and scale each color channel
> equally.
Could you elaborate with some pseudocode? How will you use outMin and outMax?
If I understand you correctly you will set the colour with the highest/darkest
value of red, green, or blue to outMax/outMin. "Auto Levels" will then be equal
to levels{0,1}, right? If I apply this to an image with brightest pixel inMax:
inMax outMax change
<.9,.95,.8> <1,1,1> <1.11, 1.05, 1.13>
i.e. the channels will not be scaled equally unless you set outMax to
<.9,.95,.8>/.95 = <.95,1,.84> which is impossible to know beforehand.
I agree your proposed syntax with outMin, outMax, inMin and inMax is better if
you're going for consistency with Photoshop/GIMP/PhotoPaint etc. I will also be
very careful saying "we don't need inMin/inMax" just because I never use it in
those programs. Personally I'd be happy with a feature which allowed me to
adjust the brightness of the darkest range and brightest range of colours
separately, by multiplying a colour expression with the darkest and brightest
pixel present in the image (as I tried to explain in my post from Saturday.)
If you add gamma to the levels expression, you can also adjust the midtones. It
will be a highlight/midtone/shadows (hms) filter, but you will have more
control with what you're doing. With hms you can easily push pixels out of
range.
Phew, hope this makes sense :)
sig.
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, 01 May 2000 19:27:19 +0200, Sigmund Kyrre Aas
<as### [at] stud ntnu no> wrote:
>I agree your proposed syntax with outMin, outMax, inMin and inMax is better if
>you're going for consistency with Photoshop/GIMP/PhotoPaint etc. I will also be
>very careful saying "we don't need inMin/inMax" just because I never use it in
>those programs.
Aren't you a bit confused there? The Photoshop equivalents of "inMin"
and "inMax" are what most people use most of the time. These are the
numbers that are actually adjusted by moving the "visual sliders" on
the levels dialog box. It's the other two numbers that most people
never use, and leave them set on 0 and 255.
I strongly feel that all four numbers should be included in the
filter.
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwv com to email me. )
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) |
Sigmund Kyrre Aas wrote:
...
> inMax outMax change
> <.9,.95,.8> <1,1,1> <1.11, 1.05, 1.13>
Guess I made a mistake here. Photoshop finds the max in each channel:
inMax.r outMax change
.7 1 1.43
inMax.g outMax change
.9 1 1.11
inMax.b outMax change
.8 1 1.25
The three max values doesn't have to be in the same pixel, but you will still
get an uneven scaling of the channels. A pixel with the colours <.7,.9,.8> will
become white instead of having a greenish tint.
In this instance I'd suggest a scaling of 1.11 for all the channels.
sig
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:
>
> Aren't you a bit confused there? The Photoshop equivalents of "inMin"
Yes I am :) Thanks.
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, 01 May 2000 05:42:40 -0400, Glen Berry wrote:
>I know that someone mentioned an idea like this a long time ago, but I
>can't remember the reaction it got.
I actually wrote a patch to do this with POV 2.2, but the code is long
lost now. I also don't remember what reaction it got; I seem to
recall that it was rather lukewarm, if that.
--
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) |
|
![](/i/fill.gif) |
On 1 May 2000 15:15:13 -0400, ron### [at] povray org (Ron Parker)
wrote:
>I actually wrote a patch to do this with POV 2.2, but the code is long
>lost now. I also don't remember what reaction it got; I seem to
>recall that it was rather lukewarm, if that.
Can you remember if having multiple cameras would speed rendering
multiple views of the same scene geometry, at least as it was
implemented in the patch you made? I wish your patch had gotten more
attention and remained with us, in source form if nothing else.
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwv com to email me. )
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) |
I recall talk of multiple camera views for one scene render around here
someplace or at c.g.r.r.
I thought it was deemed implausible or impossible and I certainly don't
remember it had actually been tried.
Where'd that "portal patch", or whatever it was being called, go to?
Seems that was Chris Huff trying it. That seemed a similar thing.
Bob
"Glen Berry" <7no### [at] ezwv com> wrote in message
news:KQcOOXNS046mLSvWPFwpFtBWB0PQ@4ax.com...
| On 1 May 2000 15:15:13 -0400, ron### [at] povray org (Ron Parker)
| wrote:
|
| >I actually wrote a patch to do this with POV 2.2, but the code is long
| >lost now. I also don't remember what reaction it got; I seem to
| >recall that it was rather lukewarm, if that.
|
| Can you remember if having multiple cameras would speed rendering
| multiple views of the same scene geometry, at least as it was
| implemented in the patch you made? I wish your patch had gotten more
| attention and remained with us, in source form if nothing else.
|
| Later,
| Glen Berry
|
| ( Remove the "7" from 7no### [at] ezwv com to email me. )
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) |