Hello!

First I want to say that I think Megapov is really great!

Secondly I want to say that I have some suggestions for improvements. (Is
this the correct group for this?)

Here's some suggestions for the patterned blur feature:

1) Make the center of the patterns appear in the center of the image. Make
<-0.5,-0.5,0> be the lower left corner (instead of <0,1,0>) and <0.5,0.5,0>
the upper right corner (instead of <1,0,0>). This will make the patterns in
patterned blur work in the same way as normal patterns in the camera
statement does.

2) Make the amount of blur resolution-independent. Blur the image based on %
of width or something instead of in pixels. I really think we should
continiue the lovely idea that everything in a POV-Ray image is completely
resolution independent.

3) Support "non-integer blurring". Currently when you use patterned blur
certain bands appear because only "integer pixel blurring" is supported, and
not the values in between. It shouldn't be too hard to support non-integer
values too (said by a regular user unable to program pathes himself).

I hope you will consider these changes, as I think they are sensible and a
bit more consistent with the way official POV-Ray works. Feel free to ask me
for details if something is a bit unclear.

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

In article <393948d4@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> First I want to say that I think Megapov is really great!

You are certainly not alone!


> Secondly I want to say that I have some suggestions for improvements. (Is
> this the correct group for this?)

Yes, this is the correct group.


> 1) Make the center of the patterns appear in the center of the image. 
> Make <-0.5,-0.5,0> be the lower left corner (instead of <0,1,0>) and 
> <0.5,0.5,0> the upper right corner (instead of <1,0,0>). This will 
> make the patterns in patterned blur work in the same way as normal 
> patterns in the camera statement does.

I chose to have upper left be <0,1,0> and lower right be <1,0,0> for all 
of the filters which use pigments, so it would be easy to control the 
filter with an image_map(useful for logos, etc). If it is "centered", 
the image_map has to be translated into position.
I really didn't even think about camera normals...I think the method I 
chose is more intuitive and easier to use.


> 2) Make the amount of blur resolution-independent. Blur the image 
> based on % of width or something instead of in pixels. I really think 
> we should continiue the lovely idea that everything in a POV-Ray 
> image is completely resolution independent.

This is certainly a good suggestion, I would have done it if I had 
thought of it...


> 3) Support "non-integer blurring". Currently when you use patterned 
> blur certain bands appear because only "integer pixel blurring" is 
> supported, and not the values in between. It shouldn't be too hard to 
> support non-integer values too (said by a regular user unable to 
> program pathes himself).

I don't understand what you mean here...the color values averaged 
together are float type, not integer. Or do you mean non-integer blur 
amounts? The patch should already do that...the radius variable is a 
"DBL", or "double", and is multiplied with the red channel of the 
pigment color, which is a floating point number("COLC", or float).
Or do you mean the colors between pixels? That is not part of the 
available data, it would have to be interpolated from the surrounding 
pixels.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
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

"Chris Huff" wrote:
> I chose to have upper left be <0,1,0> and lower right
> be <1,0,0> for all of the filters which use pigments,
> so it would be easy to control the filter with an
> image_map(useful for logos, etc). If it is "centered",
> the image_map has to be translated into position.

But <0,1,0> is *lower* left! See scene in end of message.

> I really didn't even think about camera normals...
> I think the method I chose is more intuitive and easier
> to use.

When using image_maps, yes. When using ripples, spherical, boxed, and many
other patterns, no!
The normal_in_camera feature and the patterned_blur feature really are very
much alike, so I think it would be quite natural to make the alignment work
the ame way too.

> > 2) Make the amount of blur resolution-independent.
> > Blur the image based on % of width or something instead
> > of in pixels.
>
> This is certainly a good suggestion, I would have done it
> if I had thought of it...

Hmm, is it too late to change it for the next version?

> > 3) Support "non-integer blurring". Currently when you
> > use patterned blur certain bands appear because only
> > "integer pixel blurring" is supported, and not the
> > values in between.
>
> I don't understand what you mean here...the color values
> averaged together are float type, not integer. Or do
> you mean non-integer blur amounts?

Yes. You could say the radius, in pixels, of the blur.

> The patch should already do that...

See the code below. The banding is very clear (and not very nice).

#version unofficial MegaPov 0.5;

global_settings {
   post_process {
      patterned_blur {8, 0, 0, spherical
         color_map {[0 rgb 1][1 rgb 0]}
         translate <0,0,0> // upper left corner - shows banding
      }
   }
}

sky_sphere {
   pigment {
      radial rotate 90*x frequency 32
      color_map {[0.5 rgb 0][0.5 rgb 1]}
   }
}

// so POV-Ray doesn't complain about no objects in scene:
sphere{-z,.1 pigment{color 0}}

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

In article <3939c96f@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> But <0,1,0> is *lower* left! See scene in end of message.

Hmm, so it is upside-down again...
My original patch had it this way, but I enclosed the corrections for 
the problem in a reply to my original source code post. I guess not all 
of them got in...
BTW: multiply, add, clip_colors, exponent, and find_edges work properly, 
it is just the patterned blur patch that has the upside-down pigment. 
The line:

        Loc[1] = (DBL)y/height;

In doPostPatternBlur(), file postproc.c, needs to be changed to this:

        Loc[1] = 1-((DBL)y/height);


> > This is certainly a good suggestion, I would have done it
> > if I had thought of it...
> 
> Hmm, is it too late to change it for the next version?

That would be up to Nathan...I can get to work implementing it and 
release the changes, though.


> Yes. You could say the radius, in pixels, of the blur.
>
> > The patch should already do that...
> 
> See the code below. The banding is very clear (and not very nice).

The problem here is probably that the part of the conditional which 
restricts the samples to a circle was omitted somewhere along the line, 
so the samples are taken in a Radius sized square. The line:

if(((x+l >= 0)&&(x+l < width)) && (((y+j >= 0)&&(y+j < height))))

In doPostPatternBlur(), file postproc.c, needs to be changed to 
something like this:

if(((x+l >= 0)&&(x+l < width)) && (((y+j >= 0)&&(y+j < height)))) &&
   (sqrt(sqr(j)+sqr(l)) < Task->Radius)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
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

"Rune" <run### [at] inamecom> wrote in message
news:3939c96f@news.povray.org...
| "Chris Huff" wrote:
| > I chose to have upper left be <0,1,0> and lower right
| > be <1,0,0> for all of the filters which use pigments,
| > so it would be easy to control the filter with an
| > image_map(useful for logos, etc). If it is "centered",
| > the image_map has to be translated into position.
|
| But <0,1,0> is *lower* left! See scene in end of message.
|
| > I really didn't even think about camera normals...
| > I think the method I chose is more intuitive and easier
| > to use.
|
| When using image_maps, yes. When using ripples, spherical, boxed, and many
| other patterns, no!
| The normal_in_camera feature and the patterned_blur feature really are very
| much alike, so I think it would be quite natural to make the alignment work
| the same way too.

Just thought I'd chime-in here...
Only just started to get a look at the patterned_blur feature and I'm going to
have to go along with what Rune is saying.  With it not being like the usual
centered patterns and offcenter mapping it does seem to break tradition.
Although, I wonder what people would think of centered maps in pigments,
normals, and height_field instead?  I know it has been wanted by some and not
by others, the reason being how it might or might not be more difficult to
transform a map when a corner isn't at <0,0,0>.
Anyway, it may be early for feedback on this yet, but my bet is many people
will cringe at the prospect of non-centered patterns.

Bob

Post a reply to this message