Failing to understand coordinate spaces

[jrp]

Has someone done a write up on how all of the coordinate spaces and transformation matrixes work in metashape?

There is a specific problem below, but I really want the general answer so that I can solve these problems myself as I keep running into these.

I have a model of a room, it came out about ~45 degrees off level. I clearly have no way to get world coordinates mapped onto it, but on the assumption that the floor is level I rotated the bounding box so that the red side is down. I then output an orthomosaic, on "top XY", the orthomosiac was still off level by 45 degrees. Logic told me that as the red face of the bounding box is used for the bottom of a height field, it has to define the "bottom" for other things.

Next I attempted to fix this by adding some fake GCPs. I added 3 points on the floor, measured the distances between them, did a little trig in excel to produce plausible set of local meter coordinates for 3 points at Z height zero for the 3 points, entered the numbers then clicked the "update" button in reference, nothing improved.

Please advise.

[Alexey Pasumansky]

Hello jrp,

Do you have any original referencing information for the chunk (except for the fake GCPs)?

Bounding box does not define the coordinate system space, otherwise it would severely affect any processing meant to be accurate. However, it's elements may be used for other features, including:
- base plane for Height Field mesh generation,
- region-based Cylindrical orthomosaic/DEM generation,
- automatic animation track creation,
- spherical parametrizaion of the texture atlas.

If you do not have any reference points (known coordinates for the camera locations or markers), you can manually adjust the model's orientation in the coordinate system space using Rotate Object tool.
You can also use the following script to align the coordinate system orientation to the bounding box orientation (which you might have originally expected):
https://github.com/agisoft-llc/metashape-scripts/blob/master/src/coordinate_system_to_bounding_box.py

As for the approach with the fake GCPs, make sure that you have checked on the markers in the Reference pane before pressing Update button.

[jrp]

Thank you for the very fast reply.

Clicking the check marks next to the markers solved that one.

I had forgotten about the rotate object tool too, that would have been the right thing to use.

I do not have any original reference points except for scale bars.

There is still the larger question about how these things actually work. That is: the relationships between the software internal coordinates, the local coordinates, world cordinates, bounding box, and which tools use which. How is the data actually stored, and what matrixes run on what.

Also, feature request: would it be worth adding bounding box top/sides/bottom to the options in the orthomosaic dialog? it doesn't sound like this would take much development as it supports "current view".

[Alexey Pasumansky]

Hello jrp,

Most of the chunk elements are stored using the internal coordinate system: coordinates of the camera locations (including orientation angles), marker locations, bounding box location and orientation, coordinates of the tie points, dense cloud points and polygonal model vertices.

When the chunk is transformed/referenced chunk transformation matrix is introduced. For local coordinates this 4x4 matrix is used to apply the transformation from the internal system to the referencing system.

For the geographic/projected coordinate systems the chunk transformation matrix converts the internal coordinates to geocentric coordinates. And to geocentric coordinates the project method is applied that corresponds to the selected geographic/projected coordinate system (which is not Cartesian anymore).

[jrp]

Thank you very much for that, it's actually much simpler than I expected it to be now that you've explained it.

Can I ask further: what does the "move object" tool actually do? Does it simply add a chunk transformation?

From reading the source code "coordinate_system_to_bounding_box.py" appears to change the chunk transform matrix to a carfully calculated combination of the existing chunk transform and the bounding box transform. The internal numbers stay at the arbitrary values generated, and the chunk transform interprets everything inside the chunk so that the bounding box is aligned with world coordinates? Am I right here?

Presumably "combine chunks" copies and converts all of the actual locations in each chunk through the chunk transform matrixes to local coordinates, and creates a new chunk with no transform matrix?

Thanks,
JR Peterson

[Alexey Pasumansky]

Hello jrp,

Move object adds (modifies) translation component of the 4x4 chunk transformation matrix. Using Scale Object applies scale multiplier to the top-left 3x3 block and Rotate Object modifies the rotation matrix.

T = |s*R   t|
      |0       1|

The script is modifying the chunk transform matrix. But if you use bounding_box_to_CS script (that aligned the box to the coordinate system axis), then the coordinates and orientation of the box in the internal system would be changed, while chunk.transform matrix is preserved.

Merge Chunk operation will inherit the chunk.transform from the first chunk in merging list. The coordinates of the points, cameras and etc. of the other chunks will be converted to the merged chunk internal system according to the transformation matrices of the chunk and merged chunk.