to describe this a bit more - I’m working in a visual programming environment TouchDesigner with python as a scripting engine. For a project I have created 3 components:
a board generator
a pattern detector
a camera calibrator
The board creates a class depending on board type (checker, circle, charuco, aruco) with information on the board configuration and the actual aruco board saved as a member .Board
The pattern detector finds the pattern and moves all relevant information into a pattern class. Part of that class is also a .Board member which get’s the Board’s class assigned.
Hence in the camera calibrator, the Board is fetched via pattern.Board.Board
the board itself is created such with mrkObjPts being the same that are posted in the gist and the mrkIds a list from 0 to 444:
My next steps to move further would be to try to get this going with the regular calibrateCamera. I can fish out the objPts and imgPts necessary with the found ids, so that shouldn’t be a problem. Still unclear though what I might be doing wrong.
I can’t share the whole code as it’s distributed across multiple classes but perhaps I should write a quick testcase in a single script…
you are creating charuco while I’m creating aruco. I’m guessing hence that everything I do seems correct?
I have no trouble with planar charucos, chessboards, circlegrids etc. it’s only non-planar aruco.
Right this is the limitation of the GridBoard Class for calibrating planar boards. Yet I’m trying to calibrate a non-planar setup hence I’m using the Board Class which does not have the planar limitation.
My setup has an x-amount of planes theoretically and in the testcase 3.
Sorry I didn’t check this.
Note that you don’t need to use calibrateCameraAruco you can use calibrateCamera with your grid. Sometime you can have better results first you calibrate intrinsic and then calibrate distorsion read code here and here
thank you for the tip regarding intrinsics and distortion. Is there a benefit in using calibrateCamera over the aruco version or is aruco just a wrapper around it? I like that I don’t have to fish out the object points for it.
A quick note that you will drop accuracy if you use the Aruco style board vs ChArUco. This is because the subpixel quality of corners is much higher for inner corners (e.g. up 10x, especially for mono cameras). Non-planar calibration objects also introduce errors from fabrication (in my experience the loss of quality of data outweighs the additional value of the non-planar data)
I presume you might be doing some kind of XR stage setup there? If so, also note that corner subpixel quality is also reduced when working with screens vs printouts (e.g. interference between pixel grids of camera and screen).
I hope you manage to get something working well over there.
If you just want the extrinsics between the non-planar board and the camera (i.e. already have cameraMatrix and distortionCoefficients that you trust) e.g. for XR calibration then none of this is really too much of a concern (but in that case you can also use the solvePnP function instead of calibrateCamera)
I’m making a lot of presumptions here so apologies if I’m off the mark
your assumption if fully on point
Working on a solution for arbitrarily shaped led stages (curved) knowing though that every led panel is planar. Hence the initial idea to use aruco markers to do lens and hand-eye calibration to figure out the tracker to lens transformation.
I already hit a snag with the lens calibration as the error shoots sky high on narrow zooms and your message supports my thought that for this part I have to use a board based (charuco) approach. To gather the information for the hand-eye calibration, I can then use the aruco markers and solvePnP.