[Pbrt-discuss] [pbrt 0000007]: depth of field lens position calculation wrong?
Martin Kraus
martin_kraus_germany at yahoo.com
Tue Jun 30 05:12:03 EDT 2009
Hi there!
I'm posting this to pbrt-discuss at pbrt.org (and authors at pbrt.org)
since I seem to be unable to add a note to a bug with status
"resolved". :)
> (Specifically, I think that Martin leaving the += in was a
> typo?)
No, this is not a typo, both "+=" are necessary since
ray->o contains the sampling position on the hither plane
and this sampling position is moved by some offset due to
the (additional!) stochastic sampling of the lens.
(I would assume that you don't get reasonable images when
you change the "+=" to "=".)
One more comment: reading my explanation again I realized
that I made a mistake:
> We know that Pfocus.z = FocalDistance - ClipHither
Actually, this should read: "Pfocus.z = FocalDistance"
Sorry about that, (I guess I got confused because the
sampling position is at z = ClipHither).
Cheers
Martin
________________________________________________________________________
Dr. Martin Kraus, TU Muenchen, Informatik 15
Boltzmannstrasse 3, 85748 Garching, Germany
Room: 02.13.055. E-mail: krausma at in.tum.de
Phone: +49 (0)89 289 19482. Fax: ... 19462
--- On Tue, 6/30/09, Mantis Bug Tracker <authors at pbrt.org> wrote:
> From: Mantis Bug Tracker <authors at pbrt.org>
> Subject: [pbrt 0000007]: depth of field lens position calculation wrong?
> To: martin_kraus_germany at yahoo.com
> Date: Tuesday, June 30, 2009, 1:59 AM
>
> The following issue has been RESOLVED.
> ======================================================================
>
> http://pbrt.org/bugtracker/view.php?id=7
>
> ======================================================================
>
> Reported By:
> mmp
> Assigned To:
> mmp
> ======================================================================
>
> Project:
> pbrt
> Issue ID:
> 7
> Category:
>
> Reproducibility:
> always
> Severity:
> feature
> Priority:
> normal
> Status:
> resolved
> Resolution:
> fixed
> Fixed in Version:
>
> ======================================================================
>
> Date Submitted:
> 2004-06-28 20:46 EDT
> Last Modified:
> 2009-06-29 19:59 EDT
> ======================================================================
>
> Summary:
> depth of field lens position
> calculation wrong?
> Description:
> (Ren Ng)
>
> Shouldn't the correction for depth of field
> (perspective.cpp) be
>
>
> ray->o.x = lensU;
>
> ray->o.y = lensV;
>
> ray->d = Pfocus - ray->o;
>
> rather than
>
>
> ray->o.x += lensU;
>
> ray->o.y += lensV;
>
> ray->d = Pfocus - ray->o;
> ?
>
> Seems like you just want to restart the ray on a random
> position on the
> lens, not offset it, or am I not understanding something?
>
>
>
>
> (I think he's right, but think that we do effectively gives
> the same
> result. i.e. our end result is still correct, just
> doesn't match the way
> the book explains it.)
> ======================================================================
>
>
> ----------------------------------------------------------------------
>
> (0000002) humper (administrator) - 2004-06-28 21:05
> http://pbrt.org/bugtracker/view.php?id=7#c2
> ----------------------------------------------------------------------
>
> Hmm, it seems like our code assumes that the lens is
> basically centered
> around the image sample point in camera space. This
> might cause DOF errors
> near the edges of the film (and might also affect
> vignetting effects).
>
> ----------------------------------------------------------------------
>
> (0000079) Martin Kraus (reporter) - 2006-12-06 18:00
> http://pbrt.org/bugtracker/view.php?id=7#c79
> ----------------------------------------------------------------------
>
> Hello!
>
> I'm very new to pbrt (I have never used it, just read a few
> chapters of
> the book); thus, I might get a lot of things wrong.
> Anyways, I wanted to
> report a bug in the very same lens position calculation,
> but i think the
> correct solution is a little more complicated. Even worse,
> the explanation
> in the book is incorrect because the updated ray origin is
> not on the lens
> but still on the near clipping plane. However, this
> is a rather small
> detail since the updated ray origin is at the correct
> intersection point of
> the near clipping plane with a line from the sample point
> on the lens and
> the point on the plane of focus, if the computation on page
> 272 is adjusted
> this way:
>
> <Update ray for effect of lens> ==
> ray->o.x += lensU * (FocalDistance -
> ClipHither) / FocalDistance;
> ray->o.y += lensV * (FocalDistance -
> ClipHither) / FocalDistance;
> ray->d = Pfocus - ray->o;
>
> Here is my reasoning: In the model of a pinhole camera I
> imagine the image
> plane to be at z = -ClipHither, i.e. behind the origin
> (0,0,0) (the image
> plane is symmetric to the near clipping plane at z =
> +ClipHither). The
> center of the lens is actually at the origin and its plane
> is parallel to
> the image plane (and the near clipping plane). Now, the
> unperturbed ray is
> actually going through the center of the lens (because it
> goes through the
> pinhole, i.e., the origin); therefore, the computation of
> Pfocus is
> correct. The point on the lens, however, is at (lensU,
> lensV, 0) and we
> should find the intersection of the line from this point
> (lensU, lensV, 0)
> to Pfocus at z = ray->o.z = ClipHither (i.e. on the near
> clipping plane).
>
> We know that Pfocus.z = FocalDistance - ClipHither (by
> definition, since
> it is on the focal plane); moreover, the intersection of
> the line from the
> origin (0,0,0) to Pfocus is at the unperturbed ray origin
> (ray->o). Think
> of this line with fixed point Pfocus and move the starting
> point from the
> origin (0,0,0) to the sample point on the lens at
> (lensU,lensV,0). How does
> the intersection point at z=+ClipHither move? Well, by
> (lensU,lensV,0) *
> (FocalDistance - ClipHither) / FocalDistance! Thus, we have
> to translate
> ray->o by this translation to get to the updated
> intersection point on the
> near clipping plane.
>
> Why does the original code (without the scaling by
> (FocalDistance -
> ClipHither) / FocalDistance) give reasonable results?
> Because it is a very
> reasonable approximation to set the missing factor to 1
> since ClipHither
> will usually be much smaller than FocalDistance.
> However(!), for very
> blurred objects very near to the near clipping plane there
> will probably be
> notable differences.
>
> Well, that's what I think about this. I would appreciate
> any comments!
>
> BTW: great book! :)
>
> Martin Kraus
>
> ----------------------------------------------------------------------
>
> (0000085) Martin Kraus (reporter) - 2007-01-24 13:14
> http://pbrt.org/bugtracker/view.php?id=7#c85
> ----------------------------------------------------------------------
>
> One more note: I realized that (FocalDistance - ClipHither)
> / FocalDistance
> is a constant factor for the whole scene, thus, the bug can
> be compensated
> by a scaling of the lens radius. For actual values, e.g.
> the dragons scene
> with extreme blurring as in Figure 6.9 with a lensradius of
> 0.05,
> focaldistance of 0.75 and default hither of 0.001, the
> missing factor is
> (0.75-0.001)/0.75=0.998666...; i.e., you can get the
> "correct" image with
> the incorrect code by setting the lensradius to
> 0.0499333... instead of
> 0.05. Of course, the difference is hardly noticable.
>
> Martin Kraus
>
> ----------------------------------------------------------------------
>
> (0000120) mljackpbrt (reporter) - 2008-03-24 11:42
> http://pbrt.org/bugtracker/view.php?id=7#c120
> ----------------------------------------------------------------------
>
> I agree with Martin Kraus's proposal. The Luxrender will
> fix it according
> to his notes.
>
> ----------------------------------------------------------------------
>
> (0000130) mmp (administrator) - 2009-06-29 19:59
> http://pbrt.org/bugtracker/view.php?id=7#c130
> ----------------------------------------------------------------------
>
> Fixed (finally) in the upcoming 1.04 release as well as
> pbrt 2.0. I
> believe that the correct implementation combines Martin and
> Ren's:
>
> ray->o.x = lensU * (FocalDistance - ClipHither) /
> FocalDistance;
> // etc
>
> (Specifically, I think that Martin leaving the += in was a
> typo?)
>
> Issue History
> Date Modified Username
> Field
> Change
>
> ======================================================================
>
> 2004-06-28 20:46 mmp
> New Issue
>
>
> 2004-06-28 21:05 humper
> Note Added: 0000002
>
>
> 2006-12-06 18:00 Martin Kraus Note Added:
> 0000079
>
> 2006-12-06 18:01 Martin Kraus Issue
> Monitored: Martin Kraus
>
>
> 2006-12-06 18:01 Martin Kraus Issue End
> Monitor: Martin Kraus
>
>
> 2006-12-06 18:01 Martin Kraus Issue
> Monitored: Martin Kraus
>
>
> 2007-01-24 13:14 Martin Kraus Note Added:
> 0000085
>
> 2008-03-24 11:42 mljackpbrt Note
> Added: 0000120
>
> 2008-03-24 11:42 mljackpbrt Issue
> Monitored: mljackpbrt
>
> 2009-06-29 19:59 mmp
> Note Added: 0000130
>
> 2009-06-29 19:59 mmp
> Status
> new => resolved
>
> 2009-06-29 19:59 mmp
> Resolution
> open => fixed
>
> 2009-06-29 19:59 mmp
> Assigned To
> => mmp
>
> ======================================================================
>
>
More information about the pbrt-discuss
mailing list