 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406ecc03@news.povray.org>, Warp <war### [at] tag povrayorg>
wrote:
> At least I would disallow using an external image manipulation program
> which is unrelated and separate from the renderer.
What's the difference between doing some operation using an external
program that's unrelated to the renderer and using an external program
that's packaged along with the renderer? The resulting image and the
algorithms used to generate it may be exactly the same.
> That way you could add all kinds of visual effects to the result
> which are not produced by rendering, such as many types of motion blur,
> glowing effects, etc etc.
Right. You could process the image in these ways with POV-Ray, as well.
Would the image be disqualified in that case?
> What you are getting is not what the renderer produces. The image made
> by the renderer might look like crap, but after you apply all kinds of
> special effects to the image it may look great. However, it's not a
> rendered image anymore.
Isn't it? At what point does it cease to be "rendered"? What is the
difference between a raytracer applying a contrast filter pixel by pixel
as the image is traced, and doing the same operation in an external
program?
The IRTC is the Internet Ray Tracing Competition, not the Internet Ray
Tracer Competition. I'd say it is the skill of the artist at producing
images with raytracing which matters. A contrast adjustment on a blank
image won't do anything, the artist has to make an image worth viewing
first.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > At least I would disallow using an external image manipulation program
> > which is unrelated and separate from the renderer.
> What's the difference between doing some operation using an external
> program that's unrelated to the renderer and using an external program
> that's packaged along with the renderer? The resulting image and the
> algorithms used to generate it may be exactly the same.
The difference is whether the image was produced by the renderer
called XYZ or not. It shows "the renderer XYZ can produce images
like this".
If you post-process the result of the rendering with an external
program (ie. *you* use the external program, not the renderer) the
result will be something the renderer is not able to produce.
And besides, if you want to allow any post-processing with any
unrelated image manipulation program, why do you want to restrict
it to only things that can be made "automatically" by the program
and not things the user can draw by hand? Why this kind of artificial
limitation? And where do you draw the line between something made
"automatically" by the program and something made "by hand" by the
user?
> > That way you could add all kinds of visual effects to the result
> > which are not produced by rendering, such as many types of motion blur,
> > glowing effects, etc etc.
> Right. You could process the image in these ways with POV-Ray, as well.
> Would the image be disqualified in that case?
It's something you get directly from the renderer. Why it should be
forbidden? It's not using photoshop or gimp to achieve something the
program cannot produce.
That's the difference: Can this renderer *directly* produce this
image, or do you need a third-party program for that?
> > What you are getting is not what the renderer produces. The image made
> > by the renderer might look like crap, but after you apply all kinds of
> > special effects to the image it may look great. However, it's not a
> > rendered image anymore.
> Isn't it?
Nope. Just part of the image information is what the renderer produced.
If you render a small logo and then use it in a hand-drawn image,
can you call the image, the whole image, "rendered"? No, only part
of the image has been rendered.
> At what point does it cease to be "rendered"?
At the point when the result of the rendering is modified.
How much modifications, in your opinion, can be made to a rendered
image so that it can still be considered "rendered"?
If you, for example, shuffle the location of all the pixels randomly,
is it still a "rendered" image? The result is just random noise. It may
be pseudo-random because it's based on existing data (the rendered
image), but it's still just noise, not a rendered image.
> What is the
> difference between a raytracer applying a contrast filter pixel by pixel
> as the image is traced, and doing the same operation in an external
> program?
The difference is whether it's the renderer which is able to produce
the resulting image or not.
> The IRTC is the Internet Ray Tracing Competition, not the Internet Ray
> Tracer Competition. I'd say it is the skill of the artist at producing
> images with raytracing which matters. A contrast adjustment on a blank
> image won't do anything, the artist has to make an image worth viewing
> first.
But considerably increasing the visual quality of an image by using
an image manipulation program is, in my opinion, against the spirit
of the competition.
Even a bad image can be greatly enhanced with all kinds of effects
supported by photoshop. Are we competing on who can use photoshop's
filters best?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That is, it's just a competition on who makes the
> prettiest image about a given subject. There's no real challenge
> which would make it markedly different from the IRTC.
First, it goes without saying that not everyone will be interested
in every competition....for example, I rarely enter the IRTC.
However in defence of this particular contest, there can indeed
be a significant challenge in representing many fractal forms. The
challenge normally comes in the form of the memory required for
the geometric data needed to represent fractals that in their
"pure" mathematical form have infinite detail.
For example, consider some of the clever methods that were discussed
a few weeks ago in this group on how to render the attractor I
entered into the SCC3
http://astronomy.swin.edu.au/~pbourke/fractals/peterdejong/
I certainly found it difficult to create the sphere positins for
the Apollonian fractal
http://astronomy.swin.edu.au/~pbourke/fractals/apollony/
The last images on that page have over 3 million spheres.
I would suggest that another challenge in this competition will
be to find something new. Everyone has seen quaternions and they
can certainly be made sexy, perhaps though a "new" fractal will
catch peoples eye more. (?). ps: I don't mean to discourage those
who are working on sexy quaternions.
--
Paul Bourke
pdb_NOSPAMswin.edu.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406ee7ca@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> The difference is whether the image was produced by the renderer
> called XYZ or not. It shows "the renderer XYZ can produce images
> like this".
I don't care if it's done by working the math out with paper and pencil.
> If you post-process the result of the rendering with an external
> program (ie. *you* use the external program, not the renderer) the
> result will be something the renderer is not able to produce.
And so? The algorithms that generate the image can be equivalent to
those used to generate the image with a single program. What's the
difference? Again, this is not a competition between rendering packages.
> And besides, if you want to allow any post-processing with any
> unrelated image manipulation program, why do you want to restrict
> it to only things that can be made "automatically" by the program
> and not things the user can draw by hand? Why this kind of artificial
> limitation? And where do you draw the line between something made
> "automatically" by the program and something made "by hand" by the
> user?
Because a procedure done by hand can not be reproduced. An algorithmic
procedure can be.
> It's something you get directly from the renderer. Why it should be
> forbidden? It's not using photoshop or gimp to achieve something the
> program cannot produce.
>
> That's the difference: Can this renderer *directly* produce this
> image, or do you need a third-party program for that?
It's the same process. What does it matter how it was produced?
I will not accept that a gaussian blur is "rendering" if it is done by
the program that generated the original image, but not if it is done by
a separate program. The result is the same. It looks the same, and was
generated the same way.
> If you render a small logo and then use it in a hand-drawn image,
> can you call the image, the whole image, "rendered"? No, only part
> of the image has been rendered.
Of course. Most of the image would be hand drawn. I've said several
times that hand modification should not be allowed, do you think I'd
accept a hand drawing?
> At the point when the result of the rendering is modified.
What's the result of the rendering? The color seen along each ray? The
gamma correction done by POV-Ray modifies that...no image using gamma
correction is a legal IRTC image?
> How much modifications, in your opinion, can be made to a rendered
> image so that it can still be considered "rendered"?
I already answered that. Drawing, painting, and other "by hand"
manipulation is out. Anything accepted as part of the rendering package
should also be accepted if done by a program outside the rendering
package. If a MegaPOV post-process convolution blur is acceptable, than
any other convolution blur should be acceptable.
Otherwise, limit entries based on the actual algorithms used. Color
adjustment should be allowed: gamma correction, contrast, etc. Resizing.
A small overlay for a signature, which should not affect the overall
image. Judging this would require in-depth knowledge of how the software
that generated the image works.
> If you, for example, shuffle the location of all the pixels randomly,
> is it still a "rendered" image? The result is just random noise. It may
> be pseudo-random because it's based on existing data (the rendered
> image), but it's still just noise, not a rendered image.
I can do the exact same thing with just POV-Ray. Does that magically
make it "rendered"?
To answer your question, yes, I'd still call it a rendered image. It
just wouldn't be an image of anything, and would be off-topic for pretty
much any IRTC competition.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You are speaking of a competition quite different from IRTC.
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Again, this is not a competition between rendering packages.
From the rules:
"Any rendering program is acceptable."
"Images must not be enhanced or altered ('post-processed') by use of
paint programs such as PhotoShop(tm) etc."
"Examples of unacceptable post-processing would be adding lens-glare,
tinting skies, or using filters such as motion blur."
If this is not a competition between rendering packages, then what is?
> I've said several
> times that hand modification should not be allowed, do you think I'd
> accept a hand drawing?
[...]
> Otherwise, limit entries based on the actual algorithms used.
"Paint programs may be used for the creation of image maps and the like,
but may not be used to alter the rendered image."
Your principle would mean that you can't use a painting program to
make textures by hand.
What you are saying is that you must make the image completely
algorithmically and that hand-drawing is not acceptable. This is
not the IRTC. This is something different.
--
#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:
> Harold <bai### [at] 3dculturecom> wrote:
>
>>Then don't participate.
>
> I might not, because I'm not artistically very talented, and I really
> lack any good ideas for this topic.
Funny: I'm the same way, yet I'm thrilled this is here because us
techies can come out to play :-)
--
Respectfully,
Dan P
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
<snip />
> If they allow post-processing then it's not a rendering competition
> anymore. It's a computer graphics competition.
> I don't think that was the original goal of the IRTC.
I agree with this -- allowing too much post-processing will diminish the
desire to be more clever with ray-tracers.
--
Respectfully,
Dan P
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
<snip />
> "Paint programs may be used for the creation of image maps and the like,
> but may not be used to alter the rendered image."
>
> Your principle would mean that you can't use a painting program to
> make textures by hand.
> What you are saying is that you must make the image completely
> algorithmically and that hand-drawing is not acceptable. This is
> not the IRTC. This is something different.
Right-on -- by it's very name it is a Ray-Tracing competition. For
example, if a person can correct colors in Photoshop, it means that they
are not competent enough to do it in the ray-tracer. If they have to
rescale to get good anti-aliasing, it also means they don't know how to
get good results from the ray-tracer. It isn't a Photoshop/GIMP/Whatever
competition. Take it from a guy who /isn't/ competent enough to enter
the IRTC yet, but wants to -- don't lower the bar on me! :-)
--
Respectfully,
Dan P
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40706087@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> "Any rendering program is acceptable."
Interesting...I did not realize they allowed non-raytracers.
> "Images must not be enhanced or altered ('post-processed') by use of
> paint programs such as PhotoShop(tm) etc."
>
> "Examples of unacceptable post-processing would be adding lens-glare,
> tinting skies, or using filters such as motion blur."
Examples of the current rules, the ones which we are discussing changes
to. I would find tinting the sky acceptable. Lens flare...perhaps. It
obviously can't be prevented if it is done within the scene as textured
discs or actual camera optics. I'd say 2D lens flares are OK as long as
it's not hand-positioned.
Motion blur (and other types of blur): this really can be used to
simulate real blur effects caused by scattering in the retina or sensor.
I'd consider it borderline. If any effect is allowed with one package,
it should be allowed with all others.
> If this is not a competition between rendering packages, then what is?
A competition between artists with tight constraints on how the images
are to be produced. It wouldn't matter one bit to the competition if
everyone used the same package, because the entries are images, not
packages. Packages aren't scored, the actual works are. You win by
having a superior image, not by using superior software.
> Your principle would mean that you can't use a painting program to
> make textures by hand.
No it wouldn't. Such an image would be a source file, not a modification
to the generated image. Of course, someone could put an image_map on a
plane and point the camera at it...I'd rely on human judgment to have
such entries thrown out.
> What you are saying is that you must make the image completely
> algorithmically and that hand-drawing is not acceptable. This is
> not the IRTC. This is something different.
No, that's not what I'm saying. I'm saying that it is the algorithms
used to generate the image that matter, not the software packages. The
final image should be renderable from all source files without human
editing. (Again, with the exception of signatures/watermarks. Anything
goes for those, as long as they're unobtrusive.)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> > "Any rendering program is acceptable."
> Interesting...I did not realize they allowed non-raytracers.
Where have you been living?-) There have been many scanline-rendered winner
images, plus tons of scanline-rendered entries.
> Examples of the current rules, the ones which we are discussing changes
> to. I would find tinting the sky acceptable. Lens flare...perhaps. It
> obviously can't be prevented if it is done within the scene as textured
> discs or actual camera optics. I'd say 2D lens flares are OK as long as
> it's not hand-positioned.
If the irtc becomes a generic computer graphics competition, it
would certainly degrade its interest to the borders of boredom.
It would only enhance the advantage of those people using expensive
several-thousands-of-dollars costing image manipulation programs
(or those using it pirated) which have tons of filters.
Boring. I want to see renderers in action, not photoshop filters.
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|
