[Pbrt-discuss] [pbrt 0000007]: depth of field lens position calculation wrong?

[Martin Kraus]

--- On Tue, 6/30/09, Matt Pharr <matt.pharr at gmail.com> wrote:


> Hmm, it's interesting how confusing

> this can be.  (No thanks to the  

> botched initial explanation in the book!)

> 

> I think the issue is that there are a number of equally

> valid solutions.

> 

> For starters, we are all in agreement at least that the ray

> should go  

> through the point Pfocus, as it's currently computed, and

> we agree  

> that the lens is in the z=0 plane.  (I think!)


I agree. :)
 

> For the non-dof case (or the case with lens radius == 0),

> then the  

> regular ray goes through the point (0,0,0) (in camera

> space).  This is  

> made slightly unclear by the clipping plane stuff, since we

> actually  

> start the ray on the hither plane in that case.  But

> if you extend it  

> backwards, it should go through (0,0,0), and if you keep

> going back to  

> z=-clipHither, then it should end up with the x and y

> components  

> negated versus their values at z=clipHither.

> 

> Now, if we sample a point on the lens, that point is at

> (lensU, lensV,  

> 0).  We know the ray goes through this point, and we

> also know that it  

> goes through the point Pfocus.  I think that the

> simplest correct  

> solution is to set the ray origin as the point in the lens

> (x and y to  

> lensU and lensV, respectively, and z to zero), and the

> direction to  

> the vector from the origin to Pfocus.


Thanks for this explanation! 
I agree, it's possible to set the starting point 
onto the lens and having the ray pointing to Pfocus.
However, I'm not sure that this is the "simplest" solution.
(Prior to your explanation I never understood why this 
should be correct. :)


> I believe that your solutions will also compute valid

> origins for the  

> ray, but just on the hither plane instead of the z=0

> plane.  But which  

> origin is chosen doesn't matter if the ray's mint value is

> set so that  

> it actually starts on the hither plane.


This change would have to be added, right?
 

> What do you think?

> 

> Thanks,

> -matt


I would prefer my method in order to generate consistent
t values for the case with and without a lens.
Generating the correct depth values is difficult enough 
(for example: for comparisons with raster images you 
don't need t but the z coordinate of the intersection point).
If you change mint and maxt between a pinhole image
and an image with depth of field, it just gets even
more complicated. 

Alternatively, one could have consistent t values if
the starting point is either on the lens or at 
(0,0,0) if there is no lens.
That would probably be the best (simplest) solution.

Cheers 

Martin



> On Jun 30, 2009, at 2:12 AM, Martin Kraus wrote:

> 

> >

> > 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

> >>

> >> = 

> >>

> =====================================================================

> >>

> >>

> >

> >

> >

> >

> >

> > _______________________________________________

> > pbrt-discuss mailing list

> > pbrt-discuss at pbrt.org

> > http://six.pairlist.net/mailman/listinfo/pbrt-discuss

> 

>