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