I am having another beginner problem with the program. I had a sequence of images that wasnt aligning as well as it could. However then I isolated it and aligned it, I managed to get it to align as it should. However there are other parts I needed to align to it that are quite distant (like half a km away), so have no effect on this part. I have eventually managed to align them, however despite clicking ‘Lock pose for continue’ on those images I worked hard to align, it has decided to realign them and it messes them up…
Here is a demonstration of what it did, this is it aligned correctly;
And then this is what it did when realigning despite having locked it, and its completely messed it up…
this is quite strange behavior. Did you have selected all images in that component? When you are adding new dataset to this (the one which is half km away), is there some visibility connection? Was this dataset aligned? What you can try is export XMPs, then create new project with these images + XMPs and set them as Locked in Prior pose.
Sorry to necro’ a post, but the same thing’s happened to me. Lock Pose For Continue doesn’t seem to do a thing - Reality Capture splits, realigns, and straight-up breaks components to its hearts desire is there an option I’m missing that will actually lock the cameras in their current alignment?
Hi @scopxtech,
as mentioned above, you can use the XMP workflow.
Can you show some images from your project with these errors? What are you alignment settings? When are you setting the Lock for continue option?
Hi @OndrejTrhan, thank you for the response! Unfortunately our dataset is somewhat confidential, but I’ve put together a graphic that I hope illustrates the problem. My alignment settings are attached as well, though I have tried tweaking those - no dice so far. Let me know if there’s anything else I can clarify, and thank you for your help.
Hi, for cases like this (if you have a shared part of the dataset) you can use the Merge using overlaps option: RealityCapture Help
Also, if your components are georeferenced, you can set Merge georeferenced components in the Alignment settings.
Will give it a try! The data is mostly extracted video frames, so sadly no RTK referencing. Interested to see whether Merge Using Overlaps yields better results. Will revert after giving it a shot.
Well. Unfortunately not. After experimenting over the last two weeks, Merge Using Overlaps didn’t fare any better - even adding control points didn’t fix the issue: RC would realign the component with hundreds of pixels of error on the control points, torquing and twisting the scene out of recognition.
Exporting XMPs did work a little better, but unfortunately that workflow seems to lock down further refinement: attempting to realign after a few adjustments yields an error saying (approximately) “All XMP-imported photosets or laser scans must be aligned at once: incremental addition is not supported” which is sort of an arrow to the knee, considering the align isn’t perfect and needs to be tweaked.
The strange thing is that every single ‘piece’ of the scene (300-600 cams) will align just fine: it’s putting them together into 1000+ cam components that starts causing issues.
The video frames are not ideal for photogrammetry, as the resolution is lower and also there could be some blur.
It is really strange that it behaves like this. Using the Merge using overlaps, have you reset the alignment settings? How many images are common for the components?
In this case it would be really great if you can share the images with us, as it could be bug. If it is OK with you, I can send you the invitation for the data upload for internal testing.
Thanks for staying with this, I appreciate it. I’ll pass the request up the chain and see if we can get you some of our problematic dataset.
Yes, I reset alignment settings - along with the entire RC install (make it like a fresh install). I can do it again if that would help, however I frequently tweak the align settings depending on the dataset so I feel like I’ve gone through most permutations of those at this point
Your point regarding video frames is very true: we do use stills wherever possible, but external constraints made video the only feasible method for this particular project.