My printed pattern got slightly different upscale for 0X and 0Y dimentions. How to adopt calibration for it?

[ishipachev]

Dear authors,

I recently figured out that all patterns I print have some weird issue, that squares which supposed to be squares. Is there a simple way to hack it out based on real measurements of the pattern? I have something like 0.5% upscale for 0Y dimention compared to 0X dimention. And this change caused by printer drivers is out of my control.

Is there anything I can do with already printed pattern by just changing the code? Like some place to look at at least?

[puzzlepaint]

I would first like to note that the calibration process involves a full bundle adjustment step without constraints on the pattern geometry. This means that slightly imperfect patterns, such as caused by a printer's distortion, or for example by non-planarity of the pattern, should not affect the accuracy of the calibration as long as the initialization succeeds. I think that the only exception to this is the final scale estimation for camera rigs and/or non-central cameras, which actually depends on the size of the pattern being correct. So, in case you want to calibrate only a single camera with a central camera model, the slight pattern imperfection can most likely be ignored.

If the pattern imperfection does matter for your case, then:

• Perhaps the easiest solution might be to scale the PDF before printing in the opposite way, such that the actually printed pattern has the same grid dimensions in X and Y direction.
• The code was written with the assumption of a pattern with a square grid. To change this, a good start might be to look for all occurrences of square_length and cell_length_in_meters in the code (applications/camera_calibration/src/camera_calibration/) and adjust these such that different values may be used for the X and Y directions. Probably not all occurrences of the former need to be changed, since some parts of the code use a coordinate system where the feature locations in the pattern are on integer coordinates.
• If the calibration itself works and you only want to ensure that the final scale estimation uses the correct dimensions, then it is probably sufficient to change the function ScaleToMetric() in applications/camera_calibration/src/camera_calibration/calibration.cc.

[ishipachev]

Hi @puzzlepaint Thank you for detailed answer. In my case I have a usual camera with slightly, around 0.5% moved optical center. So if overall calibration includes bundle adjustment without restriction on the geometry, that you are right, it should be fine. By the way, out of curiosity question: what do you think about quality of the calibration if we indeed force planarity and exact geometry of our pattern?

[puzzlepaint]

what do you think about quality of the calibration if we indeed force planarity and exact geometry of our pattern?

My impression is that it is typically hard to manufacture a "perfect" pattern. If the actual pattern is non-perfect, then forcing the geometry to the perfect version will most likely make the results worse. With an actual perfect pattern, I am not sure how much would be gained by forcing the geometry to the perfect state. Could maybe be interesting to try this out with simulated data. I think that the difference between the two versions should become smaller with more input images being used, as more images should allow for a more accurate reconstruction of the geometry in the non-constrained case. Not sure whether the difference would be relevant with a typical number of input images.

[5trobl]

Hi there!

FYI I wrote two papers (ICRA 2008, ICCV 2011 workshop paper and poster) many years ago on the topic and implemented it in our calibration software DLR CalLab (old version w/ the requirement of an IDL VM, which is free but cumbersome to download -- our new C++ version is not open yet, alas).

As Thomas says, BA is a safe bet if you really cannot improve the pattern's geometry (e.g., working on legacy data). A limitation of a straightforward approach using BA is that you must see each point more than once, which is inconvenient if you (as we do) aim at both, a minimum/limited amount of images and at full image coverage: . Another limitation is that you should not move the pattern during calibration.

TL;DR: It makes sense to automatize by software every step concerning error-prone humans, like printing and measuring the pattern -- don't take it personal 😄

Having said that, to be honest I rather print patterns on aluminium sandwich panels (Dibond plates), measure them, and take care not to bend them during image acquisition nor storage. But BA works fine, albeit slow in my IDL software. As you noticed, it will only ask for a metric scale in the case of stereo or hand-eye calibration.