stuffmatic / blam

🚨 No longer maintained. Check out fSpy instead 🚨 A camera and projector calibration toolkit for Blender that also does automatic 3D reconstruction of geometry with rectangular faces.
https://fspy.io/
GNU General Public License v3.0
644 stars 95 forks source link

Calibration generates bad focal length #4

Open porglezomp opened 11 years ago

porglezomp commented 11 years ago

Using OSX, blender 2.67b

I've tried 5 seperate calibrations, and none have had the axes correctly aligned. The camera angles appear to be perfect however, since I'm able to fix the focal length by hand.

stuffmatic commented 10 years ago

Sorry about the late reply. Could you share any of your test images?

offtools commented 10 years ago

Hi,

It could be, that the problem appears when working with an aspect of 4:3 instead of 16:9. We've tried the addon today with a projector (resolution 1024x768, aspect 4:3) and also got a wrong focal length. Later at home I tried to reproduce the failure without a video projector but with the lens data of the projector (Focal length, lens shift). I rendered a scene with the optical data of the projector, did the calibration work based on the rendering and tried to match the scene with the calibrated camera with the rendering as background image. I found out, that the problem may only appear when working with an aspect ratio that differs from 16:9 (4:3 in my case), with an aspect of 16:9 it seems to work. Will try this soon as possible with a projector again.

I added a small test, where I tried to match the calibrated camera with camera background image of the used scene. It shows the problem and a workaround when working with 4:3 aspect videoprojectors.

test-aspects

thegoodhen commented 6 years ago

I can confirm this. Using 4:3 images generates invalid estimates of focal length. I have tried setting the aspect ratio of the camera to the aspect ratio of my image manually before running BLAM, but it didn't help. I am getting relatively consistent (wrong) results for the image with 4:3 aspect ratio, while getting correct results for 16:9 images. So far this does NOT seem to be due to numerical instabilities.

thegoodhen commented 6 years ago

Okay, I have looked into it and I have found the issue (I think).

In the original file there is a TODO saying:

    #TODO: make sure this works for all combinations of
    #image dimensions and camera sensor settings

Well, I have done it and it doesn't. It appears that cam.data.sensor_height is set incorrectly, which may be a Blender bug (I am not sure about it). The ratio of cam.data.sensor_width to cam.data.sensor_width appears to be 16:9 (1.77777) no matter the image aspect ratio.

I have found the following workaround (which appears to work):

Find the block starting with if imageWidth >= imageHeight:

and replace the whole if-else block with:

    if imageWidth >= imageHeight:
        theAspectRatio=imageWidth/imageHeight
        theHeight=cam.data.sensor_width/theAspectRatio
        fMm=theHeight * f
        #fMm = cam.data.sensor_height * f
    else:
        fMm = cam.data.sensor_width * f

I would post a pull request, but it seems like the author is not active any more.

EDIT: I am not sure if one of the calibrated intrinsic parameters is a pixel aspect ratio. I do believe that in the original paper it is so. I cannot find it in the code anywhere. If this is the case, the code should be reviewed some more, as my workaround (probably?) assumes that the pixel aspect ratio is 1.

Bigbadcat612 commented 5 years ago

EDIT: I am not sure if one of the calibrated intrinsic parameters is a pixel aspect ratio. I do believe that in the original paper it is so. I cannot find it in the code anywhere. If this is the case, the code should be reviewed some more, as my workaround (probably?) assumes that the pixel aspect ratio is 1.

Hi! I used your code but I get a focal length of 900 mm in a square image. So it didn't work at all. Maybe that caused because I used x and z-axis to determine the focal length? Sorry for bad English.

Here's the image: perfopanel_khdf_dedalo_gloriya

thegoodhen commented 5 years ago

EDIT: I am not sure if one of the calibrated intrinsic parameters is a pixel aspect ratio. I do believe that in the original paper it is so. I cannot find it in the code anywhere. If this is the case, the code should be reviewed some more, as my workaround (probably?) assumes that the pixel aspect ratio is 1.

Hi! I used your code but I get a focal length of 900 mm in a square image. So it didn't work at all. Maybe that caused because I used x and z-axis to determine the focal length? Sorry for bad English.

Here's the image: perfopanel_khdf_dedalo_gloriya

I'm unable to reproduce the described bug with my version of code (with changes I described above). With your image, it works fine for me, following the tutorial on: https://www.youtube.com/watch?v=yeWzQYh7iH0

On Blender 2.49b 64 bit. I have however first (before following the tutorial) set the background image to your image and selected "fit" under background image options (stretch/fit/crop). Not sure if that makes any difference and I don't really have the time to double check. I will upload the solved .blend file for your convenience.

EDIT: Well, this is odd... I have now looked into it a bit more and the solution is unexpected to say the least. It fits, but the focal length is very low and the object itself is very long. But doesn't that imply the problem is underconstrained? It is confusing to me.

EDIT2: HMMMMMMMMMMMMMMM... wait.

I think that this is actually an unrelated problem. The plugin works by computing vanishing points and with almost-parallel lines, the position of the vanising point (i.e. their intersection) is highly numerically unstable. There is one alternative approach (that I've read a paper on), which uses assumptions about orthogonality as opposed to vanishing points and which yields a better numerical stability, but I don't think that's implemented in BLAM.

thegoodhen commented 5 years ago

The .blend file: https://drive.google.com/file/d/1URezwZXfG-Bt2yUT7RSLXtmqVPw7-_JY/view?usp=sharing

My (edited) blam.py:

https://drive.google.com/file/d/1GPdXrPzSqt_CFsmowqsdNqwLugD5yRlp/view?usp=sharing

Bigbadcat612 commented 5 years ago

The .blend file: https://drive.google.com/file/d/1URezwZXfG-Bt2yUT7RSLXtmqVPw7-_JY/view?usp=sharing

My (edited) blam.py:

https://drive.google.com/file/d/1GPdXrPzSqt_CFsmowqsdNqwLugD5yRlp/view?usp=sharing

Well, thanks for the reply!

It seems for me best to look an alternative to BLAM. Maybe autodesk image modeller or smth.

stuffmatic commented 5 years ago

In case you've missed it, BLAM is no longer actively maintained. You may want to check out fSpy

Bigbadcat612 commented 5 years ago

Wow, thanks! I missed fSpy for some reason. Gonna check it out

On Sat, Jan 5, 2019 at 10:59 AM Stuffmatic notifications@github.com wrote:

In case you've missed it, BLAM is no longer actively maintained. You may want to check out fSpy https://fspy.io

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stuffmatic/blam/issues/4#issuecomment-451639457, or mute the thread https://github.com/notifications/unsubscribe-auth/AcJv9_MqdTBjhouhgP-fP-82zq4BBG2Nks5vAGmLgaJpZM4AwhVB .