Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parallelizing classification and stitching #1

Open
aryarm opened this issue Sep 11, 2019 · 3 comments
Open

parallelizing classification and stitching #1

aryarm opened this issue Sep 11, 2019 · 3 comments

Comments

@aryarm
Copy link
Member

aryarm commented Sep 11, 2019

goal: parallelize the classification of each image and then stitch the classification masks together, rather than applying the classification to a large, stitched image

motivation:

  1. the classification step will be much faster and allows us more flexibility when creating pipelines
  2. we'll be able to avoid the effect of running the classifier on artifacts created by the stitched image, (like black holes, etc)

problem: the stitching software doesn't tell us how it stitched the images together

challenges:

  1. how do we stitch classification masks together geometrically?
  2. when classification masks overlap, how should we resolve diverging classifications?
@aryarm
Copy link
Member Author

aryarm commented Sep 11, 2019

Potential Solutions

There exists an open-source alternative to Microsoft Composite Image Editor. Hugin works on all platforms and has both a GUI and command-line interface. It can output stitched images as multiple files in which each file is a cropped/transformed version of one of the the original images (see the Hugin FAQ). We could run the classifier on each separate output image and then stitch the masks together the same way we do the output images (ie using tiffcp). This would sidestep challenge 2 above, since the images we classify won't be overlapping to begin with.

Equivalently, we could simply take the large stitched image that we would get from Microsoft Composite Image Editor, break it up into pieces, and run the classifier on each piece. This approach wouldn't let us run the classifier on each original image exactly, but does it matter?

However, there might be a benefit to having some control over how we resolve conflicts that would normally occur from overlapping masks. The two solutions suggested above delegate this problem to the image stitcher, but we should consider whether the classifier performs better when run on the original images rather than the stitched images (because, for example, stitching creates blurred regions).

@aryarm
Copy link
Member Author

aryarm commented Sep 11, 2019

@mdonaldsonmatasci, what are your thoughts? Am I misunderstanding the problem in any way?

@mdonaldsonmatasci
Copy link
Member

This is a good summary of the problem. A couple notes: one is that the software we were using is not Microsoft Composite Image Editor but Agisoft Photoscan (much more powerful). The second is that there is another motivation that is missing, which is that the stitched map contains artifacts of stitching, e.g. blurriness, black holes. This is why breaking up the stitched image into smaller pieces wouldn't be as good a solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants