Repeated failed stitching

[Alexander Drecun]

Hey all,

New to Hugin to forgive me if the fix to this issue is simple or has been addressed elsewhere. I'm attempting to stitch a panorama made of around 110 images and each effort at stitching has failed, returning what appears to be an Enblend error. I keep getting the message despite the fact that I'm fairly sure all of my images overlap. 

enblend: warning: images do not overlap; they will be combined without blending

enblend: note: usually this means that at least one of these images does not

enblend: note: belong to the set or the order of the images given at the

enblend: note: command line is wrong; sometimes passing option

enblend: note: "--pre-assemble" resolves the problem; in rare cases using

enblend: note: option "--levels=NUMBER" to force blending with a certain

enblend: note: NUMBER of levels can help, too

At the end, PTBatcherGUI output the following: 

enblend: an exception occured
enblend:
Precondition violation!
separableConvolveX(): kernel longer than line

(/Users/max/Downloads/hugin-build-21/hugin-2021.0.0/mac/ExternalPrograms/repository/include/vigra/separableconvolution.hxx:1103)

enblend: info: remove invalid output image "_DSC0173 - _DSC0283.png"

I've also included a link to the entire status report and attached a screenshot of my settings under the Stitcher tab. 

https://docs.google.com/document/d/1T1mln6FnDopkVkxYVMZ5sQim7zRd3A3kMadRDeyQUC8/edit?usp=sharing

Can anyone tell me why this is happening and what I'm doing wrong?

Much appreciated,

Alex

[黄禄轩]

by default, enblend can only blend images with overlap one by one. so you have three options to try out: 1. reorder images in hugin to change the order of nona output, so each image enblend loaded will be overlapped with images already blended before. 2. manually execute enblend to blend image one by one, for examble enblend -o 2.tif img1.tif img2.tif, enblend -o 3.tif 2.tif img3.tif. 3. use image list file so enblend will blend image according to the order specified in list file. don't try --pre-assmeble, i have tried that option with 768 images, it may lead to bad result.

[T. Modes]

alexande...@gmail.com schrieb am Samstag, 17. September 2022 um 23:12:41 UTC+2:

Can anyone tell me why this is happening and what I'm doing wrong?

The main issue that the final output size is very small: only 377x21 pixel.

This is caused by a very strange choice of a rectilinear projection with a fov of 179 deg.

Either decrease the field of view if you want to maintain the rectilinear projection (and then recalculate crop).

But a better solution would be to change the output projection to something other than rectilinear (e.g. cylindrical or equirectangular) and then recalculate field of view and crop.

[黄禄轩]

and by the way, it seems that your project setup is incorrect. the filed of view or fov for short seems to be too large, you need to choose a correct fov first. then region of interest or roi for short to choose output region. roi shouldn't be too small compare to canvas. in the software roi refers to crop 

[Alexander Drecun]

Perhaps I should have specified that the panorama I'm attempting to stitch is sort of a mosaic-style one made up of images that I shot moving the camera along a flat plane. I was told that rectilinear is the appropriate projection setting for such images. When I change the projection to cylindrical or equirectangular, it produces significant bulging in the middle of the panorama with thin tails at the edges. The FOV of 179 degrees is what Hugin produces when I hit the "calculate field of view" button in the Stitcher tab. 

I'm also not sure why the output size was so small. That said, I've run into this same issue when attempting to output the panorama at "calculate optimal size," which is in the area of 4.5 gigapixels. 

This is what the Stitcher tab looks like when I select all of three of "calculate field of view," "calculate optimal size," and "fit crop to image."

Does this look right or is there an issue I'm missing?

I've also attached a screenshot of the panorama I'm attempting to stitch for reference.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/165607a0-a06b-471f-8ac0-9ac84c81bed4n%40googlegroups.com.

[黄禄轩]

i see. you indeed set a wrong fov for the project. if camera is slide from one side to the other side without any kind of rotation, fov should be zero. but you cannot put a zero into it, so a small number for example 0.5 is ok. i tried blend 768 images took with a microscope, and i used 0.5 for my project and it is working well.

[黄禄轩]

camera never rotated so FOV=0 degree.

[Alexander Drecun]

Where do I set the FOV for the project? Is that something done in the Projection tab in the Fast Panorama window or is that done in Stitcher? When I put 0.5 into FOV in the Fast Panorama window it just produces an impossibly thin crop of the panorama. 

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/f8f6d0bf-4573-435b-a138-ac39899b7885n%40googlegroups.com.

[黄禄轩]

so in my case, horizontal fov is 0.5, vertical fov is 0.5, and the 0.5x0.5 solid angle is projected to a 58000x58000 pixels plain, and i want the program output the area from (19000,4000) to (56000,50000) of the plain. you can manually adjust these parameters and check if it is ok in preview window. and by the way, a small fov should be set to each image too, like 0.02 in my case.

[johnfi...@gmail.com]

There is a correct fov for each image (assuming it was taken with a camera, rather than a scanner).

Giving it an incorrect low fov for each image can solve some problems.  But it does create other problems, so I don't think you should leap to that choice so quickly.

The fov of each image together with the way they connect gives you the field of view of the entire panorama.  So I don't think anything useful could be accomplished by setting the panorama fov low relative to the value accumulated from stitching.

I haven't read this thread carefully enough to be sure, but I think you are doing the optimize step without enabling translationX to be changed.  But in taking the photographs, translationX is the primary change.

I think you should use expert mode and redo the optimization (from a reset state) with just tx, ty and tx enabled (yaw, pitch and roll disabled).  Once that is approximately correct, optimize again from that stating point also enabling yaw, pitch, roll and maybe other parameters.

Once you have good parameters, to get a more realistic fit of control points, I'm not sure what to do with projection issues.  I expect you'll still have projection issues.  But I think the path forward will be easier once the tx values are reasonable.

[黄禄轩]

in theory, TrX, TrY and TrZ can solve the problem, but in my case sometime it goes wrong and i don't know why. so i think if image and the pano is both linear projection, use a small fov is ok.  sin(x) and tan(x) approach to x when x is small. and in other projection a small fov will cause the projection approach to linear projection.

[John Fine]

On Sun, Sep 18, 2022 at 12:50 PM 黄禄轩 <huanglux...@gmail.com> wrote:

in theory, TrX, TrY and TrZ can solve the problem, but in my case sometime it goes wrong and i don't know why.

Optimizing TrX together with Yaw, and starting from one of those very far from correct, tends to go wrong.

Photos taken with near zero yaw still have some yaw because you can't aim the camera perfectly (unless it is mounted on a track).  So you probably need to end up optimizing both TrX and Yaw.  But you should not try to optimize them together until they are each close to correct.

For a camera mosaic, 0.0 is close to correct for Yaw and not for TrX.  So optimize TrX with Yaw set to 0.0, then optimize them together starting from the result of that first optimization.

The same is generally true of pitch vs. TrY, so those should be done the same way.  But in the described linear sequence of pictures, there is less room for the pitch vs. TrY ambiguity to do much harm (might as well do pitch/TrY correctly since it is important to do Yaw vs. TrX correctly).  Roll and TrZ don't have similar ambiguity vs each other, but TrZ may need to be done at the same time as TrX for good results.  With a well distributed collection of control points, I think including Roll with TrX, TrY, TrZ initially might do better than adding it later.  But either way ought to work pretty well.  The one really important reason to optimize twice is to get TrX approximately correct before allowing nonzero Yaw.

[黄禄轩]

i think maybe it's some mathemagic problems, because when yaw is too small trx and yaw has equivalent contribution to the final result, just like enable both shear and rotation. but that means tons of trouble. and small fov can be a good replacement if both image and pano are linear projection.

[Alexander Drecun]

So I shot the image sequences with the camera attached to a handcart in a rigidly fixed position so there should be hardly any plane pitch or yaw. And for optimising, my process was the following:

- Optimize for TrX only, which produced an average unit distance under 1 (can't remember exact figures off the top of my head)

- Optimize for TrY and TrZ only, producing an average unit distance in the .4-5 range

- Optimize for yaw, pitch and roll at which point the unit distance was around .2

The resulting panorama looked great to my eyes but are these differences still to great?

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6490f7e6-67b3-4f91-b185-00b68ca2b393n%40googlegroups.com.

[johnfi...@gmail.com]

On Sunday, September 18, 2022 at 3:16:14 PM UTC-4 alexande...@gmail.com wrote:

So I shot the image sequences with the camera attached to a handcart in a rigidly fixed position so there should be hardly any plane pitch or yaw. And for optimising, my process was the following:

- Optimize for TrX only, which produced an average unit distance under 1 (can't remember exact figures off the top of my head)

- Optimize for TrY and TrZ only, producing an average unit distance in the .4-5 range

- Optimize for yaw, pitch and roll at which point the unit distance was around .2

The resulting panorama looked great to my eyes but are these differences still to great?

There is no simple scale for what values are good enough from optimize.  But typically, values under 0.5 are good.

Did you look individually at a few of the worst fitting control points?  How bad were they?  Was it really a locally bad optimize result or were the control points on non matching actual points?

When you find bad control points, it is usually worth the effort to fix or delete them and then rerun the optimize (you don't need to reoptimize from scratch.  Your current best fit is a good starting point).

If instead it is a locally bad fit, I next got to the final panorama and zoom in near the locally bad fit and try to spot the seam.  If you can find the seams by zooming in on the panorama, that is a defect that is likely worth fixing.  Looking great when you look at a whole panorama is usually not good enough (for me anyway).  It should look great even if you pan around a zoomed image looking for seams.

[Alexander Drecun]

Hmm ok, I'll go back and take a look. While I haven't gone through all 100 or so images in the panorama, I haven't seen any non-matching points in the control points I've looked at but I'll take a closer look.

I don't know the significance of this, but I have taken a panorama composed of jpegs and successfully stitched it into a tiff, but all of my efforts to compose the panorama with 16 bit tiffs and export/stitch as png have failed.

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/UD75PbXwS60/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/47e7f678-67c6-464e-8f5b-20f31d4b4e94n%40googlegroups.com.

[John Fine]

On Mon, Sep 19, 2022 at 3:45 PM Alexander Drecun <alexande...@gmail.com> wrote:

Hmm ok, I'll go back and take a look. While I haven't gone through all 100 or so images in the panorama, I haven't seen any non-matching points in the control points I've looked at but I'll take a closer look.

That sounds like you don't know about an important bit of Hugin's UI:

Click the view menu.

Select "Control point table"

If the Distance column is not already sorted with the largest first, click it once or twice until it is sorted largest first.

Click on any row of the table to jump to reviewing that control point within the control points tab.

It is thus quick and easy to review the worst fitting few control points.

[Alexander Drecun]

I'm aware of that function but thought it was exclusively comparative, i.e. you can look at the control points shared by two images and sort those control points by distance. I've done that with some of my images but admittedly I'm going to have to gird myself before sorting through the 4,000+ control points for over 100 images. Unless there's a way to look at the distance for all of those 4000 control points at once.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALe0Q_%3DyDMz7EOMVS%2BNMLDiv5NyptCV9h2%2BdU5j9E%2BvDCCQm3w%40mail.gmail.com.

[John Fine]

All at once is what the UI, I described, displays.

It is similar to the UI you know about for a pair of images, but generally more useful.

You don't need to sort through the connections between 100 images.

Try it and see.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CABqZK5dKq8OAuGFcTFm6WqwGX2FKWR1%2BS2qr7kFcB8iJr%2Buivw%40mail.gmail.com.

[Alexander Drecun]

So I'm not sure if anyone will circle back around to this conversation, but I'm hoping someone will have some insight into the issues I've run into recently. I was able to successfully stitch a rectilinear mosaic panorama out of twenty images using the following method: 

- Start with an image in the center of the mosaic anchored for position and exposure

- Add one image on either side of the anchored image

- Create control points

- Optimize in the following order

     - TrX

     - TrX + Yaw

     - TrY

     - TrY + Pitch

     - TrZ + Roll

     - Yaw + Pitch + Roll + TrX + TrY + Trz

- Add one more image on each end

- Create control points

- Optimize in same order

- Repeat until I've reached twenty images

- Calculate Field of View and adjust slightly to ensure that entire mosaic is visible

- Calculate Optimal Size 

- Panorama Output: exposure corrected, low dynamic range

- Format: PNG

The stitch was successful, but I received the following notes for almost image during the stitching process, and, at the end, "batch was completed with errors."

enblend: info: loading next image: Middle Out Strategy Test-341_4410095.tif 1/1
OMP: Info #270: omp_get_nested routine deprecated, please use omp_get_max_active_levels instead.
OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
enblend: info: loading next image: Middle Out Strategy Test-341_4410096.tif 1/1
enblend: warning: unable to run Dijkstra optimizer
enblend: note: seam-line end point outside of cost-image
enblend: note: contour #1 of 1, segment #1 of 1, vertex #36 of 489
OMP: Info #270: omp_get_nested routine deprecated, please use omp_get_max_active_levels instead.
OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.
OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead.

What's a little confusing, however, is that the exact same process results in a failed stitch once I try more than twenty images. It has failed at thirty, fifty and one hundred images, all while producing a log virtually identical to the stitches that succeeded.  The twenty image panorama had dimensions of 43,671 x 8,923, while the one hundred image panorama would have been 196,497 x 11,462.

First question, I guess, is, what do these notes mean? Second, how can I correct them?

For reference, I'm using the latest version for OSX, 2021.0.0.

Thanks,

Alex

[Luís Henrique Camargo Quiroz]

    Hi Alex,

    The OMP messages have nothing to do with your images nor the way you try to stitch them, for sure. They are related to OpenMP, a library for parallel processing in the CPU (and also GPU) cores. They show us that the program (enblend, in this case) needs some code updates because OpenMP evolved and the program uses some function calls that are now obsolete.

    About the Dijkstra optimizer and seam-line end point outside of cost-image, I sometimes -- I think less than before, maybe I perfected my shooting technique? -- get them. When that happens, enblend may fail and the output image is automatically erased... In this case, use of masks or another order of the photos may help to reach a successful stitching.

   I have not yet stitched any true mosaic, however I use mosaic mode for my nadir images and in this case it works very well.

   Good luck!

   Luís Henrique

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/ef7186f1-1f52-4634-90d8-99637df41818n%40googlegroups.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[John Fine]

On Sat, Nov 5, 2022 at 7:25 PM Alexander Drecun <alexande...@gmail.com> wrote:

enblend: warning: unable to run Dijkstra optimizer
enblend: note: seam-line end point outside of cost-image

I'm not sure I'm remembering correctly.  If I am, this might help:

I have had a lot of problems similar to that.  I think they occured in panoramas with ragged edges.

When I had not taken photos far enough beyond what I actually wanted, I had the problem that assembly of the panorama would tilt the outside edges of individual photos (not parallel to the panorama edge) so I had to either clip to exclude some of the content I wanted, or clip wider to include some empty space (make the edge of the final panorama ragged).  The latter had the extra problem that I think matches what you described.

I think you can avoid it by clipping tighter.

[Alexander Drecun]

What is the cost-image? I'm wondering if both of you may, in one way or another, be pointing to the issue giving me problems. I was attempting to export stitches that were uncropped - that is to say, all of the edges of the panorama being visible - so that I could make decisions about cropping later, once I'd straightened the mosaic in a photo editing software like Gimp, but maybe doing that has been creating issues. I say that in part because some of the successful stitches I've made recently have come using Hugin in "simple" mode with a crop automatically applied.

Out of curiosity, have any of you had greater or less success depending on the file type you've used? I've experienced almost no success working with tiffs and pngs created off of the original raw files via Lightroom, but I'm getting more successful stitches with jpegs off of those same raw files. I should clarify that these successes and failures are coming while running tests on the same image set, DSC0175-DSC0235, just tiff vs png vs jpeg. 

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/UD75PbXwS60/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALe0Q_nEJ%2BTUc_oXmsAWnneUL3TpFya8FH8QGUn7-cEm8%2Bb1sA%40mail.gmail.com.

[David W. Jones]

Just to chime in here...

I don't know what "cost-image" means. I get it often, yet it doesn't cause any problems.

I almost always do my crop in Hugin. I generally use autoclip, then adjust boundaries as I needed to remove extraneous bits. Sometimes I don't clip the panorama in Hugin, but it still works without problems.

I always use 48-bit TIFF (16-bit per channel) from RawTherapee.

I suspect the issues are coming from control points and position calculation. If you're using the panorama assistant, it does a lot of cleanup on control points that you're maybe not going manually?

My process (using the Expert Interface):

1. Load images.
2. Go to control points tab and go through the images setting horizontal lines (if needed).
3. On Photos tab, run CPFind, then Positions (incremental).
4. Right-click in a blank area of the list of images and clean control points.
5. Repeat steps 3 and 4, but using the next Geometric option down.
6. After running the "Everything except translation" option and cleaning control points, view the panorama using Preview Panorama (OpenGL). Use Move/Drag and Projection to center and fit it.
7. Use Crop to autocrop it.
8. Drag crop borders to adjust. Close the Preview Panorama window.
9. On the Photos tab, calculate the Photometric optimization.
   
10. On the Stitcher tab, calculate optimal size, save the PTO, and stitch.

I think cleaning the control points is what makes the difference for me.

I've also sometimes seen Hugin misread the focal length on an image. When that happens, I get weird results, and my process eventually hits a point where Hugin says that calculated values are invalid. But you would see that before getting to the actual stitching stage.

Helpful?

On 11/7/22 06:31, Alexander Drecun wrote:

What is the cost-image? I'm wondering if both of you may, in one way or another, be pointing to the issue giving me problems. I was attempting to export stitches that were uncropped - that is to say, all of the edges of the panorama being visible - so that I could make decisions about cropping later, once I'd straightened the mosaic in a photo editing software like Gimp, but maybe doing that has been creating issues. I say that in part because some of the successful stitches I've made recently have come using Hugin in "simple" mode with a crop automatically applied.

Out of curiosity, have any of you had greater or less success depending on the file type you've used? I've experienced almost no success working with tiffs and pngs created off of the original raw files via Lightroom, but I'm getting more successful stitches with jpegs off of those same raw files. I should clarify that these successes and failures are coming while running tests on the same image set, DSC0175-DSC0235, just tiff vs png vs jpeg. 

On Mon, Nov 7, 2022 at 6:03 AM John Fine <johnfi...@gmail.com> wrote:

On Sat, Nov 5, 2022 at 7:25 PM Alexander Drecun <alexande...@gmail.com> wrote:

enblend: warning: unable to run Dijkstra optimizer
enblend: note: seam-line end point outside of cost-image

I'm not sure I'm remembering correctly.  If I am, this might help:

I have had a lot of problems similar to that.  I think they occured in panoramas with ragged edges.

When I had not taken photos far enough beyond what I actually wanted, I had the problem that assembly of the panorama would tilt the outside edges of individual photos (not parallel to the panorama edge) so I had to either clip to exclude some of the content I wanted, or clip wider to include some empty space (make the edge of the final panorama ragged).  The latter had the extra problem that I think matches what you described.

I think you can avoid it by clipping tighter.

-- 
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.