Surveying applications #2253
MrClock8163
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello
I'm studying land surveying at university currently, and in the past months I was working on a study project with one of my professors, regarding close range photogrammetry. Among other photogrammetry solutions, we also examined Meshroom, mainly because surveying is not in the main profile here, so it was interesting to see how it performs as an automated processing solution.
Personally I really like Meshroom, and we found that it performs really well (not counting the lower point cloud density compared to other photogrammetry software), but we also found that it lacks in one key field, georeferencing. For obvious reasons, for surveying applications it is important to transform the reconstructed point cloud into an existing coordinate reference system. For this we usually use ground control points (GCP, that we either visibly marked with artificial markers, or characteristic points of the surveyed area), that we measured in the target coordinate system. With this being said, I'd like to propose 3 ideas/improvements, that would make meshroom more suitable for surveying tasks if need be.
When I started the project, I saw that Meshroom now supports not only the CCTag markers, but also the 16h5 AprilTag family, so I used these markers to mark control points for the georeferencing. Unfortunately we found that barely any parameters are exposed in the GUI for marker detection and as such, the detection was unreliable. This leads me to my suggestion:
It would be nice to have a built-in way to import the image coordinates of GCPs from an external source. For example: since the native marker detection was unreliable, in my project I used a utility tool called Find-GCP to detect the markers on the images. I could add a modification to this tool to output a CSV file containing the marker matches in a
imageX, imageY, imageName, markerID, markerSize
format. Then I wrote a custom processing node for Meshroom that would read this CSV and the SfMData from the CameraInit, and generate fakecctag3
orcctag4
feature describers from the data.While this proved to be a working solution that's usable both on Windows and Linux, it'd be nice to have a built-in feature for this. Maybe a new
genericMarker
describer type could be added that'd be essentially the same as thecctag3
data, just treated separately. This would allow users to use third party tools at their convenience to detect the GCPs in the surveyed area (or maybe even do it manually).More often than not, when we measure reference points with a total station, or an RTK GNSS receiver, the coordinates we download from the instruments are in a CSV file in
pointID, easting, northing, elevation
format. Currently the only way to add the target coordinates in the SfMTransform node is by manually adding them to the list, which is rather cumbersome when we talk about an automated solution. Furthermore, if I add all my GCP coordinates to the list of the node, but one or more of points could not actually be reconstructed in the sparse point cloud, the transformation, and the whole process fails. So here's my suggestion:Modify the SfMTransform node (or implement a marker specific version of it) that could read the GCP coordinates from a CSV or other formatted file, and would be robust in the sense that it would ignore GCPs that were not actually reconstructed in the sparse cloud. It would also be nice if it had an option to automatically offset the coordinates by constant XYZ values, in order to preserve the coordinate precision (this is a relatively common practice when working with large coordiantes like in the UTM projection).
Currently the colorization of the dense cloud is giving spotty results in my experience. The textured mesh is perfectly fine, but the dense cloud has a tendency to have smudged colors in stripes (geometric position is fine though). I couldn't reliably reproduce the issue, but it happend a lot during my investigation. The color in general is not very even, it seems it's not adjusted from the color variations between images. It'd be nice if the color calculations could be improved.
For the first two items, I have my proof of concept custom nodes publicly on my github, maybe they could be used as inspiration.
I know this is a very very long text, but the ideas are rather simple behind it.
https://github.com/MrClock8163/MeshroomGCPMarkerAdditions
Beta Was this translation helpful? Give feedback.
All reactions