Hi,

I have a technical question relating your calibration process.
Here is a short background,
I followed the instructions in iPiSoft documentation website,
I recorded several calibration sessions (in 2-Kinects setup), with both of your methods, the "3D board" and the "glowing marker".
The calibration results which are obtained by the iPi-Studio software, were defined in "Prefect" quality.
I exported the "scene" after each calibration process and as i understand,
the results could be exported in .xml file (example attached) representing each one of the Kinect sensor's "3D rigid transformation" (Rotation and Translation) separately.

My current task is "merging" those two "separate" transformations into a one single transformation,
in other words, i would like to represent the direct (relative) transformation between the two cameras ( kinect[1] --> kinect[2] ).
I haven't succeeded in converting the.xml file in various of conventional techniques,
generally, by converting the "rotation degree-angles" into two rotation matrices and combining them.
The main issue happened when i try to combine the translations, there is a rough error when i tested it against a "ground truth" measurement of the scene.
I would be glad to get your advice about "how to properly convert your calibration .xml file into a single transformation format".

Thanks a lot !!

...

Could you explain better as to why you are trying to perform this?

...

Yes, of course.

I'm conducting a computer science research,
one of my tasks is to review techniques for "multiple cameras calibration".
iPiSoft offers two calibration methods (board and glowing marker).
These methods seems to be very accurate, that is according to several calibration sessions i did which the results were very consistent, so i would like to add these iPiSoft techniques into my benchmark review.

The issue is that other calibration methods (such as "chess board", "wand" and etc.) output a single Rotation matrix and translation vector and not a "pair" of transformations.
I tried to convert it by myself but the results were "too much far away" compare other techniques,
so i understood that my conversion was incorrect...
That's why i'm looking for the right way for converting iPi calibration format into a standard (relative) transformation between two cameras.

Hope you can help me figure this out,
Thanks again !

...

Ok thanks, I now understand your premise for this, but I believe you are comparing apples to oranges in the way each of those calibration methods is read by its parent program, so I am not sure what you are attempting with iPi will work at all, iPi could elaborate more I am sure.

The checker board technique has to be one of the most demanding and complicated though, isn't it?

...

Checker board is the "classic" calibration method which designed for 2D color cameras.
Actually, there is a very simple Matlab implementation for operating such calibration.
https://www.mathworks.com/help/vision/r ... oints.html

...

Yes, but I was referring to the actual procedure of moving the board, being it takes a bit longer to show it to each camera in the loop, and let it find those points each time, being the more complicated part, not how the code recognizes, or processes the data.

I hope iPi can shed some light on your request though, but I think iPi uses a form of point cloud to make its calculations, even for 2D cameras, but I can't be exact on the process.

...

Let me first describe you the details of camera transformations stored in scene files.
Translation component is pretty obvious - the value is a translation vector with components specified in meters.
Orientation of camera is specifed as Euler angles in degrees, with the order of rotation as they go in a file - first around X axis, then around Y axis and Z axis last.

To get the full transformation of a camera, rotations and translation are multiplied so that rotations are applied first, translation last.
C = Rx * Ry * Rz * T

To get transformation from camera#1 to camera#2, multiply inverse transformation of camera#1 with transformation of camera#2
C12 = Inv(C1) * C2

Note. Coordinate system is right-handed, as you can see in Mocap Studio.

...

Just curious... Isn't camera 1 real world height off ground measurement (or any cameras height actually to get that specific transformation between 2 cams) needed for this transformation spacing between 2 cameras required for the scaling process for their relative positions apart in world space to be correct?

Or, is that just needed for the view plane offset inside the Studio, and adjusted by the coding to maintain the proper spacing while tracking?

If you have this number set (cam 1 height off ground) different than real world height, this will change all the values in the XML file, correct, and will throw off the proper scaling for any other 3D package?

...