getting strange blending errors for a very wide panorama
37 views
Skip to first unread message
kevin360
Apr 9, 2009, 8:09:32 PM4/9/09
to hugin and other free panoramic software
I have a large panorama (104,014 x 20,504) that when I stitch it
together I get these strange white vertical cloud marks going the
length of the panorama. I've found that if I crop the panorama so
it's not as wide then I don't get these marks. You can see what I'm
talking about here:
http://www.bluelavalamp.net/enblend_comparison.jpg
(file is about 37K)
I'm using the same .pto file for both stitches, the only difference is
I change the "right" crop value in the "Sticher" tab. The top version
I set the right crop to be 95,000 which results in an image that's
94,797x14,325 in size. The bottom version I set the right crop to be
80,000 which results in an image that's 79,797x14,325 in size. (For
both there is a left crop set at 203.) But that's the only difference
between the two and in one I get the cloud marks, in the other I
don't.
I've also tried stitching a shrunk version of the entire image that's
only 40,000 wide and it comes out completely fine.
Here's info on what I'm running:
Slamd64 12.2 updated to -current
Hugin svn revision 3778
enblend - the CVS version from this past weekend.
Has anyone done a really wide panorama before and not had problems
like this?
Thanks,
Kevin
together I get these strange white vertical cloud marks going the
length of the panorama. I've found that if I crop the panorama so
it's not as wide then I don't get these marks. You can see what I'm
talking about here:
http://www.bluelavalamp.net/enblend_comparison.jpg
(file is about 37K)
I'm using the same .pto file for both stitches, the only difference is
I change the "right" crop value in the "Sticher" tab. The top version
I set the right crop to be 95,000 which results in an image that's
94,797x14,325 in size. The bottom version I set the right crop to be
80,000 which results in an image that's 79,797x14,325 in size. (For
both there is a left crop set at 203.) But that's the only difference
between the two and in one I get the cloud marks, in the other I
don't.
I've also tried stitching a shrunk version of the entire image that's
only 40,000 wide and it comes out completely fine.
Here's info on what I'm running:
Slamd64 12.2 updated to -current
Hugin svn revision 3778
enblend - the CVS version from this past weekend.
Has anyone done a really wide panorama before and not had problems
like this?
Thanks,
Kevin
Lukáš Jirkovský
Apr 10, 2009, 2:45:24 AM4/10/09
to hugi...@googlegroups.com
2009/4/10 kevin360 <kevi...@yahoo.com>:
Hi Kevin,
This is most likely caused by photometric optimization (to be exact by
vignetting). The easiest way how how to fix the original not-cropped
panorama is probably by removing the results of vignetting
optimization. How to do it? Just open the panorama, go to the Camera
and Lens tab, select all photos and under the Photometric tab (it's
down on the screen) set all values under the Vignetting and Vignetting
center shift to zero. Final stitch should look OK then.
Lukáš
This is most likely caused by photometric optimization (to be exact by
vignetting). The easiest way how how to fix the original not-cropped
panorama is probably by removing the results of vignetting
optimization. How to do it? Just open the panorama, go to the Camera
and Lens tab, select all photos and under the Photometric tab (it's
down on the screen) set all values under the Vignetting and Vignetting
center shift to zero. Final stitch should look OK then.
Lukáš
kevin360
Apr 10, 2009, 6:17:51 AM4/10/09
to hugin and other free panoramic software
On Apr 10, 2:45 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> Hi Kevin,
> This is most likely caused by photometric optimization (to be exact by
> vignetting). The easiest way how how to fix the original not-cropped
> panorama is probably by removing the results of vignetting
> optimization. How to do it? Just open the panorama, go to the Camera
> and Lens tab, select all photos and under the Photometric tab (it's
> down on the screen) set all values under the Vignetting and Vignetting
> center shift to zero. Final stitch should look OK then.
>
> Lukáš
Shift to zero
and started up the stitch. I'll let you know the result in 8-9 hours,
that's how
long it takes to stitch!
I'll admit, I'm not sure I understand why that will make a difference.
I understand vignetting and I could see if I was stitching at a
smaller size
then the full size of the panorama. But here both are being stitched
at the
full size, the Field of View (208x41) and the Panorama Canvas Size
(104,014x20,504) I'm not changing, they are the same for both
stitches.
The only difference is how big of a piece of the full size I'm
stitching by
adjusting the Right Crop.
I guess what I don't quite understand is, if I have a panorama that's
4 images
wide by 1 image high and the Photometric Optimization was causing
these
cloud features. Wouldn't I still see these cloud features if I
decided to only
stitch together 3 of the images instead of 4?
kevin360
Apr 10, 2009, 4:25:52 PM4/10/09
to hugin and other free panoramic software
It finished stitching and the same result. Here it is:
http://www.bluelavalamp.net/enblend_comparison_2.jpg
The top and middle are the ones from before (see first message in
thread). The last image is the same .pto file as the first, but with
the Photometric Optimizations all set to zero, so that's not causing
this problem.
Have people been able to stitch very wide panoramas before, one that's
over 95,000 pixels wide? If they have, then it's gotta be something
on my end, maybe I'm using an older library or something.
http://www.bluelavalamp.net/enblend_comparison_2.jpg
The top and middle are the ones from before (see first message in
thread). The last image is the same .pto file as the first, but with
the Photometric Optimizations all set to zero, so that's not causing
this problem.
Have people been able to stitch very wide panoramas before, one that's
over 95,000 pixels wide? If they have, then it's gotta be something
on my end, maybe I'm using an older library or something.
Lukáš Jirkovský
Apr 12, 2009, 4:02:12 AM4/12/09
to hugi...@googlegroups.com
2009/4/10 kevin360 <kevi...@yahoo.com>:
>
> It finished stitching and the same result. Here it is:
>
> http://www.bluelavalamp.net/enblend_comparison_2.jpg
>
> The top and middle are the ones from before (see first message in
> thread). The last image is the same .pto file as the first, but with
> the Photometric Optimizations all set to zero, so that's not causing
> this problem.
>
> It finished stitching and the same result. Here it is:
>
> http://www.bluelavalamp.net/enblend_comparison_2.jpg
>
> The top and middle are the ones from before (see first message in
> thread). The last image is the same .pto file as the first, but with
> the Photometric Optimizations all set to zero, so that's not causing
> this problem.
Thats strange. Unfortunately I've no idea what else can cause this.
> Have people been able to stitch very wide panoramas before, one that's
> over 95,000 pixels wide?
AFAIK there are people which used hugin for very large panoramas
(several Gigapixels). But you can try to resize input images to a
smaller scale. I know that it's not clear way how to get rid of this
problem, but if it helps we will know where the problems is and maybe
we would be able to fix it.
> If they have, then it's gotta be something
> on my end, maybe I'm using an older library or something.
I'm not sure about this. Libraries which are used for work with images
(optimization etc.) are bundled within hugin source.
Lukáš
Bart.van.Andel
Apr 12, 2009, 8:26:56 AM4/12/09
to hugin and other free panoramic software
Looks to me like Enblend causes the trouble. Most obvious in the sky,
the artifacts seem to be caused by a low frequency blending error
(which explains the wide bands). The errors should not be visible in
the intermediate files generated by Hugin during the process, could
you confirm this? You could try using Smartblend instead of Enblend,
just make sure you set the options right before you do, otherwise
you'll be waiting 6-8 hours ending up with an error and no final
output. Of course you could also have Hugin keep the intermediate
files and perform the last step (the final blending) manually, so you
can try different options without having to recompute the intermediate
images every time.
Besides, I'm wondering if the resolution you chose for the output
really makes sense. As far as I can see from the output, there are
only two series of images overlapping vertically about 50 percent
(except for the obelisk), spanning about half of the final image.
Unless the vertical resolution of the images is about 10,000 real
pixels, this is nonsense. And remember, a 12MP point-and-shoot camera
may deliver 4000x3000 pixels, but at 100% zoom you can see that it
does not really contain that much detail / information.
the artifacts seem to be caused by a low frequency blending error
(which explains the wide bands). The errors should not be visible in
the intermediate files generated by Hugin during the process, could
you confirm this? You could try using Smartblend instead of Enblend,
just make sure you set the options right before you do, otherwise
you'll be waiting 6-8 hours ending up with an error and no final
output. Of course you could also have Hugin keep the intermediate
files and perform the last step (the final blending) manually, so you
can try different options without having to recompute the intermediate
images every time.
Besides, I'm wondering if the resolution you chose for the output
really makes sense. As far as I can see from the output, there are
only two series of images overlapping vertically about 50 percent
(except for the obelisk), spanning about half of the final image.
Unless the vertical resolution of the images is about 10,000 real
pixels, this is nonsense. And remember, a 12MP point-and-shoot camera
may deliver 4000x3000 pixels, but at 100% zoom you can see that it
does not really contain that much detail / information.
kevin360
Apr 12, 2009, 10:46:03 AM4/12/09
to hugin and other free panoramic software
I agree, it's looking like it's an Enblend error that's causing the
problems.
The intermediate files are clean, they don't show the errors at all.
As for
Smartblend, it only runs under windows from what I can tell and don't
have a windows box, so I can't check to see if it would fix the
problem.
I did try another test. I was thinking that maybe the problem is the
fact
that the stitch is so wide, so I took another pano I have with only
maybe 8
images and changed the output size to be 95000x14000 to see what would
result. That came out corect, no ghosting problems. So not sure if
it's the
number of images, the resolution, or some combo in between.
As for the output resolution, it is correct. The camera used is a
Canon 50D,
so the images are 3168x4752. The pano contains 112 images, mostly
contained
in a two row setup (the obelisk as you said adding a couple more
images to the
height). It's either 54 or 55 images for each row in the horizontal
direction.
problems.
The intermediate files are clean, they don't show the errors at all.
As for
Smartblend, it only runs under windows from what I can tell and don't
have a windows box, so I can't check to see if it would fix the
problem.
I did try another test. I was thinking that maybe the problem is the
fact
that the stitch is so wide, so I took another pano I have with only
maybe 8
images and changed the output size to be 95000x14000 to see what would
result. That came out corect, no ghosting problems. So not sure if
it's the
number of images, the resolution, or some combo in between.
As for the output resolution, it is correct. The camera used is a
Canon 50D,
so the images are 3168x4752. The pano contains 112 images, mostly
contained
in a two row setup (the obelisk as you said adding a couple more
images to the
height). It's either 54 or 55 images for each row in the horizontal
direction.
Bart.van.Andel
Apr 12, 2009, 1:45:33 PM4/12/09
to hugin and other free panoramic software
> I agree, it's looking like it's an Enblend error that's causing the
> problems.
> The intermediate files are clean, they don't show the errors at all.
That's great, so it's not Hugin itself. Now the next step is to find
> problems.
> The intermediate files are clean, they don't show the errors at all.
out what causes the trouble (not purely the resolution, as your other
test proved).
> As for
> Smartblend, it only runs under windows from what I can tell and don't
> have a windows box, so I can't check to see if it would fix the
> problem.
this thread:
http://groups.google.com/group/hugin-ptx/browse_thread/thread/b11d91ad0280ace0
I haven't tried it (I'm using Windows myself), but if you succeed, I'd
love to see the result!
> As for the output resolution, it is correct. The camera used is a
> Canon 50D,
> so the images are 3168x4752. The pano contains 112 images, mostly
> contained
> in a two row setup (the obelisk as you said adding a couple more
> images to the
> height). It's either 54 or 55 images for each row in the horizontal
> direction.
drawn on paper... Sorry!
Best,
Bart
Kunlun121
May 23, 2009, 5:51:37 AM5/23/09
to hugin and other free panoramic software
Hello,
I'd like to contribute to this thread. Today I ran into the same
problem with Enblend (see my problem here: http://idisk.mac.com/jannesbolten-Public?view=web).
Also a cloud blending problem in a large panorama. I will today try
Kevin's solution of setting the crop parameters to see if it works for
me too. Thanks for that workaround.
However, I believe the cause is with Hugin, not enblend. I have
stitched and blended the exact same panorama many times before (even
over the years) with both PTGui and Hugin, always using different
versions of Enblend to create the final result and this never
happened. Even as recently as January or February of this year it came
out great with Hugin/Enblend OSX binaries that I downloaded from Harry
van der Wolf's site.
The first time I noticed the problem was 2 days ago on a version that
I have now deleted. Because I couldn't open that image due to a bug in
libtiff, I only looked at the preview in finder. The preview clearly
showed that the blending had gone badly wrong. That tiff I blended
"manually", ie from the terminal. I blended it row by row (4
horizontal rows of approx. 11 images each) and then blended first the
bottom 2 rows together, and then the top two rows. The last step was
blending the final pano. As far as I could see from the preview
thumbnails, all blend steps had gone fine, except for the last one:
there was a very visible bright seam running horizontally in the lower
portion of the clouds through the middle of my pano. In stitching this
pano, I had for the first time fiddled with the Exposure tab's
settings. (It was even the first time I noticed it; was it there
before? As I come from using PTGui, I wasn't used to having this tab.)
Now the entire upper half of the pano has no control points. I placed
the images manually, because the clouds had moved. With this
particular pano I never had any problems doing this. Enblend tends to
take care of any irregularities. Because the problem initially was
between the bottom and top part of the pano, I immediately thought the
lack of control points in the sky had caused the Exposure Optimizer to
mess up. Can it be that the exposure tab doesn't work well between
images that have no control points?
The current version (as uploaded to my idisk) shows a completely
different pattern of failure. It looks much more like Kevin's problem.
I have running 0.8.0 RC1-dmalloc with a version of Enblend that's
modified by Harry to circumvent the Libtiff bug for 2+GB images (but
my problem also showed when using the "stock" Enblend version that
part of Hugin as available at Harry's site).
Has a solution been found yet? Is there anything I can do to help find
a solution?
I'm currently blending the same panorama as the one uploaded but now
manually, row-by-row. Will post the result as my computer's done
churning it out. Looking forward to hear if progress has been made
tho.
Jannes
I'd like to contribute to this thread. Today I ran into the same
problem with Enblend (see my problem here: http://idisk.mac.com/jannesbolten-Public?view=web).
Also a cloud blending problem in a large panorama. I will today try
Kevin's solution of setting the crop parameters to see if it works for
me too. Thanks for that workaround.
However, I believe the cause is with Hugin, not enblend. I have
stitched and blended the exact same panorama many times before (even
over the years) with both PTGui and Hugin, always using different
versions of Enblend to create the final result and this never
happened. Even as recently as January or February of this year it came
out great with Hugin/Enblend OSX binaries that I downloaded from Harry
van der Wolf's site.
The first time I noticed the problem was 2 days ago on a version that
I have now deleted. Because I couldn't open that image due to a bug in
libtiff, I only looked at the preview in finder. The preview clearly
showed that the blending had gone badly wrong. That tiff I blended
"manually", ie from the terminal. I blended it row by row (4
horizontal rows of approx. 11 images each) and then blended first the
bottom 2 rows together, and then the top two rows. The last step was
blending the final pano. As far as I could see from the preview
thumbnails, all blend steps had gone fine, except for the last one:
there was a very visible bright seam running horizontally in the lower
portion of the clouds through the middle of my pano. In stitching this
pano, I had for the first time fiddled with the Exposure tab's
settings. (It was even the first time I noticed it; was it there
before? As I come from using PTGui, I wasn't used to having this tab.)
Now the entire upper half of the pano has no control points. I placed
the images manually, because the clouds had moved. With this
particular pano I never had any problems doing this. Enblend tends to
take care of any irregularities. Because the problem initially was
between the bottom and top part of the pano, I immediately thought the
lack of control points in the sky had caused the Exposure Optimizer to
mess up. Can it be that the exposure tab doesn't work well between
images that have no control points?
The current version (as uploaded to my idisk) shows a completely
different pattern of failure. It looks much more like Kevin's problem.
I have running 0.8.0 RC1-dmalloc with a version of Enblend that's
modified by Harry to circumvent the Libtiff bug for 2+GB images (but
my problem also showed when using the "stock" Enblend version that
part of Hugin as available at Harry's site).
Has a solution been found yet? Is there anything I can do to help find
a solution?
I'm currently blending the same panorama as the one uploaded but now
manually, row-by-row. Will post the result as my computer's done
churning it out. Looking forward to hear if progress has been made
tho.
Jannes
Kunlun121
May 23, 2009, 6:29:33 AM5/23/09
to hugin and other free panoramic software
Enblend shows the same weird patters in the first row of clouds of my
pano. I just noticed while Enblend is working on the top row of my
panorama (10 images, all clouds) that it's "optimizing for 59 distinct
seams". It should be optimizing for only 9 seams between 10 images, no?
pano. I just noticed while Enblend is working on the top row of my
panorama (10 images, all clouds) that it's "optimizing for 59 distinct
seams". It should be optimizing for only 9 seams between 10 images, no?
Kunlun121
May 23, 2009, 7:02:04 AM5/23/09
to hugin and other free panoramic software
Please see here: http://gallery.me.com/jannesbolten#100166 for the
results of row-by-row blending. (choose slideshow for highest
resolution view.) Only one row seems to offend Enblend. The only
difference between this row and the others, is that it has a single
picture that is connected to the row below it by control points (it's
the image that has the tips of the 2 towers in it). The rest of the
images were added manually without any CPs. This makes me speculate
further that the issue is with Hugin somehow.
Will try next by setting the crop offsets in Hugin.
results of row-by-row blending. (choose slideshow for highest
resolution view.) Only one row seems to offend Enblend. The only
difference between this row and the others, is that it has a single
picture that is connected to the row below it by control points (it's
the image that has the tips of the 2 towers in it). The rest of the
images were added manually without any CPs. This makes me speculate
further that the issue is with Hugin somehow.
Will try next by setting the crop offsets in Hugin.
Bruno Postle
May 26, 2009, 6:15:12 PM5/26/09
to Hugin ptx
On Sat 23-May-2009 at 02:51 -0700, Kunlun121 wrote:
>
>However, I believe the cause is with Hugin, not enblend. I have
>stitched and blended the exact same panorama many times before (even
>over the years) with both PTGui and Hugin, always using different
>versions of Enblend to create the final result and this never
>happened.
>
>However, I believe the cause is with Hugin, not enblend. I have
>stitched and blended the exact same panorama many times before (even
>over the years) with both PTGui and Hugin, always using different
>versions of Enblend to create the final result and this never
>happened.
The way to tell if it is a hugin or enblend problem is to enable
Remapped images in the Stitcher tab. If the remapped images don't
display the problem then it is a bug in the enblend you are using.
--
Bruno
Harry van der Wolf
May 27, 2009, 1:51:35 AM5/27/09
to hugi...@googlegroups.com
It is an enblend problem. In the past week we tested a lot of enblend versions starting with the svn3176 version (which is an enblend "3.1" version) from my website. This svn3176 version is actually an incorrect name as it was a load of hugin tools and enblend/enfuse at the time of Hugin svn3176.
Kunlun121 tested, I made enblend builds.
The "3.1" version is the only one not having this issue. All 3.2 and newer versions (both from Andrew Mihal and from Christoph Spiel) have this same issue and apparently on multiple OSes.
Kunlun121already filed a bug on enblend.sourceforge.net. I will expand the bug report.
Another observation is that older enblend use/calculate the number of seams "equal" to the number of images. Newer versions create/calculate lots of seams. This might actually be the problem: that lots and lots of "false" seams are created, resulting in these weird seams in the final result.
Harry
Kunlun121 tested, I made enblend builds.
The "3.1" version is the only one not having this issue. All 3.2 and newer versions (both from Andrew Mihal and from Christoph Spiel) have this same issue and apparently on multiple OSes.
Kunlun121already filed a bug on enblend.sourceforge.net. I will expand the bug report.
Another observation is that older enblend use/calculate the number of seams "equal" to the number of images. Newer versions create/calculate lots of seams. This might actually be the problem: that lots and lots of "false" seams are created, resulting in these weird seams in the final result.
Harry
2009/5/27 Bruno Postle <br...@postle.net>
Reply all
Reply to author
Forward
0 new messages