Christoph Hormann <chr### [at] gmxde> wrote:
> dkleckner wrote:
> > I noticed recently that focal blur has difficulty dealing with thin objects
> > which are out of focus, producing artifacts regardless of the number of
> > blur_samples and confidence/variance values.  To see a simple example of
> > this, render the following code:
>
> The current focal blur code has special handling for low number of
> samples (up to 37).  It could well be that the distribution of the
> additional samples and/or the jittering of the samples is suboptimal.
>
> >
> > Even worse, turning the number of blur samples down can actually make it
> > look better.  The artifact seems to realize it self exactly at blur_samples
> > 19 (try 18 and 19, and compare!).  I had a look at the source code, at it
> > seems to happen because of some strange hexagon-shaped grid which is used
> > to decide on the points from which to shoot rays to calculate the focal
> > blur.  (There is also a comment in there indicating "this should probably
> > be changed!")
>
> The comment is actually misleading - the hexagonal grid is used in all
> cases.
>
> > It seems to me that it would be _very_ easy to rewrite this code, using a
> > monte-carlo (i.e. random) approach to determine where in the aperature to
> > send rays from.
>
> No, the claim that it would be very easy to redesign the focal blur is
> quite baseless (actually it may be not but the claim to redesign it to a
> reliable and efficient solution is).
>
> There has already been a patch made to allow custom sample grids:
>
> http://pov.monde.free.fr/mael/mlpov083eng.html
>
> but note this is still based on the same concept as the original system.
>     And there has actually been only very limited interest in having
> this added to MegaPOV of official POV-Ray.
>
> >
> > I'd do all of this myself, as it wouldn't take long, but even figuring out
> > how to get the source code to compile seems like a major project.
>
> Building POV-Ray is not more difficult than downloading
>
>
http://www.povray.org/redirect/www.povray.org/ftp/pub/povray/Official/Linux/povlinux-3.6.tgz
>
> and calling configure && make.  And yes, this is also possible on
> Windows, provided that you have a POSIX emulation layer like Cygwin
> installed.
>
> You should feel invited to try improving the focal blur but i would
> suggest you don't assume this to be very easy and rush into it since
> this will most likely result in a patch hardly usable in production code.
>
> A final note: while it can be tempting to create a focal blur function
> that cross-uses samples among several pixels this would be pretty
> useless for multithreaded rendering in POV-Ray 3.7 (unless you add a
> thread-safe ray caching system which would be quite complicated).
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Landscape of the week:
> http://www.imagico.de/ (Last updated 20 Aug. 2006)
> MegaPOV with mechanics simulation: http://megapov.inetart.net/

Thanks for your quick feedback.

I'm quite disappointed in the lack of interest in fixing the focal blur in
the main release.  It seems pretty obvious to me that it produces unsightly
defects; arguably it is broken (e.g., the scene from my original post).  It
seems to me the original system was made to work well with a low number of
samples and with relatively little blurring, for which it is probably fine,
but it is clearly inadequate for more demanding applications.

I fail to see why it would be difficult to implement a monte-carlo based
approach or why it would be ineffecient or unreliable; all I am suggesting
is choosing points at random as opposed to from a grid.  It would certainly
have no problems with multi-threading, which you seem to imply.  Although it
may not seem on its face to be so, the monte carlo method is known generally
to be very efficient for a wide variety of applications, and almost
certainly better than a grid-base approach in this case (and by efficient I
mean the rate at which it approaches an ideal solution).

If there really isn't any interest in fixing this, perhaps it would at least
be possible to add a min_blur_samples command, which I assume _would_ be
quite simple; this would give the renderer a chance to detect thin objects
before the variance/confidence check assumes there isn't any thing there,
which is what's happening now.  At any rate I may decide to have a go at
fixing it properly myself, in which case I'll be sure to compare its
efficiency to the current system and report any results.

Post a reply to this message