I have a very thin object that is not showing up correctly because some
pixels pick it up and others don't hence creating jaggies, even with
anti-aliasing. My question is, what do I adjust in anti-aliasing to improve
this? And does increasing or decreasing the threshold provide for a better
sample?

Thanks in advance!

Post a reply to this message

Chris Becker <cmb### [at] ritedu> wrote:
> I have a very thin object that is not showing up correctly because some
> pixels pick it up and others don't hence creating jaggies, even with
> anti-aliasing. My question is, what do I adjust in anti-aliasing to improve
> this? And does increasing or decreasing the threshold provide for a better
> sample?

  Try +a0.0 if it helps. (Note that it will slow down the rendering a lot.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I don't think this would be of much help here.
Try increasing the recursion depth (+r4 or +r5) instead, this also slow down things,
especially with method 2.

If this doesn't work either, render at bigger resolution and re-size your picture
with your favourite paint program.

--
Jonathan.

Home: http://digilander.iol.it/jrgpov


"Warp" <war### [at] tagpovrayorg> ha scritto nel messaggio
news:3ca678ed@news.povray.org...
> Chris Becker <cmb### [at] ritedu> wrote:
> > I have a very thin object that is not showing up correctly because some
> > pixels pick it up and others don't hence creating jaggies, even with
> > anti-aliasing. My question is, what do I adjust in anti-aliasing to improve
> > this? And does increasing or decreasing the threshold provide for a better
> > sample?
>
>   Try +a0.0 if it helps. (Note that it will slow down the rendering a lot.)
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote:
> If this doesn't work either, render at bigger resolution and re-size your picture
> with your favourite paint program.

  How is this different from using +a0.0?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

My fault. I did some tests and have to say that +a0.0 worked better than +a0.1 +r5,
even if it is way slower.

Anyway, IMHO, it's better to render at bigger resolution. This is a pretty common
technique to avoid many AA pitfalls.

--
Jonathan.

Home: http://digilander.iol.it/jrgpov

"Warp" <war### [at] tagpovrayorg> ha scritto nel messaggio
news:3ca6f7d6@news.povray.org...
> JRG <jrg### [at] hotmailcom> wrote:
> > If this doesn't work either, render at bigger resolution and re-size your picture
> > with your favourite paint program.
>
>   How is this different from using +a0.0?
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
> JRG <jrg### [at] hotmailcom> wrote:
> > If this doesn't work either, render at bigger resolution and re-size
> > your picture with your favourite paint program.
> 
>   How is this different from using +a0.0?

+a0.0 forces all pixels to go to the full depth.

+a0.1 at a higher resolution simulates a minimum depth of anti-aliasing,
without forcing full depth for all pixels.

A minimum aa depth might be a useful feature.

-- 
Rusty is rendering!

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote:
> Anyway, IMHO, it's better to render at bigger resolution. This is a pretty common
> technique to avoid many AA pitfalls.

  I still don't understand how that's different from using +a0.0.
(What +a0.0 does in practice is exactly what you propose: It kind of renders
an image at higher resultion and "scales" it down to the desired resolution.
This happens because it sends the extra rays for *each* pixel regardless of
what there is in the image; that's exactly the same as rendering at higher
resolution. You can control the extra resolution with +r.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> +a0.0 forces all pixels to go to the full depth.

  Ie. exactly what rendering at higher resolution does.

> +a0.1 at a higher resolution simulates a minimum depth of anti-aliasing,
> without forcing full depth for all pixels.

  Yes, but rendering at higher resolution forces povray to shoot more rays
even though it wouldn't be necessary.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3ca75d03@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > +a0.1 at a higher resolution simulates a minimum depth of anti-aliasing,
> > without forcing full depth for all pixels.
> 
>   Yes, but rendering at higher resolution forces povray to shoot more rays
> even though it wouldn't be necessary.

+a0.0 forces it to shoot all the rays for every pixel. Rendering at a 
higher resolution and resizing lets you control the minimum sampling 
density (making your objects more likely to be visible) while still 
taking advantage of adaptive sampling for faster rendering.
An additional "minimum samples" control would do the same thing, without 
the additional external step of reducing the final image in size, which 
will give different results with different programs.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

+a0.0 worked perfectly. Plus it fixed some artifacts I had with image maps.
Thanks a bunch!!


"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ca678ed@news.povray.org...
> Chris Becker <cmb### [at] ritedu> wrote:
> > I have a very thin object that is not showing up correctly because some
> > pixels pick it up and others don't hence creating jaggies, even with
> > anti-aliasing. My question is, what do I adjust in anti-aliasing to
improve
> > this? And does increasing or decreasing the threshold provide for a
better
> > sample?
>
>   Try +a0.0 if it helps. (Note that it will slow down the rendering a
lot.)
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

Currently this is the best povray can do (+a0.0 +r9). Notice
the aliasing artefacts on the horizontal lines. 
http://luxlab.com/tmp/aa.png

Rendered at 500% resolution (+a0.3 +r3), low-pass filtered
(Gaussian 2.5 pixels) and resampled. 
http://luxlab.com/tmp/aa_hq.png

I like the one with clean lines.


_____________
Kari Kivisalo

Post a reply to this message

> Rendered at 500% resolution (+a0.3 +r3), low-pass filtered
> (Gaussian 2.5 pixels) and resampled.
> http://luxlab.com/tmp/aa_hq.png
>
> I like the one with clean lines.
>
>
> _____________
> Kari Kivisalo


Kari, what is the difference between your method and rendering at 500 %,
applying a mosaic filter (5 pixels) and resizing with method "nearest
neighbor"?

Norbert

Post a reply to this message

On Mon, 1 Apr 2002 09:33:30 +0200, "Norbert Kern"
<nor### [at] t-onlinede> wrote:

>Kari, what is the difference between your method and rendering at 500 %,
>applying a mosaic filter (5 pixels) and resizing with method "nearest
>neighbor"?

Gaussian blur uses a Gaussian distribution of samples and is more
'natural' than a mere average. They are both low-pass filters, one
just happens to be closer to reality, IMHO.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

> Gaussian blur uses a Gaussian distribution of samples and is more
> 'natural' than a mere average. They are both low-pass filters, one
> just happens to be closer to reality, IMHO.
>
>
> Peter Popov ICQ : 15002700


thanx

Norbert

Post a reply to this message

Norbert Kern wrote:
>
> Kari, what is the difference between your method and rendering at 500 %,
> applying a mosaic filter (5 pixels) and resizing with method "nearest
> neighbor"?

http://luxlab.com/tmp/aa_mosaic.png

Scene (thin lines) from http://www.povworld.org/povray/aa.html

plane{z,0
  pigment{gradient y
    pigment_map{
      [0 rgb 1]
      [0.47 rgb 1]
      [0.47 rgb 0]
      [0.53 rgb 0]
      [0.53 rgb 1]
      [1 rgb 1]
    }
  }
  finish{ambient 1} scale .1 rotate y*-50
}

camera{location <0,0,-5> look_at 0}


The most important part is the Gaussian blur. I used 500% resolution
just to get those very thin lines. For normal a scene 200% to 300% and
1 to 1.5 pixel blur radius should be enough. The 50% blur radius seemed
to be the minimum required to prevent visible aliasing. The image will
look soft. Sharpening filter will just bring back the the jagged edges.
It's a delicate balance between artefect free and sharp image :)


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:

> 
> Currently this is the best povray can do (+a0.0 +r9). Notice
> the aliasing artefacts on the horizontal lines.
> http://luxlab.com/tmp/aa.png
> 
> Rendered at 500% resolution (+a0.3 +r3), low-pass filtered
> (Gaussian 2.5 pixels) and resampled.
> http://luxlab.com/tmp/aa_hq.png
> 
> I like the one with clean lines.
> 

Looks really smooth. But I think it makes the lines also appear thicker 
than they are. You get a similar result when you just 'blur' the texture in 
POV-Ray and then use the normal aa method without oversizing and scaling:

pigment{gradient y
        pigment_map{
        [0 rgb 1]
        [0.41 rgb 1]
        [0.5 rgb 0.3]
        [0.59 rgb 1]
        }
}

However the bluring would have to be done dependend on the distance to 
remove the artifacts in the mid-distance.

Maybe one could add a 'blur texture when far away'-feature to POV.

- Micha

-- 
objects.povworld.org - The POV-Ray Objects Collection
book.povworld.org    - The POV-Ray Book Project

Post a reply to this message

> The most important part is the Gaussian blur. I used 500% resolution
> just to get those very thin lines. For normal a scene 200% to 300% and
> 1 to 1.5 pixel blur radius should be enough. The 50% blur radius seemed
> to be the minimum required to prevent visible aliasing. The image will
> look soft. Sharpening filter will just bring back the the jagged edges.
> It's a delicate balance between artefect free and sharp image :)
>
>
> _____________
> Kari Kivisalo

I made some experiments with your method this afternoon.
It is much better than my method, which I used in my two last IRTC entries.
I will no more use normal POV-Ray antialiasing, as such methods show enhance
most pictures considerably.
As an added benefit you get an high res version for printing at the same
time.

Post a reply to this message

"Norbert Kern" wrote:
> I made some experiments with your method this afternoon.
> It is much better than my method, which I used in my two last IRTC entries.
> I will no more use normal POV-Ray antialiasing,

Me too. And it seems to work well even with non antialiased pics.

--
Jonathan.

Home: http://digilander.iol.it/jrgpov

Post a reply to this message

Micha Riser wrote:
>
> But I think it makes the lines also appear thicker
> than they are.

Which brings us to the question of optimal sampling filter
for 2D signal. My theory is that the artefacts in the default
povray aa and mosaic filtered image appear because the sampling
filter is a rigid box. This produces a ringing efect. This can
be avoided by sacrificing higher frequencies and using a smooth
edged filter.

This increases noise but reduces sampling artefacts:
+am1 +a0.0 +r9 +j13.5

It's always a trade-off :(


_____________
Kari Kivisalo

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:
> It is much better than my method, which I used in my two last IRTC entries.
> I will no more use normal POV-Ray antialiasing, as such methods show enhance
> most pictures considerably.

  I don't think you can do that with an IRTC entry. The rules prohibit
post-processing.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
>
>   I don't think you can do that with an IRTC entry. The rules prohibit
> post-processing.

Do they prohibit anti-aliasing or resampling? This is just advanced aa.
Or if that doesn't fly, then it's per pixel weighted average contrast
adjustment :)


_____________
Kari Kivisalo

Post a reply to this message

+am1 +a0.0 +r9 +j13.5

http://luxlab.com/tmp/aa_noise.png


_____________
Kari Kivisalo

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3ca8be48@news.povray.org...

>   I don't think you can do that with an IRTC entry. The rules prohibit
> post-processing.

I should quote the rules:
http://www.irtc.org/stills/faq.html#q1.1.11

[1.1.11] Exactly what do you mean by "post-processing"?

"One guideline that has been mentioned is that
any process which affects every pixel in the image is usually okay,
but that's not a hard and fast rule--it's just used to encompass gamma
correction, resizing, conversion to JPEG format, and so forth, all of
which are legal."

I see application of the method as a special form of image resizing, which
is certainly allowed.
But perhaps I´m not right here.

Norbert

Post a reply to this message

Kari Kivisalo <pro### [at] luxlabcom> wrote:
> Do they prohibit anti-aliasing or resampling? This is just advanced aa.
> Or if that doesn't fly, then it's per pixel weighted average contrast
> adjustment :)

  It is post-processing in an extent prohibited by the rules. I don't see
any rule allowing resizing the rendered image.
  If that would be allowed, what else? Some filtering? Blurring?
Stylisizing? Lens flares?

  No, the rules don't allow that kind of post-processing, period.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3ca8e4d2@news.povray.org...

>   It is post-processing in an extent prohibited by the rules. I don't see
> any rule allowing resizing the rendered image.
>   If that would be allowed, what else? Some filtering? Blurring?
> Stylisizing? Lens flares?
>
>   No, the rules don't allow that kind of post-processing, period.

resizing is allowed :

http://www.irtc.org/stills/faq.html#q1.1.14

[1.1.14] Is it legal to resize my image after it is rendered?
Yes, it is. Be careful doing it, though--unless done correctly, resizing can
often add unwanted visual artifacts to an image.

Norbert

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:
> I see application of the method as a special form of image resizing, which
> is certainly allowed.

  I think that's really bending the rules.

  The purpose of the contest is to see what a renderer can do. In order to
achieve this purpose, only the image output by the renderer is allowed.
  Adjusting brightness/contrast is in the limits of this, although still
allowed.
  However, improving the antialiasing of an image by post-processing it
with a paint program clearly breaks this purpose and the rules. The resulting
image is not what the renderer generated, but it has been improved with
a paint program.

  There's a simple way of seeing the difference between adjusting
brightness/contrast and smoothing an image by scaling it smaller (ie.
improving its antialiasing): If the image has some pixel-sized artifacts
(which usually appear due to bad antialiasing), brightness/contrast
adjustments will not do anything about it, but they will still be there.
However, scaling the image smaller can get rid of these artifacts. Thus
what it is doing here is to remove artifacts produced by the renderer with
a paint program. The resulting image is not the one produced by the
renderer, but an improved one.
  If that's not illegal post-processing, then what is?
  How is this different from, for example, applying a blur filter with the
paint program to remove pixelation? Why blurring should be any more illegal?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:
> resizing is allowed :

> http://www.irtc.org/stills/faq.html#q1.1.14

> [1.1.14] Is it legal to resize my image after it is rendered?
> Yes, it is. Be careful doing it, though--unless done correctly, resizing can
> often add unwanted visual artifacts to an image.

  See my other post.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> 
> Norbert Kern <nor### [at] t-onlinede> wrote:
> > I see application of the method as a special form of image resizing, which
> > is certainly allowed.
> 
>   I think that's really bending the rules.

Resizing is allowed.


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo <pro### [at] luxlabcom> wrote:
>>   I think that's really bending the rules.

> Resizing is allowed.

  My statement still holds.

  I don't think that the people who decided about that rule thought that
it could be used to enhance the quality of the image.
  It's the spirit of the IRTC rules that the quality of the image produced
by the renderer should not be enhanced by post-processing. The image should
be the one produced by the renderer, with no modified quality. If the
image produced by the renderer had artifacts, it's against the rules to
remove these artifacts with a paint program. Using the resizing trick
is essentially doing this.
  We should think about the rules in their whole context and understand
the spirit of the rules, not just their letter.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Sat, 30 Mar 2002 17:56:47 -0500, "Chris Becker" <cmb### [at] ritedu>
wrote:

>I have a very thin object that is not showing up correctly because some
>pixels pick it up and others don't hence creating jaggies, even with
>anti-aliasing. My question is, what do I adjust in anti-aliasing to improve
>this? And does increasing or decreasing the threshold provide for a better
>sample?
>
>Thanks in advance!
>
>

I had the same problem just a fw days ago: a rendering with very small
text objects.  The anti-aliasing was not really working because
parts of the letters were falling between adjacent pixels, so that
the anti-aliasing was not triggered.  I ended up rendering the image
at double size, with anti-aliasing ... and sizing it down in a paint
package.  That fixed it.

Post a reply to this message

So what's the big deal of actually modifying POV-Ray with a new AA method?
AA shoots multiple rays for a single pixel which is then averaged. How is
that different than just taking a higher rendering of the image and
averaging the pixels? Why is it such a big deal to modify the renderer?
Megapov does post processing and I don't see such huge debates about that...

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ca8ed48@news.povray.org...
> Kari Kivisalo <pro### [at] luxlabcom> wrote:
> >>   I think that's really bending the rules.
>
> > Resizing is allowed.
>
>   My statement still holds.
>
>   I don't think that the people who decided about that rule thought that
> it could be used to enhance the quality of the image.
>   It's the spirit of the IRTC rules that the quality of the image produced
> by the renderer should not be enhanced by post-processing. The image
should
> be the one produced by the renderer, with no modified quality. If the
> image produced by the renderer had artifacts, it's against the rules to
> remove these artifacts with a paint program. Using the resizing trick
> is essentially doing this.
>   We should think about the rules in their whole context and understand
> the spirit of the rules, not just their letter.
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

On 1 Apr 2002 15:08:40 -0500, Warp <war### [at] tagpovrayorg> wrote:
> > It is much better than my method, which I used in my two last IRTC entries.
> > I will no more use normal POV-Ray antialiasing, as such methods show enhance
> > most pictures considerably.
>
>  I don't think you can do that with an IRTC entry. The rules prohibit
> post-processing.

What about writing the same as function in 3.5 ?

ABX

Post a reply to this message

Chris Becker <cmb### [at] ritedu> wrote:
> So what's the big deal of actually modifying POV-Ray with a new AA method?

  Nothing.

> AA shoots multiple rays for a single pixel which is then averaged. How is
> that different than just taking a higher rendering of the image and
> averaging the pixels?

  It's different because the latter method is post-processing. It's not
something the renderer itself supports, but has to be done with a paint
program.

> Why is it such a big deal to modify the renderer?

  It isn't.

> Megapov does post processing and I don't see such huge debates about that...

  Because it's the renderer itself which does it.
  The idea is to participate with the output image of a renderer, not a
rendered image which has been enhanced with another program afterwards.
The IRTC rules prohibit post-processing for this reason.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> What about writing the same as function in 3.5 ?

  How?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 2 Apr 2002 08:15:25 -0500, Warp <war### [at] tagpovrayorg> wrote:
> W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > What about writing the same as function in 3.5 ?
>
> How?

Knowing algorithm for particular effect in 2d manipulation software writing
macro/pattern applied to plane with ambient 1 and diffuse 0 under orthogonal
camera. Then it use all elements of typical still creation process but has the
same effect. OF course it is cheating but probably works.

ABX

Post a reply to this message

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> Knowing algorithm for particular effect in 2d manipulation software writing
> macro/pattern applied to plane with ambient 1 and diffuse 0 under orthogonal
> camera. Then it use all elements of typical still creation process but has the
> same effect. OF course it is cheating but probably works.

  Well, I could just take a photograph, put it as pigment to a plane and
render that plane.
  Technically the resulting image has been produced by the renderer and is
perfectly legal according to the rules.
  However, somehow I doubt that I would win that way. ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> Kari Kivisalo <pro### [at] luxlabcom> wrote:

 >>

>>Resizing is allowed.
>>
> 
>   My statement still holds.
> 

   Hmmm... I think the problem is not "resizing". Altough today paint 
programs can resize much better, only resizing doesn't gives so good 
results, at least not much better than +a0.0. The "artifact" or "moire" 
removing step is done with the previous gaussian filter, and *this is* 
postprocesing, not the resizing. IMHO, resizing only must be still 
allowed, but perhaps has not much sense today, as there are no 
resolution limits for the image (I think this rule was created to allow 
people to fit the maximum resolution allowed at that time).


-- 
Jaime Vives Piqueres

http://www.ignorancia.org/
La Persistencia de la Ignorancia

Post a reply to this message

Jaime Vives <jai### [at] ignoranciaorg> wrote:
>    Hmmm... I think the problem is not "resizing". Altough today paint 
> programs can resize much better, only resizing doesn't gives so good 
> results, at least not much better than +a0.0. The "artifact" or "moire" 
> removing step is done with the previous gaussian filter, and *this is* 
> postprocesing, not the resizing. IMHO, resizing only must be still 
> allowed, but perhaps has not much sense today, as there are no 
> resolution limits for the image (I think this rule was created to allow 
> people to fit the maximum resolution allowed at that time).

  The problem with resizing an image smaller is that there are basically two
ways of doing it (from the point of view of the program):
  1. Make the image smaller by just dropping out pixel rows and columns
appropriately.
  2. Make the image smaller by calculating (weighted) averages of pixel
rows and columns.

  The problem with method 1 is aliasing.
  The problem with method 2 is that it's in practice filtering the image,
which can enhance its visual quality and is thus post-processing.

  There wouldn't be a problem with method 2 if post-processing was not against
the spirit of the competition. IMO it's such a big filtering process that it
does not fit inside the rules.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3ca9aecd@news.povray.org...

<snip>

From what I understand of this debate, does this resize-for-better-aa really
break the rules, either in spirit or fact?

I take your point that to resize to get rid of artifacts is a definate no-no,
but the aa issue seems linked to the size of the image-output, rather than an
inherant problem with the scene.

In other words if the defect corrected by resizing is present in the high
resolution image, then you are breaking the rules. However, if the defect is not
present at high res., and you are merely trying to duplicate the "clean" image
at a lower-res. then I don't think any rules, spirit or fact, have been broken.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3ca9cd6f@news.povray.org...

<snip>

As a personal note, IMHO I've never really understood the IRTC leniency towards
post-process adjustment of brightness/contrast/etc.

I do it, but it seems a damn sight more dishonest than a resize for aa purposes
(never done that as I've never needed to).

Suggest this moves to irtc.general ?

Post a reply to this message

Warp wrote:

>   The problem with method 2 is that it's in practice filtering the image,
> which can enhance its visual quality and is thus post-processing.


   Sure? I've tried it, and I can't get "much better" results *only* 
resizing a 10 times bigger image (with The Gimp), than using +a0.0. The 
only image where I've seen *really* better results was the one posted by 
Kari, where he admits to have used "something more" than a pure resizing 
(still, I can't get such good results even using the gaussian blur on 
"The Gimp"... he surely cheated even more! ;).

 
>   There wouldn't be a problem with method 2 if post-processing was not against
> the spirit of the competition. IMO it's such a big filtering process that it
> does not fit inside the rules.


   No, IMHO, this is not the spirit of the rule about postprocesing. I 
think it tries to avoid mainly someone "adding" extra features to the 
rendering, that is, adding "foregein pixels" (pasting figures or 
objects, adding lens flares/sparkles/glow/etc..). And a "resize", even 
with filters, only plays with rendered pixels.

   Anyhow, the line is very difficult to place... in this case, I think 
it is a harmful postprocesing. A bad image is a bad image even with the 
most fine definition of details (perhaps even worse!). A good image is 
still good with the most poor antialiasing.

   For me, this is the typical "let the judges decide..." :)

-- 
Jaime Vives Piqueres

http://www.ignorancia.org/
La Persistencia de la Ignorancia

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> From what I understand of this debate, does this resize-for-better-aa really
> break the rules, either in spirit or fact?

  If we read the rules literally, resizing is allowed. There isn't anything
saying which resizing methods are allowed and which aren't; resizing is just
allowed, period. So resizing is not technically against the rules.
  However, IMHO using resizing as a method for improved post-process
antialiasing breaks the spirit of the IRTC rules. It's effectively a
post-process filter applied to the rendered image with a paint program.

  I am pretty sure that the people who allowed resizing when writing the
IRTC rules didn't think about this possibility and if they had known about
it, they would have thought more carefully.

> I take your point that to resize to get rid of artifacts is a definate no-no,
> but the aa issue seems linked to the size of the image-output, rather than an
> inherant problem with the scene.

> In other words if the defect corrected by resizing is present in the high
> resolution image, then you are breaking the rules. However, if the defect is not
> present at high res., and you are merely trying to duplicate the "clean" image
> at a lower-res. then I don't think any rules, spirit or fact, have been broken.

  If you make, for example, the typical checkered-floor image (where you can
see the horizon), you will get aliasing artifacts no matter how big you render
the image. However, rendering at for example 8000x6000 and then resizing
it to 800x600 (by using some averaging algorithm) will get rid of most of
the artifacts (if not all of them). This is because most of the artifacts
are pixel-sized and what the resizing does is to calculate the average of
10x10 pixel squares, and these artifact pixels contribute little to the
average, thus practically disappearing. Thus resizing removes the artifacts
produced by the renderer.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> As a personal note, IMHO I've never really understood the IRTC leniency towards
> post-process adjustment of brightness/contrast/etc.

  Usually tuning brightness/contrast does not modify the overall quality
of the image. If there are artifacts in the image, they will not go away
by this.

  (Of course even this has been proven to be false. As seen any some
radiosity experiments, adjusting brightness/contrast to a rather dark
radiosity scene can greatly enhance its visual appeal and quality...)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Jaime Vives <jai### [at] ignoranciaorg> wrote:
>    No, IMHO, this is not the spirit of the rule about postprocesing. I 
> think it tries to avoid mainly someone "adding" extra features to the 
> rendering, that is, adding "foregein pixels" (pasting figures or 
> objects, adding lens flares/sparkles/glow/etc..). And a "resize", even 
> with filters, only plays with rendered pixels.

  By the same definition using filters like blur and motion blur is just ok.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3ca9d501@news.povray.org...
>
>   Usually tuning brightness/contrast does not modify the overall quality
> of the image. If there are artifacts in the image, they will not go away
> by this.
>

True, such tuning shouldn't affect technical scores (but I bet it does) -
however, it might have quite an impact on artistic. The adjustment shouldn't be
necessery if you set up your scene correctly in the first place....

On a related note, I've occasionally been quite pleased with some "improvements"
made to my images by conversion to .jpg.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3ca9aeed@news.povray.org...
> W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > What about writing the same as function in 3.5 ?
>
>   How?


Its easy for mosaic filtering and subsequent resizing.
I will write such a macro to avoid future discussions.
But in my eyes correction of gamma, brightness or contrast are much more
bending the rules than the antialiasing methods in discussion.

By the way using Pov-Ray for filter effects one can do some nice effects.
Does anybody know the exact algorithm for Gaussian Blur?
How the image edges are processed?


Norbert

Post a reply to this message

On Tue, 2 Apr 2002 19:51:42 +0200, "Norbert Kern"
<nor### [at] t-onlinede> wrote:
> By the way using Pov-Ray for filter effects one can do some nice effects.

not exactly blur but uses general method for such kind of effects:
http://news.povray.org/p8r76u08vo673fksp4jaks59h2au3bppkb%404ax.com

ABX

Post a reply to this message

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> schrieb im Newsbeitrag
news:u2sjausb7r0g011em62gir4o87q3561mq0@4ax.com...

> not exactly blur but uses general method for such kind of effects:
> http://news.povray.org/p8r76u08vo673fksp4jaks59h2au3bppkb%404ax.com
>
> ABX



thanx, but I thought more in the direction of a seperate pass for
postprocessing with Pov-Ray.
It is because proximity pattern is extremely useful in some cases, but it is
slow.

Norbert

Post a reply to this message

On Tue, 2 Apr 2002 20:14:35 +0200, "Norbert Kern"
<nor### [at] t-onlinede> wrote:
> "W?odzimierz ABX Skiba" <abx### [at] babilonorg> schrieb im Newsbeitrag
> news:u2sjausb7r0g011em62gir4o87q3561mq0@4ax.com...
>
> > not exactly blur but uses general method for such kind of effects:
> > http://news.povray.org/p8r76u08vo673fksp4jaks59h2au3bppkb%404ax.com
> >
> > ABX
>
> thanx, but I thought more in the direction of a seperate pass for
> postprocessing with Pov-Ray.
> It is because proximity pattern is extremely useful in some cases, but it is
> slow.

as I said I wasn't reffering to usefulnes of proximity in the subject of this
thread but reffered to general method of applying filters - sampling one pattern
(image_map, object pattern, whatever), then apply some weighting/equation,
subsample if necessary, output new rgb

ABX

Post a reply to this message

Jaime Vives wrote:
>
> The "artifact" or "moire"
> removing step is done with the previous gaussian filter, and *this is*
> postprocesing, not the resizing.

It's just another resampling filter. Look at the table.
http://www.genaware.com/html/support/faqs/imagis/imagis10.htm

Will all IRTC images that have been resized with other than
nearest neighbour method have to be disqualified now?


_____________
Kari Kivisalo

Post a reply to this message