On Sunday, April 29, 2012 2:20:02 AM UTC+1, kevin360 wrote:
> 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>
> > >> --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:
> > >> > 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
> > >> > On Saturday, April 28, 2012 6:27:01 PM UTC+1, kevin360 wrote:
> > >> > > 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.
> > >> > > On Apr 28, 5:17 am, Monkey <davidhorma...@gmail.com> wrote:
> > >> > > > 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
> > >> > > > On Saturday, April 28, 2012 3:38:09 AM UTC+1, kevin360 wrote:
> > >> > > > > 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}
> > >> 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 hugin-ptx@googlegroups.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
> > > --
> > > 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...>