Coordinate system alignment to specific markers or between scenes #695
Conversation
…ent: views ids, poses ids, filepath pattern, specific metadata, markers ids - SfMAlignment: provides an option to align based on markers ID - SfMAlignment: provides an option to align based on poseId - SfMAlignment: provides an option to align views based on file pattern matching (regex) - SfMAlignment: provides an option to align views based on specific metadata matching
| if (d[i] == 255) | ||
| { | ||
| ALICEVISION_LOG_TRACE("Found marker: " << i << " (landmarkId: " << landmarkIt.first << ")."); | ||
| landmark.rgb.r() = i; |
There was a problem hiding this comment.
why don't we just add another field to landmark like markerId always initialized to a dummy value (for all the other features that are not markers)?
Using the color attribute is a kind of workaround. Also, it is limited to 255 values, which is limiting in case other types of markers will be integrated in the future (eg. aruco &C).
Ok we need to change all the IO functions of sfmdata but I think it's better than "hiding" data in the same structure. And I think we can still preserve backcompatibility with other sfmdata files that has not that field.
There was a problem hiding this comment.
As I explained in the PR summary, it will be a waste of space as most of the landmarks are not markers. I agree that it looks hackish. I was considering using an union between RGBColor and int but that represents many changes in IOs and creates complexity.
The correct long-term solution is probably to have landmarks per descType, but that's a major change that I cannot afford for now.
Filter out matching views without pose.
… from another reconstruction based on matching views
In many places, we assume that tracksPerView has a key for each view. So this commit adds an initialization step to ensure that it is the case (instead of checking if the key exists all over the place).
Description
Use CCTag markers to define the coordinate system: the SfMTransform node provides new inputs to align specific markers to known 3D positions.
Features list
Implementation remarks
Markers IDs are stored in the landmark color to avoid the creation of an additional field which would take space for nothing on all landmarks. Maybe in the future, we could consider to have multiple types of landmarks (with different data structure) but that would represent a complex change for a limited benefit for now.