[Bf-committers] Sensor Size

[Lars Krueger]

> Hi,
> 
> I must admit I'm confused. Doesn't help that math is not my friend...
> so please forgive my questions.
> 
> Sensor size for display purposes only?
> Focal length in meter? So in your example a 50mm focal length is f =
> 0.050? And this should be stored as pixels?

Could be in any unit as long as you know (and store/display it). Most important point here is that focal length, sensor size, and point coordinates are in the same unit.

> The horizontal dimension of image sensor would in your example with
> 22.3mm be dx = 0.0223?
> Number of pixels is then the x resolution, so lets say nx = 1920.
> sx = 0.0223 / 1920

Sorry, got that wrong in the last mail. 

sx is actually the pixel density. Unit of sx should be e.g. pixel/mm, hence sx = nx/dx

For your example:

sx=1920/22.3 ~ 86.1 pix/mm
f = 50 mm

Fx = f * sx = f * nx / dx ~ 4304 pix
Units are:  mm * pix / mm -> pix

> Fx = 0.050 * 0.000011615
> I then choose an object/point that I know is say 5 meters from the
> left border of an image? X = 5
> And that object/point I know is 6 meters away from the camera. Z = 6
> With this I get a horizontal position in pixels that is u =
> 0.000000484? What is this value and how is it used?

In this case, it would only matter that X and Z are of the same unit as f and sx. In the example above: X=5000, Z=6000

u = 3586.6 pixel 

Actually, you would have to add the coordinate of the principal point, which is usually in the centre of the image. Hence your point would be
at

u' = 3586+1920/2= 4546 pixel

> As you can see I don't understand anything. I can't see how this will

Sorry and thanks for pointing out my mistake.

> make it easy to get the correct field of view from a known focal
> length and image sensor size. How will you translate a vertical fov to
> a focal length with your method? I do not doubt that having the focal

Converting to fov (alpha_x is horiz. fov) is:

alpha_x = 2 * atan ( dx/(2*f))
alpha_y = 2 * atan ( dy/(2*f))

alpha_x = 0.43882000030571228 rad = 25.143275522848388 degree

Your example point would have an angle of 

atan (5000/6000) = 0.69473827619670325 rad = 39.8 deg 

to the right. That would mean it's far outside the fov (which extends 25.1/2 = 12.5 deg to the right). The coordinate u' is far bigger than 1920, so my calculation seems correct this time ;-)

Any 3d computer vision book/lecture usually starts with this, e.g.
http://www-inst.eecs.berkeley.edu/~ee225b/sp07/lectures/lec12.pdf
Google for "pinhole camera model" and "computer vision" for further reference.

> length as pixels is useful for your work, but can't see the relation
> to what this sensor patch is trying to accomplish.

Just for clarification, I'm not involved in the patch. I'm just providing a different point of view that might be interesting for the authors of the patch or the community. I found it quite easy to work with the focal length in pixel (which is usually called "camera constant") as it denotes everything the projection needs to know about the scaling and easy to convert from/to fov, focal length, etc.

> 
> Best regards,
> 
> Ejner
> 
> 
> On Mon, May 30, 2011 at 10:10 PM, Lars Krueger <lars_e_krueger at gmx.de>
> wrote:
> > How about storing the focal length using pixels as the unit of
> measurement? This way a lot of code gets a lot simpler. The sensor size is then used
> for display purposes only.
> >
> > Assuming
> > f - focal length (in e.g. meter)
> > dx - horizontal dimension of image sensor (same unit as f)
> > nx - number of pixels
> > sx - pixel size in same unit as f ( = dx / nx)
> > Fx - horizontal camera constant ( = f * sx)
> > X - horizontal position of a point in meter
> > Z - distance of point in meter
> > u - horizontal position in pixel
> >
> > you go from
> >
> > u = f*(dx/nx)*X/Z
> >
> > to
> >
> > u = Fx*X/Z
> >
> > Computing the Fx can be done in the UI, while all code needs only one
> variable during the projection.
> >
> > That's a quite common convention in computer vision. It comes from the
> fact that focal length and pixel size have to be multiplied to get the final
> scaling from meters to pixels during projects, but only pixel coordinates
> can be measured during calibration. Hence, pixel size remains unknown as
> only the total scale from meter (calibration object size) to pixels (image
> coordinates).
> >
> > We use this convention in all our 3D computer vision products and
> applications for about five years and never had problems. Just enter the correct
> scale for the calibration object and you're done.
> >
> > -------- Original-Nachricht --------
> >> Datum: Mon, 30 May 2011 17:48:05 +0200
> >> Von: Ejner Fergo <ejnersan at gmail.com>
> >> An: bf-blender developers <bf-committers at blender.org>
> >> Betreff: Re: [Bf-committers] Sensor Size
> >
> >> Hola,
> >>
> >> I have updated the patch to revision 37009:
> >>
> http://projects.blender.org/tracker/index.php?func=detail&aid=24427&group_id=9&atid=127
> >>
> >> I have also written a short documentation:
> >> http://wiki.blender.org/index.php/User:San/Real_Focal_Length
> >>
> >> About code review, I think I read that only committers can upload to
> >> the code review tool? The patch is assigned to Sergey Sharybin
> >> (nazgul) so hopefully he reads this and have the time to do it. I'm
> >> aware that GSOC is in full swing, but still think this patch will be
> >> good to have in 2.58.
> >>
> >> I am prepared to work more on importers/exporters and have so far made
> >> good progress on FBX and .chan and will do my best to make every
> >> script having to do with cameras work with this new code.
> >>
> >> Best regards,
> >>
> >> Ejner
> >>
> >> On Wed, Apr 27, 2011 at 9:08 AM, "Martin Bürbaum"
> >> <martin.buerbaum at gmx.at> wrote:
> >> > Ejner Fergo <ejnersan at gmail.com> wrote:
> >> >> I am of course hopeful to see this get some attention from the
> >> >> developers, and appreciate you guys seeing the importance of this. I
> >> >> just don't know how to proceed with this to make an inclusion in
> trunk
> >> >> more likely. It would be really nice to hear some opinions from
> those
> >> >> with authority.
> >> >
> >> > I am not a blender developer (sorry, no authority here), but I think
> a
> >> good start would be to upload the latest patch to the code review tool
> [1].
> >> > And link that in the bug tracker. (<? I don't know about the exact
> >> procedures here.)
> >> >
> >> > Then it's pretty easy to review and comment on the patch, which in
> turn
> >> will speed up its integration into trunk, I presume.
> >> >
> >> > Saludos,
> >> > Martin
> >> >
> >> > [1] http://codereview.appspot.com
> >> > Example Review: http://codereview.appspot.com/4280080
> >> > Mailing List: http://lists.blender.org/pipermail/bf-codereview/
> >> > _______________________________________________
> >> > Bf-committers mailing list
> >> > Bf-committers at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > --
> > Dr. Lars Krueger
> >
> >
> > NEU: FreePhone - kostenlos mobil telefonieren!
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

-- 
Dr. Lars Krueger


Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de