multiblend - a faster alternative to Enblend (Win x86/x64 binaries and source code) - v0.2 with JPEG support + bugfixes

[Monkey]

Hi all,

Apologies for starting a new discussion, but I access the group
through the website rather than via email and the subject needed
updating, plus I used a static link to the old download at the top of
the previous discussion (http://groups.google.com/group/hugin-ptx/t/
b08211b2659a7eab).

multiblend v0.2 is now available from http://horman.net/multiblend/

* fixed: no more segfaults when compiling with -O3
* work-around for seaming bug which left areas smeared in some cases
* added --reverse to change image priority (affects how "seaming bug"
areas are solved)
* added JPEG output support (requires libjpeg or equivalent; Windows
binaries use libjpeg-turbo)

As always, bug reports are greatly appreciated.

David

[Harry van der Wolf]

Hi David,

2012/1/7 Monkey <davidh...@gmail.com>

Did some quick tests: multiblend 0.2 compiles and works fine with -O3 on MacOSX. Now compiling with:
g++ -L/opt/local/lib -I/opt/local/include -msse2 -O3 multiblend.cpp -ltiff -ljpeg -o multiblend

jpeg output works fine.
However, when crosscompiling to build universally for the several architectures and versions for Mac OS X, -O3 and -O2 still segfault. using -O works.

Thanks for adding the jpeg support. Will do some further tests today.

Harry

[Naked Robot]

Can anyone post a version for OS X that is already compiled, please? :)

[Carlos Eduardo G. Carvalho (Cartola)]

Hi all,

I have compiled with -O3 and with -O2 in FreeBSD and there is still a segfault, now after "blending...":

multiblend v0.2 (c) 2011 David Horman
-------------------------------------

loading 01-15-2012010000.tif...
loading 01-15-2012010001.tif...
loading 01-15-2012010002.tif...
loading 01-15-2012010003.tif...
loading 01-15-2012010004.tif...
loading 01-15-2012010005.tif...
loading 01-15-2012010006.tif...
loading 01-15-2012010007.tif...
loading 01-15-2012010008.tif...
loading 01-15-2012010009.tif...
loading 01-15-2012010010.tif...
loading 01-15-2012010011.tif...
14512x5592, 8bpp, 11 levels
seaming...
masks...
blending...
Segmentation fault

It is working with -O. The compilation line I have used:

g++ -L/usr/local/lib -I/usr/local/include -ltiff -O2 -o multiblend-O2dbg -g -msse2 -D__APPLE__ multiblend.cpp

Here is the gdb output running on an i386 machine with FreeBSD 7.1-RELEASE, gcc 4.2.1.

multiblend v0.2 (c) 2011 David Horman
-------------------------------------

loading 01-15-2012010000.tif...
loading 01-15-2012010001.tif...
loading 01-15-2012010002.tif...
loading 01-15-2012010003.tif...
loading 01-15-2012010004.tif...
loading 01-15-2012010005.tif...
loading 01-15-2012010006.tif...
loading 01-15-2012010007.tif...
loading 01-15-2012010008.tif...
loading 01-15-2012010009.tif...
loading 01-15-2012010010.tif...
loading 01-15-2012010011.tif...
14512x5592, 8bpp, 11 levels
seaming...
masks...
blending...

Program received signal SIGSEGV, Segmentation fault.
0x0804cd2f in mask_into_output (input=0x36329240, mask=0x36600000, output=0x363290b0, first=true)
    at blending-int.cpp:489
489                     NEXT_MASK;

The gdb output when compiling using -O2 is the same. Hope it helps.

Cheers,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

[Harry van der Wolf]

2012/1/9 Naked Robot <360c...@gmail.com>

Can anyone post a version for OS X that is already compiled, please? :)

 

See my mail: http://groups.google.com/group/hugin-ptx/browse_thread/thread/5a58968d40dbcfa6/46872b0eec2f535e?pli=1

It's the 0.1a version. Not the 0.2.

I might build a new bundle including the 0.2 version tonight.

 

Harry

[Monkey]

Hmm... there are other int/float dual use bits that apparently need
rewriting. I just did the minimum to get it working on Fedora.

Give this a try, if you could:

http://horman.net/multiblend/blending-int.cpp

Harry, where do your universal builds segfault? After "masks..." or
"blending..." ?

David

[Carlos Eduardo G. Carvalho (Cartola)]

It looks ok now David! Worked with -O, -O2 and -O3. The best execution time was with -O2 where I got 35.48s. The other two ran around 37s.

Thanks,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/9 Monkey <davidh...@gmail.com>

--
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

[Harry van der Wolf]

2012/1/9 Monkey <davidh...@gmail.com>

It segfaulted after (or during) the blending at least before it could write "writing" to the terminal.
However, with this new blending-int.cpp it compiles and works correctly with -O2, also when crosscompiling.
So will this be 0.3 or 0.2.1 or 0.2a?

Harry
 

[Carlos Eduardo G. Carvalho (Cartola)]

Hi David, will you update the version as Harry asked? Today I downloaded from your site for another machine and had to download the last file separately from the link here.

Thanks!

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/9 Harry van der Wolf <hvd...@gmail.com>

--

[Monkey]

Hi Carlos,

I've updated the download archive now - I haven't changed the version
number as the fix doesn't change multiblend's functionality.

David

On Jan 14, 10:03 am, "Carlos Eduardo G. Carvalho (Cartola)"

[Carlos Eduardo G. Carvalho (Cartola)]

Thanks David!

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/16 Monkey <davidh...@gmail.com>

[Naked Robot]

does anyone have a compiled version for mac available?

Thank you,
Naked Robot

[Harry van der Wolf]

Again: check the several mails about hugin for OSX. Search for "[OSX] 20120115 New Hugin bundle hugin-mac-​2011.5.0.5​723_cd2f5e​37af3b incl. multiblend 0.2 and enblend 4.1 developmen​t"

 

Harry

2012/1/17 Naked Robot <360c...@gmail.com>

does anyone have a compiled version for mac available?

Thank you,
Naked Robot

[Bart van Andel]

Although this is slightly off topic, I feel I should mention it.

On Monday, January 16, 2012 6:05:15 PM UTC+1, Monkey wrote:

I've updated the download archive now - I haven't changed the version
number as the fix doesn't change multiblend's functionality.

Please do update version numbers if the contents of the file have changed. There may be various reasons why this should be done, but one in particular that I know of is this:

There exists a cross compiler environment named Mingw-cross-env [0], which relies on the file name for versioning. Part of the script is an update procedure which checks if newer files are available. Obviously this will fail if the filename hasn't changed. Moreover, it includes a hash based check to see if the downloaded file is indeed the file we are looking for (a basic sanity check). And this part will fail if the *contents* of the file with the same file name have changed.

Although this is mostly important for libs, I guess it's good practice to apply this reasoning to other packages as well.

This statement is not only applicable to multiblend, it also affects any other package. I believe Hugin itself doesn't suffer from this as version numbers are properly used in file names on sourceforge (note: behavior not recently tested).

[0] http://mingw-cross-env.nongnu.org/

--

Bart

[Harry van der Wolf]

2012/1/23 Bart van Andel <bavan...@gmail.com>

It's not off topic and I completely agree with you. I wanted to react as well but completely forgot (one get's older).

You have versions, subversions and bugfixes.

On some OSes you have something like: x.y.z, where x is a major change, y are minor changes and z are bugfixes. Also: where y is an equal number we speak about stable versions and where y is an odd number we speak of development versions.
For packaging and bugfixing you could even have x.y.z-a, where a is a change in configuration or configure script, package configuration or even a bug fix (whether or not in the configuring or packaging part).

Maybe that's all way over the top, but please update the versions with something like 0.2.1 or 0.2a like you did earlier.

It makes it clear to anyone that "something" has changed compared to the previous version.

Harry

[Monkey]

Just to keep you all up to date, I've got what I think is a workable
idea to implement wrapping. It will increase execution time, but not
much, and may also use slightly more memory, but it'll be worth the
sacrifice :) I'm not sure when I'll get around to programming it yet,
but it will be done.

I will also bear in mind the suggestions on version numbers for future
versions, thanks!

David

[Bart van Andel]

Hey everybody,

I've downloaded the source files to try and see if I could compile it for my own purposes. Attached is a modified version (source code) with a number of changes compared to David's current version:

• The software can now be cross-compiled on a Linux system targeting Win32, using mingw-cross-env (MCE). This took some effort, because this compiling environment is slightly different from both native Linux and WIN32, e.g. it doesn't come with a memalign-implementation, so I had to import one (not my own code).
• Source code structure has been restructured slightly: all source code has been moved into a src/ directory.
• Build script provided (build.sh), capable of building natively, or using MCE, both in release and debug flavors. Binaries will be placed in bin/ directory.
• Code reformatted. Mixed spaces and tabs were being used, now the code more or less follows the Linux standard with the exception that longer lines were kept. GNU indent was used for this (indent.sh script provided).
• Most importantly, I needed to be able to provide my own seam masks instead of having multiblend compute one for me. So I've implemented a function to load a PGM mask file. This file should use gray values [0..n-1] corresponding to images 0 to n-1, and have dimensions equal to the input span (may need --nocrop argument to prevent multiblend from modifying the output size; in my case it did). However a function to "unstretch" palettes from [0..255] back to [0..n-1] has also been implemented (--loadseams-unstretch).
• Mask saving (already present) is now a command line argument (--saveseams). This file can be edited and used again as an input mask. In this case, --loadseams-unstretch is required because the current implementation of saving the seams stretches the palette.
• I suppose the other functions for saving intermediate files (pyramid for example) could be exposed similarly, but I haven't implemented that (yet).
• NB: the default behavior hasn't been changed.
• NB: this is a work in progress, therefore, YMMV when using it.

Code is tested only through the cross-compile build and works fine for me. If anyone is interested I can post the binaries to this list or some other place.

Compiling natively on Linux works fine too, but I haven't actually blended anything with it (it does run though).

Compiling natively on Windows hasn't been tested.

Comments welcome!

@Monkey: Feel free to put this file on your site! What about putting the source code on github for example?

[Bart van Andel]

Oh, by the way, when installing mingw-cross-env, it is not required to build the whole system (which takes ages). After unpacking the .tar.gz archive or "hg clone"ing the system, a mere "make tiff jpeg" should do. This will automatically build the dependencies required for libtiff and libjpeg (e.g. the compiler itself).

--

Bart

[Terry Duell]

Hullo Bart,

On Wed, 08 Feb 2012 03:05:44 +1100, Bart van Andel <bavan...@gmail.com>
wrote:

> Hey everybody,
>
> I've downloaded the source files to try and see if I could compile it for
> my own purposes. Attached is a modified version (source code) with a
> number of changes compared to David's current version:
>

[snip]

> Code is tested only through the cross-compile build and works fine for
> me.
> If anyone is interested I can post the binaries to this list or some
> other place.
> Compiling natively on Linux works fine too, but I haven't actually
> blended
> anything with it (it does run though). Compiling natively on Windows
> hasn't been tested.
>
> Comments welcome!

It compiles here on Fedora 16 x86_64 using your build.sh.
I have run a simple test blend without any options, and blends OK.
I'll try to do a bit more rigorous testing when I have a bit more time,
and report if I find any problems.

Thanks for your work on this.

Cheers,
--
Regards,
Terry Duell