multiblend - black areas in output

186 views
Skip to first unread message

kevin360

unread,
Apr 27, 2012, 12:26:13 PM4/27/12
to hugin and other free panoramic software
I'm getting some black splotches in the output from multiblend. The
stitch is a 7 bracket stitch and I'm sending multiblend 13 images that
are all of the same exposure.

http://www.bluelavalamp.net/hugin/multiblend-spots/multi-pano_exposure_0006-small.tif

full size version here (194meg):

http://www.bluelavalamp.net/hugin/multiblend-spots/multi-pano_exposure_0006.tif


multiblend is version 0.31beta


output from enblend looks like this (small version):

http://www.bluelavalamp.net/hugin/multiblend-spots/psm-nft-pano_exposure_0006-small.jpg

full size version (177meg):
http://www.bluelavalamp.net/hugin/multiblend-spots/psm-nft-pano_exposure_0006.tif


here's the commandline I used for multiblend:

multiblend -a -v -f10803x12963+3318+1589 -o multi-
pano_exposure_0006.tif -- pano_exposure_layers_0006.tif
pano_exposure_layers_0013.tif pano_exposure_layers_0020.tif
pano_exposure_layers_0027.tif pano_exposure_layers_0034.tif
pano_exposure_layers_0041.tif pano_exposure_layers_0048.tif
pano_exposure_layers_0055.tif pano_exposure_layers_0062.tif
pano_exposure_layers_0069.tif pano_exposure_layers_0076.tif
pano_exposure_layers_0083.tif pano_exposure_layers_0090.tif



Which was the enblend commandline and I just changed it to
multiblend. Any ideas what might be causing these black marks in the
stitch?

Monkey

unread,
Apr 27, 2012, 6:23:15 PM4/27/12
to hugi...@googlegroups.com
I'm a little mystified by this - if you scale down the input images (like, to easily uploadable/downloadable size ;) ) does the problem still occur? If so could you upload the input images somewhere?

Does multiblend give any warnings about images being overlapped, or areas being arbitrarily assigned?

kevin360

unread,
Apr 27, 2012, 10:34:19 PM4/27/12
to hugin and other free panoramic software
Ok, have a zip file:

http://www.bluelavalamp.net/hugin/multiblend-spots/multiblend-test.zip

it's 1.7meg in size. It has two input images (1.jpg & 2.jpg) that
were shrunk to 25% of the original. It has a pto file that I made
using hugin. The pto.mk file is included that I edited to change from
enblend to multiblend, this file was originally created by hugin when
I saved the .pto file. And it has the output stitch (1-2.jpg) which
has been converted to jpg from tif using ImageMagick. The tif version
looks the same, just converted to make it much smaller.

I did not include, but when I stitch the images with enblend the
result looks fine.


On Apr 27, 6:23 pm, Monkey <davidhorma...@gmail.com> wrote:
> I'm a little mystified by this - if you scale down the input images (like,
> to easily uploadable/downloadable size ;) ) does the problem still occur?
> If so could you upload the input images somewhere?
>
> Does multiblend give any warnings about images being overlapped, or areas
> being arbitrarily assigned?
>
>
>
>
>
>
>
> On Friday, April 27, 2012 5:26:13 PM UTC+1, kevin360 wrote:
>
> > I'm getting some black splotches in the output from multiblend.  The
> > stitch is a 7 bracket stitch and I'm sending multiblend 13 images that
> > are all of the same exposure.
>
> >http://www.bluelavalamp.net/hugin/multiblend-spots/multi-pano_exposur...
>
> > full size version here (194meg):
>
> >http://www.bluelavalamp.net/hugin/multiblend-spots/multi-pano_exposur...
>
> > multiblend is version 0.31beta
>
> > output from enblend looks like this (small version):
>
> >http://www.bluelavalamp.net/hugin/multiblend-spots/psm-nft-pano_expos...
>
> > full size version (177meg):
>
> >http://www.bluelavalamp.net/hugin/multiblend-spots/psm-nft-pano_expos...

kevin360

unread,
Apr 27, 2012, 10:38:09 PM4/27/12
to hugin and other free panoramic software
Forgot to include the output of multiblend. Here's the output when
stitching:

make -f 1-2.pto.mk
===========================================================================
Stitching panorama
===========================================================================
/usr/local/bin/multiblend --compression=LZW -a -v -f2946x2506+40+23 -o
1-2.tif -- 1-20000.tif 1-20001.tif

multiblend v0.31beta (c) 2012 David Horman
------------------------------------------

ignoring enblend option -a
ignoring enblend option -f
loading 1-20000.tif...
loading 1-20001.tif...
2946x2506, 8bpp, 10 levels
split done
seaming...
masks...
blending...
writing 1-2.tif...

exiftool -E -overwrite_original_in_place -TagsFromFile /root/wd/photos/
ssd/dc_night_3_29_2012/museum/error_tests/1.jpg -ImageDescription -
Make -Model -Artist -WhitePoint -Copyright -GPS:all -DateTimeOriginal -
CreateDate -UserComment -ColorSpace -OwnerName -SerialNumber '-
Software=Hugin Pre-Release 2011.5.0.f1c1e4f56585' '-UserComment<$
{UserComment}&#xa;Projection: Equirectangular (2)&#xa;FOV: 34 x
40&#xa;Ev: 0.00' -f 1-2.tif
1 image files updated

kfj

unread,
Apr 28, 2012, 4:18:17 AM4/28/12
to hugin and other free panoramic software


On 28 Apr., 04:38, kevin360 <kevin...@yahoo.com> wrote:
> Forgot to include the output of multiblend.  Here's the output when
> stitching:
> ...
> /usr/local/bin/multiblend --compression=LZW -a -v -f2946x2506+40+23 -o
> 1-2.tif -- 1-20000.tif 1-20001.tif

This shows you're using multiblend on TIFF files, yet you include a
pto to stitch two JPGs. Are you sure stitching the two JPGs will
produce the error? TIFFs can have a variety of attributes which can
throw image processing software off the track, like apha channels and
masks and 16bit depth. When I tried it, I found multiblend useless for
my work (I'm doing nontrivial 360X180s in 16bit) because it produced
so many artifacts, but everyone seemed to be happy with the software
since it can speed up the creation of simple panoramas.

Kay

Monkey

unread,
Apr 28, 2012, 5:17:37 AM4/28/12
to hugi...@googlegroups.com
Thanks for the files - I ran it through but my result was okay. If you can get the same bad result with even smaller images, perhaps you could upload a couple of TIFs somewhere - that would guarantee I'm passing the same TIFs to multiblend.

David

kevin360

unread,
Apr 28, 2012, 1:20:45 PM4/28/12
to hugin and other free panoramic software
The images that are input into hugin are jpg files. When nona runs
and transforms then they are converted into a tif file. The line you
quoted below is when multiblend blends together the tif images that
nona has created.

kevin360

unread,
Apr 28, 2012, 1:27:01 PM4/28/12
to hugin and other free panoramic software
Ok, here are the two tiff images that I'm passing to multiblend that
were created from nona:

http://www.bluelavalamp.net/hugin/multiblend-spots/1-20000.tif
http://www.bluelavalamp.net/hugin/multiblend-spots/1-20001.tif

for multiblend I built it trying both compiler lines provided in the
readme file. The results are the same, so adding in the tiffxx lib
didn't make any difference. The system is 64-bit slackware linux.

Monkey

unread,
Apr 28, 2012, 3:43:13 PM4/28/12
to hugi...@googlegroups.com
Still no sign of the problem with those files here, I'm afraid - that's with Windows 32- and 64-bit builds, and a Fedora 14 32-bit build, which is all the OSes I have access to.

Does adding --nomask or --reverse to the multiblend command line make any difference?

David

kevin360

unread,
Apr 28, 2012, 4:25:37 PM4/28/12
to hugin and other free panoramic software
--nomask or --reverse doesn't make a difference. I have two other
linux systems that I just tested this on. 2 64-bit systems and 1 32-
bit system. One of the 64-bit systems it worked fine on. There were
some libraries that were different versions so I started trying that,
but didn't find anything there. Then I noticed that I have two
different gcc versions between the machines and that's the answer.
One machine is running gcc 4.6.2 and the other is running 4.7.0 If I
take the binary from 4.7.0 and move to the older version machine I get
the black area. If I take the binary from 4.6.2 machine and move to
the newer version machine I don't get the black area. I tried turning
off all optimization on the 4.7.0 compile but didn't make any
difference. The only way I can get the black areas to go away is to
compile with gcc 4.6.2.

On Apr 28, 3:43 pm, Monkey <davidhorma...@gmail.com> wrote:

Harry van der Wolf

unread,
Apr 28, 2012, 5:03:16 PM4/28/12
to hugi...@googlegroups.com
Hi,

I just ran the 0.31beta on OSX on the two tif images: no artefacts to be seen.
I simply did a "multiblend -o pipo.tif 1-20000.tif 1-20001.tif".

It's a 64bit openmp enabled multiblend.

Harry



2012/4/28 kevin360 <kevi...@yahoo.com>
Projection: Equirectangular (2)
FOV: 34 x
> > > > 40
Ev: 0.00' -f 1-2.tif
> > > >     1 image files updated

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx



--
Hugin development bundles for Mac OS X
ImageFuser for Mac OS X
KImageFuser for Linux

Monkey

unread,
Apr 28, 2012, 6:55:05 PM4/28/12
to hugi...@googlegroups.com
Openmp enabled? What does that involve/do?

I'll try to get gcc 4.7.0 running somewhere next week so I can work out why this is going wrong.

What happens if you try -l 0 or -l 1 ?

David
2012/4/28 kevin360 <kevi...@yahoo.com>
To unsubscribe from this group, send email to hugin-ptx+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/hugin-ptx

kevin360

unread,
Apr 28, 2012, 9:20:02 PM4/28/12
to hugin and other free panoramic software
Both -l 0 and -l 1 causes the black spot to go away. -l 2 and I get a
black line down through the image. Increasing the -l to higher
numbers increases the width of the black line and starts to blur it.


On Apr 28, 6:55 pm, Monkey <davidhorma...@gmail.com> wrote:
> Openmp enabled? What does that involve/do?
>
> I'll try to get gcc 4.7.0 running somewhere next week so I can work out why
> this is going wrong.
>
> What happens if you try -l 0 or -l 1 ?
>
> David
>
> On Saturday, April 28, 2012 10:03:16 PM UTC+1, Harry van der Wolf wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I just ran the 0.31beta on OSX on the two tif images: no artefacts to be
> > seen.
> > I simply did a "multiblend -o pipo.tif 1-20000.tif 1-20001.tif".
>
> > It's a 64bit openmp enabled multiblend.
>
> > Harry
>
> > 2012/4/28 kevin360 <kevin...@yahoo.com>
> >> hugin-ptx+...@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/hugin-ptx
>
> > --
> > Hugin development bundles for Mac OS X<http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin>
> > ImageFuser for Mac OS X <http://imagefuser.sourceforge.net/>
> > KImageFuser for Linux<http://panorama.dyndns.org/index.php?lang=en&subject=KImageFuser&text...>

Harry van der Wolf

unread,
Apr 29, 2012, 2:04:05 AM4/29/12
to hugi...@googlegroups.com


2012/4/29 Monkey <davidh...@gmail.com>

Openmp enabled? What does that involve/do?


Binaries and libraries will normally run on one core. With openmp the binaries and libraries that supoort parallel processing can/will  automatically use multiple cores when available. In this case it makes multiblend even faster.
See http://openmp.org/
Enblend does/use this already for a longer period.

Harry

Monkey

unread,
Apr 29, 2012, 5:14:18 AM4/29/12
to hugi...@googlegroups.com
The -l thing suggests it's something to do with the mask pyramid calculations. I know that with -Wall there are a lot of warnings about union members possibly being unitialised, but I was pretty sure I'd covered everything :(

Harry, did you make changes to the multiblend code to use OpenMP, or did it only affect the libraries it uses? I did try multithreading some parts of multiblend once (not with OpenMP), but never got any speed advantage out of it. The slowest part is seaming, which isn't easy to multithread.

David

Harry van der Wolf

unread,
Apr 29, 2012, 5:31:35 AM4/29/12
to hugi...@googlegroups.com


2012/4/29 Monkey <davidh...@gmail.com>

Harry, did you make changes to the multiblend code to use OpenMP, or did it only affect the libraries it uses? I did try multithreading some parts of multiblend once (not with OpenMP), but never got any speed advantage out of it. The slowest part is seaming, which isn't easy to multithread.

David

I did not make changes to the code.
libjpeg and libpng can be compiled with openmp support, so I did in the last round of library updates (jpeg-8d and png-1.5.10. The latter doesn't seem to compile with enblends builtin vigra so I might need to go back to a lower png version or I need to build vigra my own now).
Even though the libraries are compiled with or without openmp doesn't mean that the binaries using these libraries can be compiled for openmp.
The Apple gcc/g++ compiler somehow checks whether it is save to enable compilation for openmp, even though the source might not use it. When checking the 0.31 version it suddenly was possible to use openmp in compilation so I did.
It didn't do any speed comparisons yet. I'll try to find some time to do that.

Harry

Monkey

unread,
May 9, 2012, 8:58:18 AM5/9/12
to hugi...@googlegroups.com
Hi Kevin,

I haven't had a chance to investigate this any further, but if you wouldn't mind helping out a little, could you compile the latest version of multiblend (0.4, http://horman.net/multiblend/) and use the hidden --save-masks which will create mb_mask000.png to mb_maskxxx.png, and send me the resulting files?

Thanks,

David
> >> hugin-ptx+unsubscribe@googlegroups.com
Reply all
Reply to author
Forward
0 new messages