![](/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) |
Chris Huff wrote:
>
> I think I get what you are saying...instead of adjusting the rgb values
> directly, you want to adjust the brightness of the colors?
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.
Cheers! 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) |
>In development:
>find_edges
> The "cartoon-like" filter. It basically works, but still needs a lot
>of work.
>
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.) 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. Or so I think. I've never actually
tried it out... Could it be of interest?
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.
Simen.
>Does anyone have any suggestions for additional filters? I currently
>have these on the "to-do" list:
>highlight/midtone/shadow level adjustment
>color_function filter
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, 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) |