When working with camera calibration and next projection of points from 3D to 2D, problems were found with coordinate systems when performing translation (tvec in parameters projectPoints). In the classical photogrammetry approach, the translation vector Rs must be given in the world frame. Example can be found in The Civil Engineering Handbook, Second Edition (uceb.eu) formulas 56.13-56.16.
However, when calling the projectPoints function, it turned out that a vector in the camera coordinate system is expected. This problem has been described in the following issue 16292, but it already closed. Can you explain why such a solution was chosen and is it possible to clarify the documentation for describing the translation vector?
the issue you cite isn’t “closed”, it got resolved with a merge.
that API only deals with things going on between the camera frame and the object frame.
a world frame is irrelevant here, from a mathematical standpoint.
if docs are sloppy on this, you can generally assume that “world” is synonymous with “camera”, unless both frames were introduced as being separate.
A is the camera intrinsic matrix, R and t are the rotation and translation that describe the change of coordinates from world to camera coordinate systems (or camera frame)
in that context, “world” means “object”. the transformation transforms object/world-local geometry into the camera frame.
do not expect the docs to be teaching materials. they make more sense if you already know what they’re supposed to mean. they are engineering notes.
in that issue you linked, someone recommended a book. I don’t know if it’s good, but it might be better than the docs. perhaps give “multi-view geometry” (Hartley & Zisserman) a look too.
