 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
#include "colors.inc"
global_settings {assumed_gamma 1.0}
camera {
location 0
look_at z
focal_point z*5
aperture .5
blur_samples 200
confidence 0.9999
variance 1/100000
}
#declare i = 1;
#while(i < 30)
sphere{<i*i/30 - i/2, 0, i>, .01*i pigment {color White} finish {ambient
1}}
sphere{<i*i/30 - i/2, i/3, i>, .1 pigment {color White} finish {ambient 1}}
torus{.05 * i, .001 * i pigment {color White} finish {ambient 1} rotate x *
90 translate <i*i/30 - i/2, -i*(1/6+mod(i, 4)/15), i>}
#declare i = i + 2;
#end
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!")
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. This would also make it very easy to allow control of the
bokeh (shape of the defocus), which would make focal blur look like it does
in an actual photograph. The monte-carlo method should also converge more
rapidly on the ideal result than a grid-based method, allowing cleaner
looking focusses in less time even in situations where the defect doesn't
show up.
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. So are
any of the main POV programmers interested in giving it a shot? It seems
to me that this is a serious flaw in the POV renderer, and it would benefit
greatly from it being fixed in the main release. I'd be more than happy to
contribute advice and testing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dkleckner wrote:
>
> Thanks for your quick feedback.
>
> I'm quite disappointed in the lack of interest in fixing the focal blur in
> the main release.
>
> I fail to see why it would be difficult
>
> If there really isn't any interest in fixing this, perhaps it would at least
> be possible to
I am in no way a member of the team. I am just another POV-Ray user,
passing along some thoughts.
This is free software, developed by volunteers for over 15 years. All
the trivial fixes were completed long ago. The source code is available
to you if you need to make changes right away, or you can just wait for
the next release, and see if it does what you want it to do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dkleckner wrote:
>
> Thanks for your quick feedback.
>
> I'm quite disappointed in the lack of interest in fixing the focal blur in
> the main release.
Huh? Where did i say there is no interest in improvements of the focal
blur feature? The only place where i talked about limited interest was
the MLPov bokeh_pigment patch. And as described this patch only allows
to vary the grid pattern used, it does not change the technique itself.
> I fail to see why it would be difficult to implement a monte-carlo based
> approach or why it would be ineffecient or unreliable;
I said the claim implementing a new focal blur system would be 'very
easy' is lightheaded when you intend it to be reliable and efficient.
This is based on my experience in working on the POV-Ray source and my
knowledge of the complexity of the problem. It has nothing to do with
any particular approach you might take to this. And i would be happy to
be proven wrong with that although i feel this is - unlikely.
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/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
