[Bf-committers] Sensor Size

Tue May 31 23:40:56 CEST 2011

Hi Lars,

I was really lost when I read your first mail, but now it seems a
little more clear. Thank you for bearing with me and explaining :)

When I first started to read about calculations of focal length,
sensor and fov, and looking at how other DCC software/exporters do it,
everything I found was the "classic" calculations with no pixels
involved, so I thought that was the only way to do it (disclaimer: I
didn't write the patch, that honor belongs to Matt Ebb. I only exposed
the vertical fov since I needed it for importers/exporters). It is
really interesting to see another approach now that I _think_ I
understand it!

I just have a question:
With this "computer vision" method, doesn't it require more data? You
still need to know the sensor size besides the focal length and image
resolution, but then you also need to know the distance to a point.
Not that I mind measuring for location data, but I don't fully
understand X and Z yet. My first thought is that the fov changes a lot
depending on where you select the point?

In any case I will read your mail again a couple of times, read the
pdf, google and do some tests.

Thanks again for your input!

Best regards,

Ejner

On Tue, May 31, 2011 at 10:46 PM, Lars Krueger <lars_e_krueger at gmx.de> wrote:
>> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>