In my case, my dad needed a Gui for stitching microscope images and he told me that none of the panorama stitching Guis were working for him.

I found out that the out of the box opencv Stitcher [1] class is perfect for that but nobody seems to have made a GUI out of it.

So, I've spent two days making an extremely simple proof of concept of a Qt Gui [2].

The majority of the time was spent trying to use GitHub Action to automatically build an executable...

If you go see in the release section, there is a tag with a prebuilt binary.

[1]: https://docs.opencv.org/4.x/d8/d19/tutorial_stitcher.html

[2]: https://github.com/kwon-young/ImageStitcher

Just a suggestion, maybe create a new repo that is not a fork from a template. Just copy the files in, and then create a simple README that explains what it is and how to run it.

So Github still doesn't have an unfork button.. but they can unfork the repo using a virtual assistant https://stackoverflow.com/questions/38831301/how-to-un-fork-... .. I don't get why the regular UI can't do this

Anyway in some language ecosystems there are cli tools that make repositories from templates, and a benefit is that it prevents people from forking the template (which is appropriate if you are modifying the template like upgrading dependencies etc, but not if you are just making a new project using it)

That is a really handy tip. It is so easy to quickly fork a template forgetting that is is not the intended use case.

For microscopy images, have you tried ashlar?

https://github.com/labsyspharm/ashlar

It may help to have the microscope stage positions available in the OME metadata.

I did not know of this project. I suppose it did not come up in my research sinve I was looking for simple Guis that my dad could use.

His setup only has a simple microscope camera that can stream a video to an old windows xp pc with a hardware/software combination...

I'd love someone with more CV experience to explain why this fails on my use case?

(four image zip) https://drive.google.com/file/d/1gTZWlKmS4ZtEZDK8OjjLeGN_V0F...

A panorama is built by stitching together many images taken from the same viewpoint.

The 1st critical thing you need to know, is that the camera may not move. It may only rotate. If the camera moves a tiny bit, that's generally OK, but there will be stitching artifacts. To be really precise, the entrance pupil of the camera shouldn't move, but this is quite hard to get right.

The 2nd thing, is that the stitching algorithms need to match images to each other, and in order to do this, the images must have large overlapping portions. This usually means that if you want to create a 360 degree panorama where you spin your camera all the way around, you'll have at least about 12 images. The minimum number of images depends on how wide your lens is.

This is a great overview of panoramas: http://6.869.csail.mit.edu/fa17/lecture/lecture14sift_homogr...

One more thing: It really helps to apply lens correction to your camera images, if you're trying to create a high quality panorama.

Nice explanation

(sorry don't have time to run through the OP script and check what you're getting for outputs, but...)

- I'm not even entirely sure how these images would stitch together

- between 1.jpeg and the rest, there is very little overlap. RANSAC likely won't find matchable points.

- you're asking for a pretty severe homography of the scene.

Thanks! That's what I was trying to understand.

Panorama Stitcher (macOS) matched 3 and 4 to give https://imgur.com/a/HnagrrH but image 2 is just too skewed to match, even after rotating in Photoshop, and image 1 is just wonky re: 4 and difficult to orient for a match.

Is there a way to get it to report progress while it's working? It's been running for 30 minutes and I can't tell if it's doing anything. There's been no output since it reported the files it was combining.

Wondering if anyone has examples/ideas for how to do this with video? I have two cameras (GoPro) that I use to record athletic games on a 20ft tall tripod, and I want to automatically stitch them together for easier analysis of games. I think I can use a tool like this to find the stitching parameters for the first frame and then apply it to all future frames, assuming the camera doesn't move?

Yes, this would definitely work, so long as the two cameras have sufficient overlap. If you were to use OpenCV's stitching code, then you could run the first few phases of that on your initial photo pair, which determine the camera angles, and then save those angles.

Then, for every video frame, you could skip the photo angle computation, and just run the imagine stitching logic. The stitching_detail code is very readable, and quite easy to hack for experimentation.

Would be nice to include some sort of performance benchmarks that compare it to the alternatives.

what do you think should be the alternatives it should be compared to?

Depends on what the package is supposed to be used for.

If its meant for photographers to create panoramas, then I think a comparison to: Photoshop, Hugin (or PTGUI for gpu acceleration), and Microsoft ICE would be a good benchmark.

Perhaps hugin

How is this compared with Microsoft ICE?

Microsoft seems to have discontinued ICE a long time ago. As far as I know, the state of the art in panorama stitching is PTGui.

I was working on mobile panorama stitching last year, and one of my datasets had a kitchen wall that was almost purely white, so very little detail for the classic feature algorithms such as SIFT and ORB to cling to. The OpenCV stitching pipeline, which is built on these (and RANSAC), didn't do very well when matching these walls.

But PTGui was amazing on this data - it would find just a tiny number of very high quality feature points to match (eg 3 or 4), and produce a perfect panorama. In addition, it's really fast. I was very impressed.

True, but ICE is free while PT GUI is 150€.

And compared to the open source darling Hugin it has also a less fussy UI.

Hugin hasn't worked for me on macos well for a couple of years.

I never got it work with my images. (Flatbed mosaic.)

The fussy UI is nothing. The real benefit is the gpu acceleration. That alone is worth the money.

A simple GUI would be great to let the user select high quality 3-4 matches (reference points) between the image pairs. Then the rest of the stitching pipeline could stay the same.

I'm convinced after the work I did on panoramas that one shouldn't need to involve user input. Maybe for very strange situations... but generally it shouldn't be necessary. This is especially true if you have access to the IMU on a phone, which helps constrain the potential angles of each of your images.

If your images are just a random bag of jpegs that came in from the cold, then it's harder for sure.

So how did you solve the mobile panorama stitching? You ran PTGui on a backend server and uploaded the user images there?

I started from the OpenCV stitching_detailed example, and worked from there. That example runs pretty much out of the box on Android.

Cool, thanks!