Panomatic - automatic keypoints creator

[Naouel]

Hello,

I just released a brand new tool Panomatic that does the same kind of
job as autopano or autopano-sift.
The main features are :
-Coded in modern C++
-Fast !
-Multithreaded in case you have multiple CPU/Cores.
-Will take place of autopano-sift
-Uses SURF feature descriptors (my own implementation)
-Uses Sieves to distribute matches at best
-Uses KDTrees for fast matching
-Uses a simplified RANSAC algorithm to fit a Homography model to
remove wrong matches

Just try it ! I have put some binaries for MacOS and Windows here :
http://aorlinsk2.free.fr/panomatic/
The source code will be available soon.


Anael

[ghking]

i might be doing something wrong. i get this error-

execvp(/Applications/Hugin.app/Contents/Resources/autopano-sift-c, -
o, /var/folders/zs/zseBNUfhELeq6MKrfx8s3E+++TI/-Tmp-/ap_resDUC2PV, /
Users/gavinking/Desktop/100_1323.JPG, /Users/gavinking/Desktop/
100_1324.JPG) failed with error 86!

then it crashes.

[Harry van der Wolf]

When I start panomatic from the command line on (Intel) OSX 10.4.11,
I get a segmentation fault. I used the 0.90 32-bit version.
Did you compile panomatic on Leopard and if so, did you use the
correct SDK?

For other users: The panomatic is not universal, only i386. So it
won't run on a ppc.

Below the panomatic.crash.log from my $HOME/Library/Logs/CrashReporter.
Please continue your attempts, I'm interested.

Hoi,
Harry

**********

Host Name: Antares-4
Date/Time: 2008-03-02 08:31:17.087 +0100
OS Version: 10.4.11 (Build 8S2167)
Report Version: 4

Command: panomatic
Path: ./panomatic
Parent: bash [393]

Version: ??? (???)

PID: 10854
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffff4

Thread 0 Crashed:
0 libstdc++.6.dylib 0x90b27830 std::basic_ostream<char,
std::char_traits<char> >::sentry::sentry[in-charge]
(std::basic_ostream<char, std::char_traits<char> >&) + 24
1 libstdc++.6.dylib 0x90b28e27 std::basic_ostream<char,
std::char_traits<char> >& std::operator<< <std::char_traits<char> >
(std::basic_ostream<char, std::char_traits<char> >&, char const*) + 29

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0xa0b0e920 ebx: 0x0001c643 ecx: 0xbffff890 edx: 0x00000000
edi: 0xbffff768 esi: 0xa0b0e920 ebp: 0xbffff718 esp: 0xbffff700
ss: 0x0000001f efl: 0x00010286 eip: 0x90b27830 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0x10dfff panomatic /Users/harryvanderwolf/
Downloads/panomatic/panomatic
0x8fe00000 - 0x8fe4afff dyld 46.16 /usr/lib/dyld
0x90000000 - 0x90171fff libSystem.B.dylib /usr/lib/
libSystem.B.dylib
0x901c1000 - 0x901c3fff libmathCommon.A.dylib /usr/lib/system/
libmathCommon.A.dylib
0x9080b000 - 0x908d3fff com.apple.CoreFoundation 6.4.9 (368.31) /
System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation
0x90911000 - 0x90911fff com.apple.CoreServices 10.4 (???) /
System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x90913000 - 0x90a07fff libicucore.A.dylib /usr/lib/
libicucore.A.dylib
0x90a57000 - 0x90ad6fff libobjc.A.dylib /usr/lib/libobjc.A.dylib
0x90aff000 - 0x90b63fff libstdc++.6.dylib /usr/lib/libstdc++.
6.dylib
0x90bd2000 - 0x90bd9fff libgcc_s.1.dylib /usr/lib/libgcc_s.
1.dylib
0x90bde000 - 0x90c51fff com.apple.framework.IOKit 1.4.8 (???) /
System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90c66000 - 0x90c78fff libauto.dylib /usr/lib/libauto.dylib
0x90c7e000 - 0x90f24fff com.apple.CoreServices.CarbonCore
682.28 /System/Library/Frameworks/CoreServices.framework/
Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x90f67000 - 0x90fcffff com.apple.CoreServices.OSServices 4.1 /
System/Library/Frameworks/CoreServices.framework/Versions/A/
Frameworks/OSServices.framework/Versions/A/OSServices
0x91008000 - 0x91047fff com.apple.CFNetwork 129.22 /System/
Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
CFNetwork.framework/Versions/A/CFNetwork
0x9105a000 - 0x9106afff com.apple.WebServices 1.1.3 (1.1.0) /
System/Library/Frameworks/CoreServices.framework/Versions/A/
Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore
0x91075000 - 0x910f4fff com.apple.SearchKit 1.0.7 /System/
Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
SearchKit.framework/Versions/A/SearchKit
0x9112e000 - 0x9114cfff com.apple.Metadata 10.4.4 (121.36) /
System/Library/Frameworks/CoreServices.framework/Versions/A/
Frameworks/Metadata.framework/Versions/A/Metadata
0x91158000 - 0x91166fff libz.1.dylib /usr/lib/libz.1.dylib
0x91169000 - 0x91308fff com.apple.security 4.5.2 (29774) /
System/Library/Frameworks/Security.framework/Versions/A/Security
0x91406000 - 0x9140efff com.apple.DiskArbitration 2.1.2 /System/
Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x91415000 - 0x9141cfff libbsm.dylib /usr/lib/libbsm.dylib
0x91420000 - 0x91446fff com.apple.SystemConfiguration 1.8.6 /
System/Library/Frameworks/SystemConfiguration.framework/Versions/A/
SystemConfiguration

[Harry van der Wolf]

I just did some quick tests on Leopard. Your panomatic does work on
Leopard (also within the bundle when following your work around), so
you develop on Leopard. You need to specify the correct target to be
able to make it run on Tiger.
I need to have a look at the preferences tab within the bundle as it
used to be possible to specify an "external" application. That's also
how I tested autopano-sift-c when it was just released (and that's not
so long ago).

Hoi,
Harry

2008/3/2, Harry van der Wolf <harryva...@home.nl>:

[Daniel M German]

Naouel> From: Naouel <anael.o...@gmail.com>
Naouel> Subject: [hugin-ptx] Panomatic - automatic keypoints creator
Naouel> To: hugin and other free panoramic software <hugi...@googlegroups.com>
Naouel> Date: Sat, 1 Mar 2008 16:51:08 -0800 (PST)
Naouel> Reply-To: hugi...@googlegroups.com

Thanks Naouel,

I tried the OS X version and it worked well with a pair of images.

I have a bug report:

When I fed it two images images, one black and white, it complained
that greyscale images were not supported (not an issue), then crashed
(the actual bug).

thanks again,

--dmg

Naouel> Hello,

Naouel> I just released a brand new tool Panomatic that does the same kind of
Naouel> job as autopano or autopano-sift.
Naouel> The main features are :
Naouel> -Coded in modern C++
Naouel> -Fast !
Naouel> -Multithreaded in case you have multiple CPU/Cores.
Naouel> -Will take place of autopano-sift
Naouel> -Uses SURF feature descriptors (my own implementation)
Naouel> -Uses Sieves to distribute matches at best
Naouel> -Uses KDTrees for fast matching
Naouel> -Uses a simplified RANSAC algorithm to fit a Homography model to
Naouel> remove wrong matches

Naouel> Just try it ! I have put some binaries for MacOS and Windows here :

--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

[Erik Krause]

On Saturday, March 01, 2008 at 16:51, Naouel wrote:

> Just try it ! I have put some binaries for MacOS and Windows here :
> http://aorlinsk2.free.fr/panomatic/
> The source code will be available soon.

Crashes with an illegal instruction exception on Windows 2000 (AMD
Athlon 1.3 GHz)

best regards
Erik Krause
http://www.erik-krause.de

[Naouel]

I updated the binaries :
For mac, i386 and ppc that should work with 10.4. x86_64 needs 10.5
For windows, a version without SSE instructions.

Please report successes / problems !

Thx

Anael

[Harry van der Wolf]

It works correct now on Intel OSX 10.4.11 also in combination with
the bundle (using the renaming work-around).

I assume you did know already, but in case you didn't know: To create
a universal binary from your "one architecture only" binaries you can
use the lipo command:
lipo -create "ppc panomatic" "i386 panomatic" -output panomatic

If you do a subsequent lipo -info panomatic you will see that it has
merged it to a universal binary.

And off course you can extend this with the 64 bits versions.
Hoi,
Harry

[Naouel]

Hello,

I released version 0.9.1 that :
+ fixes CPU detection on MacOS
+ fixes loading of greyscale images

As Harry suggested I build an universal binary with ppc / i386 /
x86_64.

Anael

[Harry van der Wolf]

Your universal binary works fine on OSX 10.4.11. Also the 0.91
binary now recognises 2 CPU's instead of 1.

There is currently one drawback. I used it from within the Hugin.app
bundle on the "Pete Holzmann" set of 70 images. Somewhere in the
process (between 35-40 images) it crashes. I will do a rerun, but
such a dataset takes a lot of time and I didn't see where it did go
wrong.

How is memory usage arranged? Does it support smaller resized images
or does it work on full-size images (in this case 70 images of
2136x2848 pixels).

Harry

[Naouel]

You're right. There's a kind of memory leak somewhere :-)
Please retry with 0.9.2.

Anael


On Mar 2, 10:59 pm, Harry van der Wolf <harryvanderw...@home.nl>

[Pablo dAngelo]

Hi Anael,

> Hello,

>
> I just released a brand new tool Panomatic that does the same kind of

> job as autopano or autopano-sift.

Sounds very interesting! I haven't tried it yet though (no linux version/source code ;-)

Unfortunately the SURF algorithms is patented too:
http://www.wipo.int/pctdb/en/wo.jsp?wo=2007128452

As there are quite a few people working on keypoints generators, maybe it would make sense
to coordiante development a little, or at least make sure that the individual components are
interoperable (for example, separate keypoint generation algorithm from the matching step).

For this, my long term goal was to have the keypoint detection as a separate program
(for flexibility and due to patent reasons), and have a good matching core (with the features you
listed, plus projection aware ransac etc.).
This has a high priority for me, and I'll continue working towards this after 0.7.0 has been released.

Note that the invariant keypoint descriptors are very good to deal with an unknown image geometry,
but there is inevitably a tradeoff in accuracy. For highly accurate control point localisation (with real
sub-pixel accuracy, down to 0.1 pixels), IMHO methods based on invariant keypoints are not suitable.
It would need some further study, but I'm not sure if the repeatability of the keypoint locations are not
that accurate, given different local distortions.

Once the approximate placement and projection parameters are known, taking these into account
could lead to much better control points. I believe Tom Sharpless is also thinking in that direction.

So my plan for a good and robust control point detection looks like:

1. keypoints extraction (on image with conformal projection) (external program)
2. Keypoints matching, internal in hugin (projection aware RANSAC, matching
only neighbouring images, if images are already roughly positioned.)

This will result in a relatively good assignment, with reasonable estimates for projection
parameters/distortion etc.
To improve the results a refinement step could be added, which
reuses this knowledge and uses correlation and/or least squares matching on locally
corrected images around each interest point (or new points, if desired). This function should
then also be used by the "fine tune" operation in the control points window. This will then work
well on fisheye images, too etc.

ciao
Pablo
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

[Philippe Gac]

hi,

thanks for your Panomatic

it seems it has some problems with the most recent snapshots of hugin (no
point returned) but it works fine with the 0.7 stable release

I tested it on pano views of modern buildings

for that, autopano is almost unusable (most of the point selected are
reflections or artefacts)

Panomatic gave very bad points (light geom checking?) but most of them were
very good and it saved me a lot of time: most were perfect after hugin
finetuning with rotation

a nice thing would be to detect and remove points in the sky...

one suggestion: when the series of images has a recognizable pattern (single
row...), have an option to remove points between distant images (in
A-B-C..., points of A,C are often imprecise, if not false)

phi

-----Message d'origine-----
De : hugi...@googlegroups.com [mailto:hugi...@googlegroups.com]De la
part de Naouel
Envoyé : 02 March 2008 01:51
À : hugin and other free panoramic software
Objet : [hugin-ptx] Panomatic - automatic keypoints creator

[Seb Perez-D]

On Sun, Mar 2, 2008 at 1:51 AM, Naouel <anael.o...@gmail.com> wrote:
> The source code will be available soon.

Can't wait to test it in Linux... I'll try in Wine, but speed
comparisons will be affected probably.

Cheers,

Seb

[Harry van der Wolf]

Hi Anael,

I tested again with your 0.92 universal version within the Hugin
bundle on OSX with the 70 images set from Peter Holzmann. It now did a
decent job. The "spread" of points seems to be a better than for
autopano-sift-c.
Also, autopano-sift-c does "find" a lot of duplicate points (that is:
in my panos and tests): sometimes 30-40% of the points are just
duplicates.
panomatic does a much better job there. From my own 5 and 12 image
test sets not a single duplicate point. I didn't check all 70 images
from Peter's set, but for the 15 or so images I didn't find a double
point either, and as mentioned, the points are nicely spread.

I haven't done any speed comparisons yet between autopano-sift-c and panomatic.

Keep up the good work and please share the source code with us.

Hoi,
Harry

2008/3/3, Seb Perez-D <sbprz...@gmail.com>:

[J. Schneider]

Hi Philippe,

> one suggestion: when the series of images has a recognizable pattern (single
> row...), have an option to remove points between distant images (in
> A-B-C..., points of A,C are often imprecise, if not false)

Just a question for better understanding: I used to add points like A,C
in the hope to improve precision of images orientation - or at least to
even out partially improper alignment. If I understand you correctly,
this is rather counter-productive? Is it just an observation or is there
a principal reason?
regards
Joachim

[Naouel]

Hey,

I just released the source code of panomatic 0.9.2 .

Please try it on various systems and give your feedback !
Thanks,

Anael

[Simon Oosthoek]

Thanks for posting the sources, however, there's still some work to be
done ;-)

$ ./configure:
....
config.status: creating libsurf/Makefile
config.status: error: cannot find input file: zthread/src/Makefile.in

$ make
cd . && /bin/bash /home/simon/src/hugin-cvs/panomatic-0.9.2/missing
--run aclocal-1.10 -I zthread/share
/usr/share/aclocal/libxosd.m4:9: warning: underquoted definition of
AM_PATH_LIBXOSD
/usr/share/aclocal/libxosd.m4:9: run info '(automake)Extending aclocal'
/usr/share/aclocal/libxosd.m4:9: or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
cd . && /bin/bash /home/simon/src/hugin-cvs/panomatic-0.9.2/missing
--run automake-1.10 --gnu
configure.in:22: required file `./compile' not found
configure.in:22: `automake --add-missing' can install `compile'
Makefile.am: required file `./INSTALL' not found
Makefile.am: `automake --add-missing' can install `INSTALL'
Makefile.am: required file `./COPYING' not found
Makefile.am: `automake --add-missing' can install `COPYING'
make: *** [Makefile.in] Error 1

Also, the README file is empty, as well as some other commmon files, but
I guess that's nitpicking...

About the license, could you consider opening up to GPLv3, either by
dual licensing it GPLv2 and v3, or use the "or later" clause as proposed
by the FSF?

It will take some attention regarding the known issues of patents on the
SURF algorithms, so I'm not sure how that works, as I'm not a lawyer...
However, using GPLv2 is not a solution to this problem, since the intent
of the GPLv2 and v3 licenses are the same and may have the same legal
interpretation. If anything, I believe GPLv3 may be safer regarding patents.

Cheers

Simon

[Michael [Plouj] Ploujnikov]

The main.c file, for example, states that it is licensed under GPLv2 and later.

--
Libre Software:
http://www.gnu.org/philosophy/free-sw.html

[Naouel]

> $ ./configure:
> ....
> config.status: creating libsurf/Makefile
> config.status: error: cannot find input file: zthread/src/Makefile.in

aaargh :-/
can you have a try with

./reconf
./configure
./make

> Also, the README file is empty, as well as some other commmon files, but
> I guess that's nitpicking...

Yes for tonight. But I will do it later.

>
> About the license, could you consider opening up to GPLv3, either by
> dual licensing it GPLv2 and v3, or use the "or later" clause as proposed
> by the FSF?

That's already the case... but maybe that's not very clear. In all the
source code files, the text says GPLv2 or later.
However the LICENCE file contains text of GPLv2. What should I do ??

>
> It will take some attention regarding the known issues of patents on the
> SURF algorithms, so I'm not sure how that works, as I'm not a lawyer...
> However, using GPLv2 is not a solution to this problem, since the intent
> of the GPLv2 and v3 licenses are the same and may have the same legal
> interpretation. If anything, I believe GPLv3 may be safer regarding patents.
>

That could be great. I will not make any money with the software so
there should not be any problem.

Anael

[Naouel]

I uploaded a fixed source package for 0.9.2. It compiles on a Linux
machine by using only :

./configure CPPFLAGS="-I/home/naouel/projects/boost_1_34_1"
./make

Enjoy.

Anael

[Simon Oosthoek]

Naouel wrote:
>> $ ./configure:
>> ....
>> config.status: creating libsurf/Makefile
>> config.status: error: cannot find input file: zthread/src/Makefile.in
>
> aaargh :-/
> can you have a try with
>
> ./reconf
> ./configure
> ./make

Ok, that's working fine :-)

>> About the license, could you consider opening up to GPLv3, either by
>> dual licensing it GPLv2 and v3, or use the "or later" clause as proposed
>> by the FSF?
>
> That's already the case... but maybe that's not very clear. In all the
> source code files, the text says GPLv2 or later.
> However the LICENCE file contains text of GPLv2. What should I do ??

http://www.fsf.org/licensing/licenses/gpl-howto.html

> That could be great. I will not make any money with the software so
> there should not be any problem.

I'm sure it's not quite that simple all over the world :-(
As a simple thought experiment, you may be depriving the "owners" of the
patent their potential revenue by providing their functional idea for
free without reimbursing them for creating it. Patent stuff can get very
silly when applied to software and similar mathematical algorithms.

If you're in doubt about this, you might want to look here:
http://www.softwarefreedom.org/

Cheers

Simon

[Philippe Gac]

Hi Joachim,

In a perfect world, you'd be right without any reservation... Such data
would also help determine the lens parameters.

But, at least in most of my panos, it is rather counter-productive for
mainly 2 reasons:

- the intersection A-C lies far from the center of the image where its
quality id degraded: softness, irregular distorsion, chromatic aberration,
purple fringing... thus the points found are often erroneous or at least
imprecise

- without pod, the optical center is not fixed and you compensate with d/e
center-shift parameters; that's possible with 2 images at the time with a
well-placed seam but not with 3 images with 2 distant seams. these "bridged"
pairs often introduce unsatisfiable constraints. Of course, when you align
A-B B-C, you might have to do some cropping to force the placement of seams.

it's true that A-C control points may divide by 2 the accumulated error
regarding orientation
when possible, I use vertical lines; if not, I try to select the best points
to make max error as small as possible (0.5 in some difficult cases, instead
of 1.2)

on the whole, in my experience, I consider that these "bridged" pairs a
nuisance. For multirows panos, I thus remove all "bridges" and that gives
better and quicker results. Most of the times, I also remove "crosses",
pairs across diagonally contiguous images for the same reasons.

I think that guessing the pattern of the mosaic, or allowing the user to
specify it, provided it is simple, could save a lot of time by eliminating a
priori useless pair searches and alleviate the work of ransac algo. Then,
you could even look first for points on a band (to be adjusted).

regards, philippe

[Stephan Hegel]

Hi Anael,

I've just managed to build and run panomatic-0.9.2 on openSuSE 10.3, x86_64.
First impression: it works, two CPUs are detected, it seems to be pretty fast.
Pto-Files can be loaded into hugin, key points appear but I didn't have the
time to check them out.

A few questions:
1st:
Does Panomatic processes downscaled or full scale images ?

2nd:
When running it over tiff images I get a bunch of warnings:
i3 : Analyze image...
Warning: no TIFFTAG_SAMPLEFORMAT or TIFFTAG_DATATYPE, guessing pixeltype 'UINT8'.
Is this wanted ?
The tiffinfo utility reports among others:
Bits/Sample: 8
Samples/Pixel: 3

3rd:
Is it really necessary to use Boost 1.34.1 or would 1.33.1 be sufficient ?
Reason is that openSuSE comes with 1.33.1. Building 1.34.1 was rather a
headache 'cause in the source distribution are quite a bunch of Unix shell
scripts in DOS format which lead to very funny error messages like "comand
not found", execute permissions for the scripts aren't set correctly plus
searching for a fix for a bjam segfault:
http://svn.boost.org/trac/boost/ticket/977

Don't know what is currently shipped with Debian/Fedora/... ?

Regards,
Stephan.

[Naouel]

>
> A few questions:
> 1st:
> Does Panomatic processes downscaled or full scale images ?

Full scale. Every pixel counts ;-)
Working on scaled images would surely reduce the memory footprint and
speed up analysis of images...

>
> 2nd:
> When running it over tiff images I get a bunch of warnings:
> i3 : Analyze image...
> Warning: no TIFFTAG_SAMPLEFORMAT or TIFFTAG_DATATYPE, guessing pixeltype 'UINT8'.
> Is this wanted ?
> The tiffinfo utility reports among others:
> Bits/Sample: 8
> Samples/Pixel: 3
>

That's annoying, I know... This warning comes from in vigra_impex, the
lib I use to load the images.

> 3rd:
> Is it really necessary to use Boost 1.34.1 or would 1.33.1 be sufficient ?
> Reason is that openSuSE comes with 1.33.1. Building 1.34.1 was rather a
> headache 'cause in the source distribution are quite a bunch of Unix shell
> scripts in DOS format which lead to very funny error messages like "comand
> not found", execute permissions for the scripts aren't set correctly plus
> searching for a fix for a bjam segfault:
> http://svn.boost.org/trac/boost/ticket/977

You should read the web page : you don't need to compile boost !!!!
All the features I use in boost are provided via headers.
And moreover I think that boost_foreach is not present in boost
1.33.1.

Anael

[Stephan Hegel]

Hi Anael,

Naouel wrote:
> You should read the web page : you don't need to compile boost !!!!

Stay cool ... ;).

First, I've read the README (is empty) and the INSTALL file in your
tarball. Nothing about Boost. When I run configure I get an error
stating that the boost libraries 0.34.1 cannot be detected. It also
says nothing about "headers only". And the Boost installation web site
for Unix explains installation procedure for both header and binary
libs.

Second, when I install (and overwrite) an existing package with a new
version on my system, I prefer to do it completely. Otherwise it is
only a matter of time and the next package can find the new headers
and is crying for the missing libs. However, YMMV here.

> All the features I use in boost are provided via headers.

In case you use only a few header files of the Boost lib, why not just
copy them to the panomatic tarball and use them from there ? Doing so
would remove this external dependency. Much easier to maintain.

The Boost license seems to allow this: "if you distribute your own code
along with some Boost code, the Boost license applies only to the Boost
code (and modified versions thereof); you are free to license your own
code under any terms you like".
Quoted from
http://www.boost.org/more/license_info.html

Kind regards,
Stephan.

[J. Schneider]

Philippe Gac schrieb:

>
> Hi Joachim,
>>> one suggestion: when the series of images has a recognizable
>> pattern (single
>>> row...), have an option to remove points between distant images
>>> (in A-B-C..., points of A,C are often imprecise, if not false)
>> Just a question for better understanding: I used to add points like
>> A,C in the hope to improve precision of images orientation - or at
>> least to even out partially improper alignment. If I understand you
>> correctly, this is rather counter-productive? Is it just an
>> observation or is there a principal reason? regards Joachim
>
> In a perfect world, you'd be right without any reservation... Such
> data would also help determine the lens parameters.

Of course the world is perfect! (Except for my Windows machine ...)

> But, at least in most of my panos, it is rather counter-productive
> for mainly 2 reasons:
>
> - the intersection A-C lies far from the center of the image where
> its quality id degraded: softness, irregular distorsion, chromatic
> aberration, purple fringing... thus the points found are often
> erroneous or at least imprecise

I accept this trade-off in precision for dividing by 2 the accumulated
error, as you call it.

> - without pod, the optical center is not fixed and you compensate
> with d/e center-shift parameters; that's possible with 2 images at
> the time with a well-placed seam but not with 3 images with 2 distant
> seams. these "bridged" pairs often introduce unsatisfiable
> constraints. Of course, when you align A-B B-C, you might have to do
> some cropping to force the placement of seams.

That's interesting. I used the d/e method in some particularly stubborn
cases and not always with success - perhaps because of bridged pairs. I
will have to keep this in mind as my panoramas are usually hand held.

> it's true that A-C control points may divide by 2 the accumulated
> error regarding orientation when possible, I use vertical lines; if
> not, I try to select the best points to make max error as small as
> possible (0.5 in some difficult cases, instead of 1.2)

Always depends on the overall size of the pano or the size of single
images. I have been wondering for some time what would be a reasonable
size independent descriptor for fit quality.

> ...
> regards, philippe

regards
Joachim

[slaterson]

On Mar 1, 4:51 pm, Naouel <anael.orlin...@gmail.com> wrote:
> Hello,
>

> I just released a brand new toolPanomaticthat does the same kind of

> job as autopano or autopano-sift.
> The main features are :
> -Coded in modern C++
> -Fast !
> -Multithreaded in case you have multiple CPU/Cores.
> -Will take place of autopano-sift
> -Uses SURF feature descriptors (my own implementation)
> -Uses Sieves to distribute matches at best
> -Uses KDTrees for fast matching
> -Uses a simplified RANSAC algorithm to fit a Homography model to
> remove wrong matches
>
> Just try it ! I have put some binaries for MacOS and Windows here :http://aorlinsk2.free.fr/panomatic/

> The source code will be available soon.
>

> Anael

i tried this today on a panorama i have been working on recently. i
used the 0.9.2 release compiled on a gentoo workstation, pentium 4
(northwood) 3 ghz cpu with 1 gb of ram. for my project, 57 images,
each image having 4386x2920 resolution, it took 7626 seconds to create
all control points. when i loaded the pto file in hugin, all the
images were stitched as expected.

do you have any plans to add automatic creation of horizon lines?
autopano-sift-c has this feature, i don't know any details as i am
just starting to learn and use it.

[Faceman]

I must be doing something wrong. I have Harry's OS X bundle, SVN 2926.
I'm running OS X 10.5.2. But the instructions on your page do not seem
to work. It begins its run and loads and analyzes just fine (in my
case, analyzing 16 TIFF images of 3072x2048 pixels) and then errors
out with the following error:

i0 <> i1 : Find Matches...
Assertion failed: (px != 0), function operator*, file /opt/local/
include/boost/shared_ptr.hpp, line 309.

Huh?

Also, a minor point "autopano-sift-c" appears at .../Contents/
Resources/HuginStitchProject.app/Contents/MacOS/autopano-sift-c and
not /Contents/Resources, as per your instructions.

On Mar 1, 7:51 pm, Naouel <anael.orlin...@gmail.com> wrote:
> Hello,
>

> I just released a brand new tool Panomatic that does the same kind of

[Bruno Postle]

On Tue 04-Mar-2008 at 06:37 +0100, Stephan Hegel wrote:
>
>Is it really necessary to use Boost 1.34.1 or would 1.33.1 be sufficient ?
>Reason is that openSuSE comes with 1.33.1.

>Don't know what is currently shipped with Debian/Fedora/... ?

Fedora F8 (and F9) has boost-1.34.1, though I have no idea of the
differences.

--
Bruno

[Stephan Hegel]

Hi,

Bruno Postle wrote:
>> Don't know what is currently shipped with Debian/Fedora/... ?
>
> Fedora F8 (and F9) has boost-1.34.1, though I have no idea of the
> differences.

Well, I've checked with boost-1.33.1 and it doesn't compile. Anael
was right when he guessed that BOOST_FOREACH is missing in 1.33.1.

Rgds,
Stephan.

[Pablo d'Angelo]

slaterson wrote:

> do you have any plans to add automatic creation of horizon lines?
> autopano-sift-c has this feature, i don't know any details as i am
> just starting to learn and use it.

Please don't.
This feature of autopano-sift-c is just a hack. It doesn't belong into a
control points generator.
Use the align button or the in "Straighten horizon" button the hugin preview
instead.

ciao
Pablo

[Harry van der Wolf]

2008/3/5, Faceman <face...@gmail.com>:

>
> I must be doing something wrong. I have Harry's OS X bundle, SVN 2926.
> I'm running OS X 10.5.2. But the instructions on your page do not seem
> to work. It begins its run and loads and analyzes just fine (in my
> case, analyzing 16 TIFF images of 3072x2048 pixels) and then errors
> out with the following error:
>
> i0 <> i1 : Find Matches...
> Assertion failed: (px != 0), function operator*, file /opt/local/
> include/boost/shared_ptr.hpp, line 309.

This is something linked in dynamically, that should be corrected.
Panomatic works for me as I have boost also in /opt/local for straight
macports based compiles of hugin and the like. You do obviously not
compile yourself and therefor this file is missing on your system. I
did not (have time to) compile panomatic myself on OSX and than linked
inside the bundle, but I want to include it together with
autopano-sift-c in future bundles

>
> Also, a minor point "autopano-sift-c" appears at .../Contents/
> Resources/HuginStitchProject.app/Contents/MacOS/autopano-sift-c and
> not /Contents/Resources, as per your instructions.
>

You are correct. Autopano-sift-c is in
"Hugin.app/Contents/Resources/HuginStitchProject.app/Contents/MacOS"
and not in "Contents/Resources" (overlooked that completely in the
mails as I know the hugin.app structure almost blindly now and didn't
even readt this).
And yes indeed, you should also copy panomatic (as autopano-sift-c) to
that location.

Hoi,
Harry

[Naouel]

> I must be doing something wrong. I have Harry's OS X bundle, SVN 2926.
> I'm running OS X 10.5.2. But the instructions on your page do not seem
> to work. It begins its run and loads and analyzes just fine (in my
> case, analyzing 16 TIFF images of 3072x2048 pixels) and then errors
> out with the following error:

> i0 <> i1 : Find Matches...
> Assertion failed: (px != 0), function operator*, file /opt/local/
> include/boost/shared_ptr.hpp, line 309.

I suspect a but with the loading of TIFF files. Could you try to
convert the files (say to JPG) and
try again ? And can you send me the whole output of panomatic ? (in a
private email).

> > This is something linked in dynamically, that should be corrected.
> Panomatic works for me as I have boost also in /opt/local for straight
> macports based compiles of hugin and the like. You do obviously not
> compile yourself and therefor this file is missing on your system. I
> did not (have time to) compile panomatic myself on OSX and than linked
> inside the bundle, but I want to include it together with
> autopano-sift-c in future bundles
>

That's wrong. I just use boost features that are provided via header
files, then nothing regarding boost should be linked dynamically.
To check the required dynamic libraries, just run otool -L panomatic.
Hopefully nothing from

Anael

[Harry van der Wolf]

> > > This is something linked in dynamically, that should be corrected.
> > Panomatic works for me as I have boost also in /opt/local for straight
> > macports based compiles of hugin and the like. You do obviously not
> > compile yourself and therefor this file is missing on your system. I
> > did not (have time to) compile panomatic myself on OSX and than linked
> > inside the bundle, but I want to include it together with
> > autopano-sift-c in future bundles
> >
>
>
> That's wrong. I just use boost features that are provided via header
> files, then nothing regarding boost should be linked dynamically.
> To check the required dynamic libraries, just run otool -L panomatic.
> Hopefully nothing from
>
>

I also tried "otool -L panomatic" as it is the first to check, but it
returns nothing regarding boost. So technically it shouldn't be "in
there".
You also compile jpeg, zlib, tiff and some others statically as part
of panomatic. I understand that you do this to be able to deliver a
stand-alone binary. I prefer to link it against my own libs though.
Can you add some setting or so that you can also compile it against
available libs on the system OR that you can modify the SUBDIRS lines
in Makefile.in and so that it only tries to build the libs specified
on that line (like surf, vigra and panomatic) and that others are
found via the prefixes on the system?

I have another problem: You compile panomatic for ppc against the
MacOSX10.4u.sdk
I tried to compile panomatic for ppc against MacOSX10.3.9.sdk to be
100% ppc compliant. This doesn't work however. What is it that
prevents it from compiling against/for 10.3.9?

Harry

[slaterson]

how is align or straighten used? i did a quick check of the docs
here: http://hugin.sourceforge.net/docs/manual/Hugin_Preview_window.html
but there aren't any details. i have tried using those before and it
has proven difficult to figure out. i have been adding horizontal and
vertical control point but i'd really like an easier/quicker method if
possible.

thanks

[Faceman]

Anael,

Thanks for the input. I'll see if I can try it with JPGs later tonight
(I like using TIFFs to avoid the block artifacts of JPEG, though).

Note that I am obviously not a developer. Since I'm running panomatic
from within Hugin on OS X, the console messages go by quickly and then
the window is closed. In fact, the only way I captured the info I
posted was by using a screen capture utility to capture a movie of the
console messages flying by. Inelegant, I know. I could always try
running it from the terminal shell and seeing if that'd be helpful for
you. FWIW, it does seem to be processing the TIFF images normally with
messages "Analyze image..." and "Load RGB..." occurring uneventfully,
followed by "Find matches...." and then the error output I described
above.

Also, I do not have otool installed on my system, to my knowledge.

[Faceman]

Harry,

Thanks for looking into this, as well. I was guessing that I was
missing some library, though. And you are correct that I do not
compile these builds myself, but it may be something to try. My guess
is that I'd just make a mess of it, though.

On Mar 5, 4:17 am, "Harry van der Wolf" <hvdw...@gmail.com> wrote:
....

>
> This is something linked in dynamically, that should be corrected.
> Panomatic works for me as I have boost also in /opt/local for straight
> macports based compiles of hugin and the like. You do obviously not
> compile yourself and therefor this file is missing on your system. I
> did not (have time to) compile panomatic myself on OSX and than linked
> inside the bundle, but I want to include it together with
> autopano-sift-c in future bundles
>

....
> Hoi,
> Harry

[Naouel]

> You also compile jpeg, zlib, tiff and some others statically as part
> of panomatic. I understand that you do this to be able to deliver a
> stand-alone binary. I prefer to link it against my own libs though.
> Can you add some setting or so that you can also compile it against
> available libs on the system OR that you can modify the SUBDIRS lines
> in Makefile.in and so that it only tries to build the libs specified
> on that line (like surf, vigra and panomatic) and that others are
> found via the prefixes on the system?

For Linux that's surely a good idea to use by default the bundled
libs, and with override (--with-libXXX = /path/ ) to link dynamically
with
system ones. If somebody wants to help on this... no problem.

However for mac I'm not convinced.
Most of users don't have macports installed, so they don't have
libjpeg, libtiff, libpng on their system (maybe zlib is bundled by
default).

In my opinion that would be more interesting to think of reusing the
vigra framework in the hugin bundle. If you have a look at the
(broken) XCode project,
that's the way it used to work. (With my AnaImageFramework that
bundles all the external libs but zthread).

>
> I have another problem: You compile panomatic for ppc against the
> MacOSX10.4u.sdk
> I tried to compile panomatic for ppc against MacOSX10.3.9.sdk to be
> 100% ppc compliant. This doesn't work however. What is it that
> prevents it from compiling against/for 10.3.9?
>

No idea. But depending on your compilation errors I may give some
clues.


Anael

[Bob Bright]

On Wed, 2008-03-05 at 02:29 -0800, Naouel wrote:

>  I must be doing something wrong. I have Harry's OS X bundle, SVN 2926.
>  I'm running OS X 10.5.2. But the instructions on your page do not seem
>  to work. It begins its run and loads and analyzes just fine (in my
>  case, analyzing 16 TIFF images of 3072x2048 pixels) and then errors
>  out with the following error:

>      i0 <> i1 : Find Matches...
>      Assertion failed: (px != 0), function operator*, file /opt/local/
>  include/boost/shared_ptr.hpp, line 309.

I suspect a but with the loading of TIFF files. Could you try to
convert the files (say to JPG) and
try again ? And can you send me the whole output of panomatic ? (in a
private email).

I'm getting the same error followed by a core dump with TIFF input on Ubuntu 7.10.  Complete output is pasted below.  And switching to JPEG does indeed cure the problem (fine for testing purposes, but I can't use JPEG for production work).

BBB


panomatic -o test.pto fused*.tif
Pan-o-matic 0.9.2 by Anael Orlinski - nao...@naouel.org

Output file       : test.pto
Number of CPU     : 2

SURF Options
  Extended : yes
  Score threshold : 1000
Sieve 1 Options
  Width : 10
  Height : 10
  Size : 10
  ==> Maximum keypoints per image : 1000
KDTree Options
  Search steps : 40
  Second match distance : 0.15
RANSAC Options
  Iterations : 1000
  Distance threshold : 25
Sieve 2 Options
  Width : 5
  Height : 5
  Size : 1
  ==> Maximum matches per image pair : 25
Input Files :
  - fused_00.tif
  - fused_01.tif
  - fused_02.tif
  - fused_03.tif
  - fused_04.tif
  - fused_05.tif
  - fused_06.tif
  - fused_07.tif
  - fused_08.tif
  - fused_09.tif
  - fused_10.tif
  - fused_11.tif

--- Analyze Images ---
i0 : Analyze image...
i1 : Analyze image...
i1 : Load RGB...
i0 : Load RGB...
i2 : Analyze image...
i3 : Analyze image...
i2 : Load RGB...
i3 : Load RGB...
i4 : Analyze image...
i5 : Analyze image...
i4 : Load RGB...
i5 : Load RGB...
i6 : Analyze image...
i7 : Analyze image...
i6 : Load RGB...
i7 : Load RGB...
i8 : Analyze image...
i9 : Analyze image...
i8 : Load RGB...
i9 : Load RGB...
i10 : Analyze image...
i11 : Analyze image...
i10 : Load RGB...
i11 : Load RGB...

--- Find matches ---
i0 <> i2 : Find Matches...
i0 <> i1 : Find Matches...
panomatic: /home/bbb/build/boost_1_34_1/boost/shared_ptr.hpp:309: typename boost::detail::shared_ptr_traits<T>::reference boost::shared_ptr<T>::operator*() const [with T = KDTreeSpace::KDTree<KDElemKeyPoint, double>]: Assertion `px != 0' failed.
i0 <> i1 : Find Matches...
Aborted (core dumped)

[Harry van der Wolf]

> However for mac I'm not convinced.
> Most of users don't have macports installed, so they don't have
> libjpeg, libtiff, libpng on their system (maybe zlib is bundled by
> default).
>

Agreed. Just leave it as it is.

> In my opinion that would be more interesting to think of reusing the
> vigra framework in the hugin bundle. If you have a look at the
> (broken) XCode project,
> that's the way it used to work. (With my AnaImageFramework that
> bundles all the external libs but zthread).
>

I have a look at the xcode project, but I'm not an xcode expert myself.

>
> >
> > I have another problem: You compile panomatic for ppc against the
> > MacOSX10.4u.sdk
> > I tried to compile panomatic for ppc against MacOSX10.3.9.sdk to be
> > 100% ppc compliant. This doesn't work however. What is it that
> > prevents it from compiling against/for 10.3.9?
> >
>
>
> No idea. But depending on your compilation errors I may give some
> clues.
>

OK. Not tonight, but I'll be back.

[Harry van der Wolf]

Well, I just pushed another ppc compilation through where I tried to
compile against the 10.3.9.SDK

Below a snippet of where the error occurs

rm -f libsurf.a
ar cru libsurf.a Image.o KeyPointDescriptor.o KeyPointDetector.o MathStuff.o
ranlib libsurf.a
Making all in panomatic
g++ -DPACKAGE_NAME=\"detectpano\" -DPACKAGE_TARNAME=\"detectpano\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"detectpano\ 1.0\"
-DPACKAGE_BUGREPORT=\"ana...@gmail.com\" -DPACKAGE=\"detectpano\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DWORDS_BIGENDIAN=1
-DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1
-DHAVE_POSIX_THREADS= -DHAVE_SCHED_YIELD= -DHAVE_PTHREADKEY_CREATE=
-DHAVE_BOOST= -DPNG_NO_ASSEMBLER_CODE= -I. -I../libsurf
-I../vigra/include -I/usr/local/include -I../zthread/include
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/OpenEXR
-isysroot /Developer/SDKs/MacOSX10.3.9.sdk -arch ppc -mcpu=G3
-mtune=G4 -mmacosx-version-min=10.3 -dead_strip -c -o Homography.o
Homography.cpp
Homography.h:60: error: expected unqualified-id before numeric constant
Homography.h:60: error: abstract declarator 'double**' used as declaration
Homography.h:60: error: expected ';' before numeric constant
Homography.h:61: error: expected unqualified-id before numeric constant
Homography.h:61: error: abstract declarator 'double*' used as declaration
Homography.h:61: error: expected ';' before numeric constant
Homography.h:62: error: expected unqualified-id before numeric constant
Homography.h:62: error: abstract declarator 'double*' used as declaration
Homography.h:62: error: expected ';' before numeric constant
Homography.h:63: error: expected unqualified-id before numeric constant
Homography.h:63: error: abstract declarator 'double*' used as declaration
Homography.h:63: error: expected ';' before numeric constant
Homography.cpp: In member function 'void Homography::allocMemory(int)':
Homography.cpp:47: error: invalid lvalue in assignment
Homography.cpp:49: error: invalid types 'long int[int]' for array subscript
Homography.cpp:51: error: invalid lvalue in assignment
Homography.cpp:52: error: invalid lvalue in assignment
Homography.cpp:53: error: invalid lvalue in assignment
Homography.cpp: In member function 'void Homography::freeMemory()':
Homography.cpp:61: error: type 'long int' argument given to 'delete',
expected pointer
Homography.cpp:62: error: type 'long int' argument given to 'delete',
expected pointer
Homography.cpp:63: error: type 'long int' argument given to 'delete',
expected pointer
Homography.cpp:65: error: invalid types 'long int[int]' for array subscript
Homography.cpp:66: error: type 'long int' argument given to 'delete',
expected pointer
Homography.cpp: In member function 'void Homography::addMatch(int,
PointMatch&)':
Homography.cpp:125: error: invalid types 'long int[int]' for array subscript
Homography.cpp:126: error: invalid types 'long int[int]' for array subscript
Homography.cpp:127: error: invalid types 'long int[int]' for array subscript
Homography.cpp:128: error: invalid types 'long int[int]' for array subscript
Homography.cpp:129: error: invalid types 'long int[int]' for array subscript
Homography.cpp:130: error: invalid types 'long int[int]' for array subscript
Homography.cpp:131: error: invalid types 'long int[int]' for array subscript
Homography.cpp:132: error: invalid types 'long int[int]' for array subscript
Homography.cpp:134: error: invalid types 'long int[int]' for array subscript
Homography.cpp:138: error: invalid types 'long int[int]' for array subscript
Homography.cpp:139: error: invalid types 'long int[int]' for array subscript
Homography.cpp:140: error: invalid types 'long int[int]' for array subscript
Homography.cpp:141: error: invalid types 'long int[int]' for array subscript
Homography.cpp:142: error: invalid types 'long int[int]' for array subscript
Homography.cpp:143: error: invalid types 'long int[int]' for array subscript
Homography.cpp:144: error: invalid types 'long int[int]' for array subscript
Homography.cpp:145: error: invalid types 'long int[int]' for array subscript
Homography.cpp:147: error: invalid types 'long int[int]' for array subscript
Homography.cpp: In member function 'bool
Homography::estimate(PointMatchVector_t&)':
Homography.cpp:188: error: invalid conversion from 'long int' to 'double**'
Homography.cpp:188: error: initializing argument 1 of 'bool
Givens(double**, double*, double*, double*, int, int, int)'
Homography.cpp:188: error: invalid conversion from 'long int' to 'double*'
Homography.cpp:188: error: initializing argument 2 of 'bool
Givens(double**, double*, double*, double*, int, int, int)'
Homography.cpp:188: error: invalid conversion from 'long int' to 'double*'
Homography.cpp:188: error: initializing argument 3 of 'bool
Givens(double**, double*, double*, double*, int, int, int)'
Homography.cpp:188: error: invalid conversion from 'long int' to 'double*'
Homography.cpp:188: error: initializing argument 4 of 'bool
Givens(double**, double*, double*, double*, int, int, int)'
Homography.cpp:196: error: invalid types 'long int[int]' for array subscript
Homography.cpp:197: error: invalid types 'long int[int]' for array subscript
Homography.cpp:198: error: invalid types 'long int[int]' for array subscript
Homography.cpp:200: error: invalid types 'long int[int]' for array subscript
Homography.cpp:201: error: invalid types 'long int[int]' for array subscript
Homography.cpp:202: error: invalid types 'long int[int]' for array subscript
Homography.cpp:204: error: invalid types 'long int[int]' for array subscript
Homography.cpp:205: error: invalid types 'long int[int]' for array subscript
make[1]: *** [Homography.o] Error 1
make: *** [all-recursive] Error 1
Making install in zlib/src
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in libpng/src
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in libtiff/src
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in libjpeg/src
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in vigra/src/impex
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in zthread/src
Making install in .
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in libsurf
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in panomatic
g++ -DPACKAGE_NAME=\"detectpano\" -DPACKAGE_TARNAME=\"detectpano\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"detectpano\ 1.0\"
-DPACKAGE_BUGREPORT=\"ana...@gmail.com\" -DPACKAGE=\"detectpano\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DWORDS_BIGENDIAN=1
-DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1
-DHAVE_POSIX_THREADS= -DHAVE_SCHED_YIELD= -DHAVE_PTHREADKEY_CREATE=
-DHAVE_BOOST= -DPNG_NO_ASSEMBLER_CODE= -I. -I../libsurf
-I../vigra/include -I/usr/local/include -I../zthread/include
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/OpenEXR
-isysroot /Developer/SDKs/MacOSX10.3.9.sdk -arch ppc -mcpu=G3
-mtune=G4 -mmacosx-version-min=10.3 -dead_strip -c -o Homography.o
Homography.cpp

2008/3/5, Harry van der Wolf <hvd...@gmail.com>:

[Naouel]

Clearly that's a problem with loading TIFF files. Panomatic 0.9.3 will
not not fix it either. I will try to use libtiff 3.9beta or 4.0.0alpha
to see if there is any improvement.
And I will change the code to abort if a load problem is detected...

Curiously, my 16-bit files I get from Canon DPP are working without a
glitch.

Anael

[Naouel]

Two things :

1.
0.9.3 is out. With some suggested features that will speedup
detection.
I am interested to know if you see a keypoint quality decrease with
half-scaled images (the new default), because there's a real speed
gain.

2.
The TIFF loading bug is due to alpha channel. There's surely a way to
batch remove this channel with imagemagick. Panomatic 0.9.4 will fix
this problem.

Anael

[Bob Bright]

2.
The TIFF loading bug is due to alpha channel. There's surely a way to
batch remove this channel with imagemagick. Panomatic 0.9.4 will fix
this problem.

Anael

Are you sure?  My TIFFs are generated from .CR2 by ufraw, and they don't appear to have an alpha channel.

BBB

[Faceman]

Anael,

Indeed the alpha channel seems to be a problem. The image set that
generated the crash does indeed have alpha channels (they were output
by enfuse, btw). I just tried 0.9.2 on a set without alpha channels
and it worked just fine.

I, too, use Canon DPP to process RAWs, but usually just to 8-bit TIFF.
I am not sure why enfuse added an alpha channel (it's a totally empty
alpha channel, btw), but the alpha channel does screw up panomatic.

Nice detective work! Hopefully future versions will overcome this, or
I'll have to look for a batch way of removing alpha channels.

[ArAgost]

On Mar 6, 12:53 am, Naouel <anael.orlin...@gmail.com> wrote:
> Two things :
>
> 1.
> 0.9.3 is out. With some suggested features that will speedup
> detection.

Tried it right now. It's *fast*. And by fast I mean that generating
almost 2k CPs across 20 (quite overlapped) images took less than 90 s
on my macbook. For a comparison, Autopano took almost 10 minutes to
connect 10 of those images, with a worse spread. Quality seems pretty
high, though I don't have previous experience with your utility. Well
done!
Now the only problem is that with 2000 CPs the OS X version tends to
crawl... (see bug ticket here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1908721&group_id=77506&atid=550441),
but that's not your fault :)