I’ve been observing unexpected behavior in RC, so the following may not be solved by thinking about it strictly in terms of a photogrammetry problem, but I also can’t rule that out, so here’s the situation. I have two components with overlapping content in a cave scene, the first w/ 946 photos, the other 523, the overlapping region having about 160. Perhaps, it’s helpful to see some of this geometry. Here’s the 946 component:
That arm taking off to the lower left contains the overlapping photos, that big data gap to the pit containing a high dome, a cupola, that I wasn’t able to capture on a first trip. Returning with an extension pole and crew, we got coverage in that area, seen here:
You see the same arm lower left. I’ve got the alignment settings exposed, Force component rematch = True, as is Merge components only. Note, I’ve got several smaller components above these main two, but ignore them, tried a great variety of approaches, early on deleted these smaller components to nuke their influence. Also to note, all photos set to Use all image features. Here’s what I’ve tried:
- de-activating photos from 523 component associated with the cupola (B), this on the theory that discrepancy in the geometry between the large vertical spaces, these only captured from a fairly central placement of the extension pole, thwarted merging A and B.
- de-activating all extension pole-acquired photos from A and B. At least the cupola contains a closed loop, it being domed at the top, did the open top at the pit cause it to flare?
- resetting to active all photos, then de-activating only those photos on the ground, but not within the overlapping set, there being a region of ground that was captured about 6 months apart. This ground may have changed, this cave takes water, the larger cobble only moves with major flooding, but even lower water levels might have rearranged the furniture.
- activating only the overlapping photos from the arm and ground further up beneath the cupola
- activating only sections in A not covered in B.
- activating smaller sections of an overlapped region between A and B.
Using this last approach, I finally managed to produce a single instance of a component that merged any photos from A and B into a new C.
Note, the right arm joined the cupola, as well as the entry to the pit.
Since C contained all of B, I deleted B. Now went after growing C:
- kept as inactive the remainder of A’s photos in the pit, turned on the remainder of A’s photos belonging to the right arm, nada.
- Making inactive right arm in A, adding to active only those photos in A in the pit that aren’t from the pole.
I’m scratching my head why these photos in A at the base of the pit didn’t merge. You see in the grid view a small selection of cameras, these being common to C, note how all the remaining active photos at the base of the pit are well overlapped, these never being a problem getting to align out of the gate. What could possibly be throwing RC blocking a merge of these photos.
Equally strange, I made inactive all these pit shots in A, then lassoed a small handful of cameras in A extending the right arm in C, switched those to active, essentially the same conditions as this previous approach at the pit base, same result, otherwise easily aligned photos won’t merge, not a one.
I could continue submitting conditions, pointing to things that don’t make sense, and opening questions about RC functionality, whether specific to my install or possibly bugs, but my response to so much nonsense was to keep going with the experimentation and wide open observation. Boy did that pay off.
I selected the cameras common to A and B in the junction area, beneath the cupola and between the left and right arms and the pit base. With only those cameras active, with Force component rematch True and now Merge components only False, I ran alignment. Finally, a new component that joined the cupola to the surroundings from A. I then activated a dozen or so neighboring poses from A, alignment added them, and so forth for a half dozen or so iterations growing the scene until most the cameras were added.
BUT, on closer inspection I discovered a major separation in the pit wall. Interesting. This could well explain why A and B couldn’t merge before, a deformity in one and/or the other, once merged, pushing the problem back in the direction it originated from or some such. Unless you see the separation in a surface, there’s no feedback allowing you to know. Once I saw the separation, what used to be a big frown now brings a smile. That’s because I figured out the fix. In hindsight I believe the tools were there all along, but the new Expand tool, most useful.
The fix. I thought about the problem this way, got a component that’s basically good except for this separation, a loop that won’t close properly. I figured the tie points in those related cameras were bad. (BTW, bad tie points would also explain why otherwise good CPs return high projection errors. We’ll get back to that.) How then to delete the bad tie points. So far, the only way I’ve heard us talking about deleting tie points is in deleting the component used to store them. While that’s true, it’s like throwing out the baby with the bathwater and misses a more surgical alternative.With Tie Points enabled in Scene, I rotated the model to get a perspective on the separated wall in a way that allowed me to lasso this region. I then clicked Expand, noticed a huge chunk of cave (too huge) lit up, then clicked Find Images, more cameras than I wanted to nuke. I choked down on the selection with the points lasso, Expand> Find Images, now seemed like I had contained the selection to the most offending images/tie points. I switched these photos to inactive, ran alignment, a new component formed with a hole in that area, fine. Now let’s close it, switched the cameras back on, ran alignment, no more wall separation!
That worked in this case. Not all separations are so focused, like a bubble pushed out. I’ve got one in another project that runs long from high on one wall down to the floor, then crosses diagonally across some 30’. Some of this is due to inadequate capture, wasn’t equipped with the pole to provide loop closures until at the very end, so a very predictable condition inviting a separation. I’m going back once more to provide those. And if my present component can’t digest some bad tie points, I’m now confident RC has the tools to nuke them.
On a final note, and I should post this in the requested features section, the placement of CPs, especially when Weight is increased, should be enough to instruct RC to nuke or at least dampen any of the surrounding tie points near a given CP. We only see the projection error of the CP climbing up, a sign that the tie points are retaining greater voice. Agreed?
