![](/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) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Tom Melly <tom### [at] tomandlu co uk> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Tom Melly <tom### [at] tomandlu co uk> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jaime Vives <jai### [at] ignorancia org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> schrieb im Newsbeitrag
news:3ca9aeed@news.povray.org...
> > 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
|
![](/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 Tue, 2 Apr 2002 19:51:42 +0200, "Norbert Kern"
<nor### [at] t-online de> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/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 Tue, 2 Apr 2002 20:14:35 +0200, "Norbert Kern"
<nor### [at] t-online de> wrote:
> "W?odzimierz ABX Skiba" <abx### [at] babilon org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |