apsc testing: Array out of bounds
Pete Holzmann
images.
During comparison of image #1 and image #10, I got a
simple "Array out of bounds" message and the process
died.
(Sorry, I'm not set up to build and test more intensely
;))
Pete
Seb Perez-D
> I tried a command-line apsc test with a larger number of
> images.
>
> During comparison of image #1 and image #10, I got a
> simple "Array out of bounds" message and the process
> died.
Hi
What version of apsc are you using? what operating system? how many
images? what was the command line used?
Thanks
Seb
Pete Holzmann
>What version of apsc are you using? what operating system? how many
>images? what was the command line used?
OK, here's a small contribution I can make.
A link to a set of test photos for our use:
http://picasaweb.google.com/Almagre.Bristlecones.2007/TestPano?aut
hkey=MKAOfAwe_kw
(If you read this too soon after I post, some of the photos will
not yet be uploaded -- it is happening as I write :))
Seventy photos that ought to make up a panorama. Subsets also are
useful.
If you login to picasaweb, you will find links to download the
entire album in original form (6mpxl images with Exif, etc). These
are unretouched, straight from my Fujitsu f31fd.
For my apsc testing, I began with the first three images, then
moved on to the first ten.
I'm running WinXP SP2 with all patches. 2GB RAM.
Current apsc version is as included in the current Hugin test
install dated 080208. apsc.exe dated 080207, 5:00pm
I hope that helps!
Pete
Stephan Hegel
Pete Holzmann wrote:
> OK, here's a small contribution I can make.
Thanks, Pete, for providing this set of test images.
> A link to a set of test photos for our use:
> http://picasaweb.google.com/Almagre.Bristlecones.2007/TestPano?aut
> hkey=MKAOfAwe_kw
>
> ...
>
> If you login to picasaweb, you will find links to download the
> entire album in original form (6mpxl images with Exif, etc). These
> are unretouched, straight from my Fujitsu f31fd.
Somebody out there who can make the images available without signing
up for picasaweb ?
I would like to add them to my little test bed and run it through
apsc on my x86_64 Linux box.
Regards,
Stephan.
Seb Perez-D
> If you login to picasaweb, you will find links to download the
> entire album in original form (6mpxl images with Exif, etc). These
> are unretouched, straight from my Fujitsu f31fd.
I am logged in in Picasaweb, but I cannot see the link to download the
entire album. I can see in eash photo the link to download a single
image, but I am not going to download by hand 70 images!
An FTP access would be great.
If you understand a bit of french, I could recommend http://dl.free.fr/
In "fichier a envoyer" you put a zip file with all the images and put
your email address in "Me notifier du lien par email:"
Also, what command line options did you choose? have you tried setting
--maxdim 1200 for example?
Cheers,
Seb
Pete Holzmann
>> If you login to picasaweb, you will find links to download the
>> entire album in original form (6mpxl images with Exif, etc). These
>> are unretouched, straight from my Fujitsu f31fd.
>Somebody out there who can make the images available without signing
>up for picasaweb ?
Your wish is my command :)
The hard way:
ftp://ftp.ds.org/hugin
The easy way:
ftp to ftp.ds.org
login anonymous
cd hugin
grab the files
(Upload in progress right now)
Tom Sharpless
of) does not seem to make the best use of memory, and so is just not
suitable for big jobs (lots of images, or big ones). Nor does it seem
to generate any better control points than autopano, etc., indeed
perhaps not as good (it rarely finds the same ones over again; but if
there were such a thing as some "best" points one would expect the
program to find them repeatably). So I'd recommend using one of the
other control point finders for the time being.
Regards. Tom
Pete Holzmann
>> For my apsc testing, I began with the first three images, then
>> moved on to the first ten.
>
>As it stands, autopano-sift-c (which APSC is just a variant packging
>of) does not seem to make the best use of memory, and so is just not
>suitable for big jobs (lots of images, or big ones).
If ten 6mpxl images is a "big" job, then I seriously wonder about
its utility at all. I provided the complete set of photos for
testing purposes... have not yet tested more than ten images.
With respect to control point finding: I have noted that lots of
people are using a reduction to 800 pixels. In my testing, that's
fine for very simple images.
But (for example) when testing the first three images of my set, I
get *no* control points for the first image pair if I reduce to
800, but a pretty nice set of points if I leave it full size.
>...So I'd recommend using one of the other control point
>finders for the time being.
That's fine for production. Right now, I'd like to help make progress in
improving the situation :-D
Blessings,
Pete
Stephan Hegel
Pete Holzmann wrote:
>> Somebody out there who can make the images available without signing
>> up for picasaweb ?
>
> Your wish is my command :)
Thanks :).
> The easy way:
> ftp to ftp.ds.org
> login anonymous
> cd hugin
> grab the files
> (Upload in progress right now)
Another easy way:
wget --recursive --level=2 ftp://ftp.ds.org/hugin
(Download in progress right now)
Rgds,
Stephan.
Seb Perez-D
> As it stands, autopano-sift-c (which APSC is just a variant packging
> of) does not seem to make the best use of memory, and so is just not
> suitable for big jobs (lots of images, or big ones).
I've successfully used apsc for projects with 81 10MP images, and
resulting in one component and no spurious control points, so I guess
your mileage may vary ;-)
Seb
Seb Perez-D
> With respect to control point finding: I have noted that lots of
> people are using a reduction to 800 pixels. In my testing, that's
> fine for very simple images.
>
> But (for example) when testing the first three images of my set, I
> get *no* control points for the first image pair if I reduce to
> 800, but a pretty nice set of points if I leave it full size.
Running APSC on your first three images like this
APSC --maxdim 800 test.pto ftp.ds.org/hugin/DSCF676[1-3].JPG
I get one component:
Connected component identification resulted in 1 component:
component 1: /DSCF6761.JPG, /DSCF6762.JPG, /DSCF6763.JPG
With the first 9 images, it also works as expected, one component
found as well, and no crash.
Pete, what was exactly the command line you used? could you paste the
error -or the last lines before the crash?
Thanks for helping us with this!
Cheers,
Seb
Stephan Hegel
Pete Holzmann wrote:
> With respect to control point finding: I have noted that lots of
> people are using a reduction to 800 pixels. In my testing, that's
> fine for very simple images.
>
> But (for example) when testing the first three images of my set, I
> get *no* control points for the first image pair if I reduce to
> 800, but a pretty nice set of points if I leave it full size.
>
Sorry, I can't confirm this. I've run apsc from within hugin with the
first three images of your test set with --maxdim=800 (which is the
default, BTW) and I do get useful control points.
Same with the first ten images.
Hmm, more testing is just going on ...
Rgds,
Stephan.
Stephan Hegel
My observations:
I've just fed Pete's 70 6MP images into apsc with --maxdim=1200 and after
30 minutes or so it has been done. Aligning the images afterwards reports
"bad fit". However, so far I haven't detected wrong control point pairs -
so it can be done. It might be that those images are all handheld shots
with parallax errors.
Max memory consumption reported by atop is about 430MB.
When using apsc's --refine option together with --maxdim=1200, memory
consumption shots up and my 2GByte RAM box starts swapping. Memory usage
increases step by step and finally the whole process stops with an error.
When starting apsc with --maxdim bigger than the max size of the provided
images (e.g. 3000) and leave the --refine option out it takes ages to finish
but it does, eventually (... but still "bad fit" ...).
Regards,
Stephan.
Harry van der Wolf
images.
When I login I get the following message:
220---------- Welcome to Pure-FTPd [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 07:15. Server port: 21.
220 You will be disconnected after 15 minutes of inactivity.
USER anonymous
230-Welcome. This is a limited-access FTP site for friends of DataServe.
230 Anonymous user logged in
However, when trying to download I always get the error:
550-The load was 5.83 when you connected. We do not allow downloads
550-by anonymous users when the load is that high. Uploads are always
550 allowed.
I already logged in about 5 times over the last evening and today,
both with a commandline FTP and with a GUI-FTP (cyberduck).
The server mentions that I'm user 1 (once I was user 2), so is it
some sort of setting I need to change?
Harry
Seb Perez-D
> I've just fed Pete's 70 6MP images into apsc with --maxdim=1200 and after
> 30 minutes or so it has been done. Aligning the images afterwards reports
> "bad fit". However, so far I haven't detected wrong control point pairs -
> so it can be done. It might be that those images are all handheld shots
> with parallax errors.
Pete's images stitch nicely - although there is a bit of parallax
error it is tolerable. Here is how it stitched (I added a piece of sky
that was missing). This was with maxdim 800.
http://farm3.static.flickr.com/2134/2254266205_6163e837d0_o.jpg
ArAgost
DSCF67[61-70].JPG fed into APSC (revision 2804).
-Test #1:
APSC --maxdim 800
Went straight.
-Test #2:
APSC --maxdim 800 -- align
Went straight. Alignment recognized correctly the first row (1-5).
-Test #3:
APSC --maxdim 800 --align --refine.
After RANSAC, but before refining, this popped out:
Connected component check...
DSCF6761.JPG, /DSCF6768.JPG
/DSCF6769.JPG, /DSCF6770.JPG, /DSCF6764.JPG, /DSCF6765.JPG, /
DSCF6766.JPG
Searching for matches between /Users/ago/Desktop/pano/DSCF6761.JPG-/
Users/ago/Desktop/pano/DSCF6762.JPG
NOT found!
WARNING: Failed to build bondball as requested. No pre-aligning of
images
takes place.
(refining went on straight and file got written ok)
This seemed to me quite odd, so I tried some more runs of Test #2.
It appears that about 50% of the time the pre-aligning fails, in a non-
predictable way. Anybody knows why?
-Test #4
APSC --maxdim 2000 --align
Went straight.
Upon opening the corresponding output files, Hugin always shows a
blank preview and the "images are connected by n control points.
Images or control points have changed, a new alignment is necessary."
Is this right? Shouldn't the pre-aligning avoid this?
However I did press the align button, and these are the results.
-Test #1:
322 control points. Inspecting control points pairs in the appropriate
tab shows that they fit quite loosely.
After I pressed the align button: Mean error 4.3 pixels, max error
19.1, preview window shows no macroscopic problem (i.e. no omelette).
-Test #2:
318 control points. Still a bit loose (like in test #1).
After I pressed the align button: Mean error 90.8 pixels, max error
647.2, preview window shows no macroscopic problem (though not as good
as case #1). Seems like control points between DSCF6761 and DSCF6762/
DSCF770 are at a distance of ~ 650 px. WTF?
-Another run of Test #2:
Roughly the same as #2.
-Test #3:
306 control points. Still not pixel perfect (but maybe that's just my
fault to keep comparing it to manually insterted and refined control
points).
After I pressed the align button: Mean error 3.9 pixels, max error
15.2, preview window shows no macroscopic problem.
It's worth noting that DSCF6761 and DSCF6762 are without control point
pairs, and those in DSCF6761 and DSCF770 are ok. Looks like refining
took the impossible situation that came out of test #2 and, uhm,
refined it.
-Test #4 :
306 control points. Control points *seem* to be paired more precisely,
but that's hard to say.
After I pressed the align button: Mean error 121.4 pixels, max error
681.4, preview window shows just a "step" on the small construction on
the right side. Looks a lot like example #2. DSCF6765 and DSCF6766, 68
and 69 have no control points in common.
Can anybody explain me something about the results I obtained? They
seem odd to say the least.
Pete Holzmann
>Running APSC on your first three images like this
> APSC --maxdim 800 test.pto ftp.ds.org/hugin/DSCF676[1-3].JPG
>I get one component:
> Connected component identification resulted in 1 component:
> component 1: /DSCF6761.JPG, /DSCF6762.JPG, /DSCF6763.JPG
>
>With the first 9 images, it also works as expected, one component
>found as well, and no crash.
>
>Pete, what was exactly the command line you used? could you paste the
>error -or the last lines before the crash?
As others discovered... with --refine it crashes.
I was always using --refine, (thinking that's best for high quality
control points)... and trying varying levels of maxdim.
For me, with --refine --maxdim 800, I get CP's linking 6762 and 6763, but
6761 is disconnected.
My next attempt was with ten (not nine) images, and I got the "Array out
of bounds" error previously reported.
From the various tests, it would appear that:
* Without --refine, it works reasonably well
* With --refine, we've got trouble
* There's still a need to improve distribution of control points.
As you can see, the alignment of the balcony rail and roofline
leaves something to be desired.
(For some reason, the keypoint algorithms rarely use
corners that to my eye are the obvious alignment points!)
Pete Holzmann
>
>I wanted to do my share of testing on OSX, but I can't download the
>images.
You were probably logging in during a system backup process or
something. I haven't seen that "too loaded" error before. My
apologies! This is a shared service; I have no control over that
message.
If anyone has trouble, please email me -- I'll set you up with a
non-anonymous ftp login so you won't have this issue.
Pete
Pete Holzmann
>Pete's images stitch nicely - although there is a bit of
>parallax error it is tolerable. Here is how it stitched (I
>added a piece of sky that was missing). This was with
>maxdim 800.
Well yes, it was a set of hand-held shots. Probably 10-15 cm of
shift as I turned in various directions.
>http://farm3.static.flickr.com/2134/2254266205_6163e837d0_
>o.jpg
Very cool, Seb!
This brings up a couple of thoughts:
* Sky-fill is always an interesting challenge. Hi-rez sky
is impossible (since there's nothing to CP with).
* In the past, I've had trouble trying mixed-resolution images.
It seems reasonable to zoom out and take a set of wide angle shots
specifically to catch a large area of sky... and stitch those in
the background of the main panorama. Perhaps this could also work
for lake waters and such.
Question: has anyone attempted this with success? Any hints? I've
always had trouble, I think because there's nothing to say which
image resolution takes precedence. (Of course I would want the
background image to be pixel-stretched...)
Thanks,
Pete
Harry van der Wolf
Op 10-feb-2008, om 22:50 heeft Pete Holzmann het volgende geschreven:
>
> On 10 Feb 2008 Harry van der Wolf said...
>
>>
>> I wanted to do my share of testing on OSX, but I can't download the
>> images.
>
> You were probably logging in during a system backup process or
> something. I haven't seen that "too loaded" error before. My
> apologies! This is a shared service; I have no control over that
> message.
>
It worked after all. Took some time and some tries.
Let you know
Harry
Stephan Hegel
Seb Perez-D wrote:
> Pete's images stitch nicely - although there is a bit of parallax
> error it is tolerable. Here is how it stitched (I added a piece of sky
> that was missing). This was with maxdim 800.
>
> http://farm3.static.flickr.com/2134/2254266205_6163e837d0_o.jpg
Yes, this this looks really good.
Could you please describe shortly the technique you were using to fix
the missing piece of sky ?
Rgds,
Stephan.
Seb Perez-D
> Could you please describe shortly the technique you were using to fix
> the missing piece of sky ?
I use a Gimp plugin called Resynthesizer
http://www.logarithmic.net/pfh/resynthesizer
If you use it on too large images it will fail, so be reasonable and experiment.
On Sun, Feb 10, 2008 at 10:57 PM, Pete Holzmann <pete-...@icta.net> wrote:
> * In the past, I've had trouble trying mixed-resolution images.
>
> It seems reasonable to zoom out and take a set of wide angle shots
> specifically to catch a large area of sky... and stitch those in
> the background of the main panorama. Perhaps this could also work
> for lake waters and such.
gadl has done this in hugin - prepare to bring your computer to a
crawl if you try it too ;-)
http://www.flickr.com/photos/gadl/1391492038/in/pool-extremelylargepanoramas
Cheers,
Seb
Harry van der Wolf
Please correct the cmake configure step for APSC/autopano/generatekeys so that malloc is detected correctly (or hack it in such a way that it is written to config.h anyway)
Yuval Levy
> On small image sets (up to 15) APSC works fine.
SVN2841 worked great on 45 images in Windows's command line when those
images were in the same folder. When the images where across three
folder, hugin seemd not to pass properly the parameters to APSC.
Yuv
Harry van der Wolf
software as it does not use the correct memory allocation on OSX.
Don't ask me the details as I'm not a programmer, but my work-around
to the config.h fixed it, which means it was taht actual bug. Maybe I
should file a report to the bugtracker.
Harry
2008/2/14, Yuval Levy <goo...@levy.ch>:
Pablo d'Angelo
Harry van der Wolf schrieb:
> This is not what I mean. My mail dealt with a(nother) bug in the
> software as it does not use the correct memory allocation on OSX.
> Don't ask me the details as I'm not a programmer, but my work-around
> to the config.h fixed it, which means it was taht actual bug. Maybe I
> should file a report to the bugtracker.
I don't really understand how simply defining HAVE_MALLOC fixes this
problem, especially since this define is not checked in the autopano-sift-c
source code. Is it checked by the system headers on OSX?
Usually the HAVE_* defines only affect the programs and not the the system
libraries. Very strange. Further information would be greatly appreciated.
Google tells me that realloc() behaves differently on OSX than on linux, but
other than that I haven't found further explanations.
Anyway, I have just added a
#define HAVE_MALLOC
to config.h (OSX only). SVN 2881
Can you elaborate a bit on the enblend problem, too? I haven't heard of
memory problems related to this issue in enblend before. Also enblend does
not use realloc at all.
> Harry
>
> 2008/2/14, Yuval Levy <goo...@levy.ch>:
>> Harry van der Wolf wrote:
>> > On small image sets (up to 15) APSC works fine.
>>
>> SVN2841 worked great on 45 images in Windows's command line when those
>> images were in the same folder. When the images where across three
>> folder, hugin seemd not to pass properly the parameters to APSC.
I just tried (with current SVN) and it worked fine with images in different
folders (under windows).
ciao
Pablo