 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] luxlab com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
