"Fabien Mosen" <fab### [at] skynetbe> wrote...
> Nathan Kopp wrote:
> >
> > ...which is a big reason why I think POV needs post-processing built in.
> > Actually, I think that POV should have post-processing utilities as part
of
> > the distribution, specifically designed to work with POV, though not
part of
> > the primary EXE.  Of course, in that case the IRTC rules would have to
be be
> > changed.
> >
> > I don't know how to change the IRTC rules, but they currently seem to
favor
> > other rendering engines over POV (I'm talking about the official POV
here,
> > not MegaPov), and to me that seems a bit "backwards".
>
> To me, the true spirit of that rule is that every effect should be
> 3D-related.  Applying gaussian blur all over, or manually, is not
> 3D-related.  But if the blur, even post-processed, uses 3D information
> to know where and how it applies, it's fine.

The exact rule is: "Images must not be enhanced or altered
('post-processed') by use of paint programs such as PhotoShop(tm) etc"

What I'm wondering about is this:
Instead of having post-processing built into the core of POV, it is provided
(with the package distribution) as a separate tool.  The core POV-Ray would
output a data file containing the 3d data, along with the image file.  The
post-processing tool would then be used to read in the original image and
the 3d data and produce a new image file.

This post processing tool _could_ be considered to be part of the rendering
tool, since it is part of the package.  It definately could not be
considered to be a "paint program such as PhotoShop(tm)".  So, would such an
implementation be acceptable under the current rule?

-Nathan Kopp

Post a reply to this message