Calibration with known camera position

[myronzbrown]

Thanks for making this open source. I have a use case with PTZ cameras where I know the camera position. UCalib sometimes works to give me the correct position without forcing it to do that, but it's not entirely reliable because the camera fov is not that wide. With the constraint, I think it would be very reliable. I'm working on an ugly hack to force this in the code right now, but I was wondering if you already have a nice clean way to enforce this in the initial basis calibration.

[Ulises-ICM-UPC]

Thank you very much for your interest in UCalib. We appreciate it. We find your suggestion very interesting. We are going to modify it, so there is no need for you to work on it ;). We will update the code before the end of this week. We will let you know.

[Ulises-ICM-UPC]

@myronzbrown
The option to force the value of some of the variables has been implemented. This is done through the 'givenVariablesDict' dictionary. The details can be found at https://github.com/Ulises-ICM-UPC/UCalib#basis-calibration. Some other minor changes have been made to the code such as the option to allow overwriting results.
Please do not hesitate to contact us for any further issues you may consider of interest.

[myronzbrown]

Thank you! I'll try it out this week.

[myronzbrown]

Thanks. I tried it today, and it works well. Maybe you can help with a separate issue I see. There appears to be a random seed based on time in the code. I sometimes get very good results but then at other times complete failures with errors > 100 for the same images with the same GCPs. It does appear correlated with time. I had hoped this was just some unreliability from trying to estimate too many parameters that would go away when constraining the known camera position, but it looks like more than that. Is this something you have noticed?

[Ulises-ICM-UPC]

Thank you for your message and thoughts. We are glad that the parameter forcing is working despite the fact that sometimes the error is large. Regarding the latter, as you suggest, the code finds a first seed with a Monte-Carlo method with maximum time, "timedeltaMax", and maximum number of iterations "counterMax" modifiable. It is also possible to rerun the code to obtain better results.

However, the above should be avoided (and we agree on your thoughts about fixing the camera). The code includes some reasonable ranges for some parameters that, being quite general, have been set with coastal video monitoring in mind (camera looking "down", e.g.). These parameters can be modified (data['refValuesDict']['ta'] is set to pi/2 and could be increased to pi). Maybe you don't mind sending us a case, so that we can try to detect (and solve) what is the problem that we haven't had with our data. Sincerely,

[myronzbrown]

Thanks. And sorry for the long wait. I was away from work and also am not getting email notifications from GitHub, which I should go try to fix. Thanks for the recommendation about changing 'ta'. I'll give that a try. If it doesn't work for me, I may be able to work up an example data set I would be allowed to send.

[Ulises-ICM-UPC]

OK Myron. Please, let us know. Thanks!

[myronzbrown]

Quick update. I tried changing the TA values quite a bit, and it produces similar results for me with those different starting values, sometimes very good and sometimes fails. I can iterate to get a good result, so that does work. For my current situation, my cameras have plastic domes that are causing distortion that cannot be easily modeled in calibration. It's causing the residual errors to be larger than usual. It may also be causing the instability in the solution, though UCalib does produce a nice though understandably approximate result when it does find a good solution. I'm having similar problems with other solvers. I'll be working with other cameras soon that don't have the domes, and I'll check then to see if that helps with stability. I don't have an easy way to send example data, unfortunately. Thanks for your help on this.

[Ulises-ICM-UPC]

You are welcome, Myron, and thanks for the info. We understand that the plastic domes can introduce a difficult distortion, and in any case, we would suggest using the "full" model if you have enough GCPs. Just a comment in regard "I can iterate to get a good result, so that does work", which is good news: when re-running, the code always uses the previous saved solutions (so you can only improve); also, instead of re-running, you can perhaps increase the timedeltaMax and counter Max. Thanks for your feedback and suggestions!