[Bf-committers] Sensor Size

Ejner Fergo ejnersan at gmail.com
Tue May 31 06:14:32 CEST 2011


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

As you can see I don't understand anything. I can't see how this will
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
length as pixels is useful for your work, but can't see the relation
to what this sensor patch is trying to accomplish.

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
>


More information about the Bf-committers mailing list