Project

General

Profile

Feature #113

findimageoverlaps incapable of adding images to existing overlap file without complete rerun

Added by Lynn Weller over 7 years ago. Updated about 2 months ago.

Status:
Acknowledged
Priority:
Normal
Assignee:
-
Category:
Applications
Target version:
-
Impact:
Software Version:
Test Reviewer:

Description

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.

History

#1 Updated by Steven Lambright over 7 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)

#2 Updated by Steven Lambright over 7 years ago

I'm acknowledging that adding another Cube to the overlap list is indeed a problem.

#3 Updated by Steven Lambright over 7 years ago

Lynn,

"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,
Steven Lambright

#4 Updated by Lynn Weller over 7 years ago

Not sure I understand what would be different between adding to an existing overlap and including in the initial run. Others need to be involved in this conversation.

#5 Updated by Steven Lambright over 7 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.

#6 Updated by Tammy Becker over 6 years ago

This issue needs to be revisited; possibly with SSC

#7 Updated by Lynn Weller over 6 years ago

Or maybe the processors need a better understanding of what the change might mean and get a chance to test it. I'd like to know how run time would improve (hopefully).

#8 Updated by Anonymous over 5 years ago

  • Target version deleted (150)

#9 Updated by Tammy Becker over 3 years ago

  • Category changed from API to Applications
  • Assignee deleted (Tammy Becker)

Also available in: Atom PDF