Skip to content
This repository has been archived by the owner on Jan 14, 2020. It is now read-only.

Calibration generates bad focal length #4

Open
porglezomp opened this issue Jun 22, 2013 · 10 comments
Open

Calibration generates bad focal length #4

porglezomp opened this issue Jun 22, 2013 · 10 comments

Comments

@porglezomp
Copy link

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
Copy link
Owner

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

@offtools
Copy link

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

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

thegoodhen commented Jun 22, 2018

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

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

thegoodhen commented Oct 22, 2018

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

thegoodhen commented Oct 22, 2018

@Bigbadcat612
Copy link

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
Copy link
Owner

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

@Bigbadcat612
Copy link

Bigbadcat612 commented Jan 5, 2019 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants