findimageoverlaps incapable of adding images to existing overlap file without complete rerun
The program findimageoverlaps creates an overlap file which is used by such programs as autoseed for automatic seeding of points in an overlap area. When a user has new images to work with, overlaps for the existing and new data must be completely recomputed from scratch. This is not a problem when there are a small amount of images (dozens), but as volume increases the program takes a very long time to run.
I ran the program on 5546 messenger images and it took 83h 25min to run. If I add even just one image to that list, I must rerun findimageoverlaps in its entirety to compute the new overlaps. We need a way to add to an existing overlap file without having to push all of the data through all over again.
Additionally, when in place, a handful of the cnet utility programs should be updated to accept an image overlap file if they don't already do so.
This new functionality would greatly facilitate the cumbersome process of adding new images to existing networks. I currently avoid using findimageoverlaps due to its excessive run time, inflexible input options, and the inability of some programs to utilize an overlap file. This program could use some attention.
#1 Updated by Steven Lambright almost 8 years ago
If we add this functionality, the results of adding the one image will not be the exact same as if it was included in the original run. Is this behavior acceptable?
If so, then fixing this ought to be fairly easy.
(For the programmer - put the new image at the beginning of the overlap list and re-do the full calculations; most of the intersections will find no overlap and have no change)
#3 Updated by Steven Lambright almost 8 years ago
"Additionally, when in place, a handful of the cnet utility programs should be updated to accept an image overlap file if they don't already do so." Which programs are these? Is there a chance that they don't need the overlap list which is why they don't accept one?
Thanks for the feedback,
#5 Updated by Steven Lambright almost 8 years ago
The calculation results, in a perfect world, would be the same. But our intersection operations give (usually) insignificantly different results when performed in a different order. However, with how many polygons we generate, these very slight differences can cause a potentially noticeable difference - say if a polygon intersection just barely failed. The original input list's order influences the result (and potentially the failures) in a similar manner. It probably will never be noticed, its existence needs mentioned is all.