From martin_kraus_germany at yahoo.com  Tue Jun 30 05:12:03 2009
From: martin_kraus_germany at yahoo.com (Martin Kraus)
Date: Tue, 30 Jun 2009 02:12:03 -0700 (PDT)
Subject: [Pbrt-discuss] [pbrt 0000007]: depth of field lens position
	calculation wrong?
Message-ID: <717584.19704.qm@web38406.mail.mud.yahoo.com>


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




      

From martin_kraus_germany at yahoo.com  Tue Jun 30 14:14:31 2009
From: martin_kraus_germany at yahoo.com (Martin Kraus)
Date: Tue, 30 Jun 2009 11:14:31 -0700 (PDT)
Subject: [Pbrt-discuss] [pbrt 0000007]: depth of field lens position
	calculation wrong?
Message-ID: <944650.23426.qm@web38408.mail.mud.yahoo.com>




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