Page 1 of 1

Import Wizard failure

PostPosted: Sat Dec 31, 2011 4:10 am
by jriley
I have a pano shot with 344 pictures using a Merlin head with Papywizard. When I use the Import Wizard, everything looks normal in the preview after loading the XML file and images (See first image below). I checked the detection options to "Auto detection Skip optimization Use recorded location" (see second image below). I always deselect optimization because unlinked images (e.g. the sky) go off to crazy places if optimized.

After I click the Finish button, APP churns for an extremely long time (compared to what I have experienced in the past) to detect control points. When it is finished, the pano looks like the third image below, where it seems every single image is right on top of all of the others (the FOV is 7.92x5.94°).

Here is what is odd: I initially ran this through APP using my old 2.52 version. After detection, the images were in the appropriate grid pattern, but I had forgotten to put in the focal length of the lens (I am using an Olympus E-P2 with an old Olympus Pen manual 250mm lens, so it isn't in the EXIF data.) Since I had gotten a notice that an update was available, I downloaded APP 2.6 and imported the XML and images again, resulting in the aforementioned stack of images instead of the grid layout. I tried going back to APP 2.52, which I hadn't deleted, and now it had the same result too!

I have tried using a fresh copy of the XML file, thinking maybe it had gotten corrupted. No difference. Any ideas or help appreciated.

I have put the .pano and the Papywizard XML file in my Dropbox at http://dl.dropbox.com/u/559761/panofiles.zip

PostPosted: Sun Jan 01, 2012 11:58 pm
by jriley
I downloaded the AutoPano Giga trial, repeated the import, got a similar result. See image below.

PostPosted: Tue Jan 03, 2012 3:13 pm
by AlexandreJ
* speed issue : What is your default detection quality ? Didn't you raise this to high which explain why it's slow.
* If you have dust on the lens, on full blue sky, we detect that and we try to stitch image together pilled up. This may also explain this issue.
Try to use papywizard import without optimization checked to inspect the links before optimization.

PostPosted: Tue Jan 03, 2012 6:06 pm
by jriley
I had the detection level set to normal. I was using tiffs; could that be slowing it down? I have tried it again with jpegs and it doesn't seem that much faster. Dust on the sensor isn't an issue - the E-P2 shakes it off the sensor and I don't see any in the pictures; plus, I am already doing the Papywizard import without optimization.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't want to muddy the issue, but I wanted to test Papywizard importing in general, so I ran a series of shots using all of the different presets in Papywizard (with my Rokinon 7.5mm fisheye) and imported them. The results were, shall we say, interesting.

The Import Wizard preview always showed the correct arrangement of images (just as with the gigapixel in this thread.) I did all imports without optimization. Most of the detected panos looked normal, but a couple of panos were pretty messed up.

One thing I noticed for all of them, even in the ones that looked OK, was that the angles were not the same as the ones in the Papywizard XML file. The roll for each image in the XML is 0°, but is approximately 90° (but not the same for all) in the detected pano. Is that because the camera was in portrait orientation? Another observation is that the yaw and pitch, though similar to the values in the XML file, are different. Is some sort of transformation being done on the Euler Angles? In the ones where the detected pano is messed up, the detected angles are are far off from the XML values.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So, I am still stumped.

PostPosted: Wed Jan 04, 2012 12:39 am
by mediavets
Does your camera have an orientation sensor? If it does you may be better off disabling it if that is possible.

PostPosted: Wed Jan 04, 2012 1:03 am
by jriley
mediavets wrote:Does your camera have an orientation sensor? If it does you may be better off disabling it if that is possible.

It does have one, but I made sure all of the images were oriented the same way in Lightroom. Still, they would all be the same since the pitch is fairly horizontal for all. The orientation wouldn't be the cause of the problem here anyhow, as far as I can imagine. The problem here is that they are all virtually at the same position, despite the fact that I didn't have APP optimize the pano. They should all be in the position given in the Papywizard XML file. I checked the XML to be sure that it doesn't have something crazy in it and it seems fine (as seen in the Import Wizard preview too!)

It really seems that the files from Papywizard are fine, but for some reason APP isn't positioning the images correctly. :(

PostPosted: Thu Jan 05, 2012 5:39 pm
by jriley
Still hoping for some help. I tried it again with the same results. I wanted to note that the RPY of every single image was 0,0,0 exactly. Since there was no optimization, this is the actual imported result and quite different to that in the Papywizard XML file.

PostPosted: Wed Jan 18, 2012 9:09 pm
by jriley
Still no ideas? Anyone from Kolor willing to take a look at it? I could upload (reduced-sized if needed) jpegs and the xml file. You don't even really need my jpegs, since it isn't optimizing; you could just use some place-holders.

PostPosted: Thu Jan 19, 2012 5:38 pm
by AlexandreJ
Yes, please upload the low res to the ftp. BTW : I found a bug in papywizard plugin recently. I patched it for next 2.6.1 release.
Perhaps it's already solved, but still upload them so I'm sure I can release the 2.6.1

PostPosted: Fri Jan 20, 2012 12:23 am
by jriley
Thanks - I will do that, once I find the ftp, since I haven't done that before :P

PostPosted: Fri Jan 20, 2012 12:26 am
by gkaefer
jriley wrote:Thanks - I will do that, once I find the ftp, since I haven't done that before :P

see here:
http://www.kolor.com/forum/t766-ftp-server
Georg

PostPosted: Fri Jan 20, 2012 7:48 am
by jriley
I don't think the ftp site is working correctly. I have tried three different ftp clients plus the Mac Finder to connect with no success. It either never responds or wants a name and password, which shouldn't be needed. I have used ftp plenty of times, so I don't think I am doing it wrong.

PostPosted: Fri Jan 20, 2012 9:12 am
by AlexandreJ
ftp is not working as expected. Confirmed. Will be solved today.

PostPosted: Sat Jan 21, 2012 1:55 am
by jriley
FTP is working now and the zip file (containing the papywizard XML and log files, a project file, and reduced-size and highly compressed images) is uploading. If reducing the dimensions of the photos is a problem, I can upload them again - just let me know.

I hope this gets it figured out :D

PostPosted: Tue Jan 24, 2012 1:08 pm
by AlexandreJ
I checked this case. The issue is in the XML file because all pitch angle are in the range [-67 -90] meaning you shot the nadir only ( with heavy distortion, etc ).
This doesn't correspond at all with the content of this panorama which looks like standard landscape photography where you can see the horizon.
So that's the issue with this case. The xml should be patched by adding some value to all pitch angle ( doesn't look like at +90° is the right answer ).

PostPosted: Tue Jan 24, 2012 7:33 pm
by jriley
AlexandreJ wrote:I checked this case. The issue is in the XML file because all pitch angle are in the range [-67 -90] meaning you shot the nadir only ( with heavy distortion, etc ).
This doesn't correspond at all with the content of this panorama which looks like standard landscape photography where you can see the horizon.
So that's the issue with this case. The xml should be patched by adding some value to all pitch angle ( doesn't look like at +90° is the right answer ).

Alexandre - I can see how this XML could result from not setting the reference point on the head, maybe. I assume the head takes the position when powered on to be (0,0,0) and, if I then pitched -90° from the stored position to attach the camera, it would think it was at (0,-90,0), even though I have the camera pointed at the horizon. I must have failed to "Set Reference" to tell it that was (0,0,0) :P

The thing that thew me off from realizing that is that the shots look normal in the import window grid.

Also, can you offer insight into why the positions in the detected panorama were different than the ones in the XML file, even though there was no optimization performed?

Now I have to figure out a way to change all of those pitch values without doing it by hand :(

PostPosted: Wed Jan 25, 2012 9:15 am
by AlexandreJ
jriley wrote:Alexandre - I can see how this XML could result from not setting the reference point on the head, maybe. I assume the head takes the position when powered on to be (0,0,0) and, if I then pitched -90° from the stored position to attach the camera, it would think it was at (0,-90,0), even though I have the camera pointed at the horizon. I must have failed to "Set Reference" to tell it that was (0,0,0) :P

The thing that thew me off from realizing that is that the shots look normal in the import window grid.

Also, can you offer insight into why the positions in the detected panorama were different than the ones in the XML file, even though there was no optimization performed?

Now I have to figure out a way to change all of those pitch values without doing it by hand :(

I agree, it may be a reference point issue. The shot looks normal because I don't deform the image in the small preview, but you can see the coordinates ( theta, phi ) range under the xml file name and see that range is obviously wrong.
Yes, I agree with the last point, I don't know a simple way to do that ( I could quickly patch it here by adding a value during import, but it will product a .pano, not change the XML ).

PostPosted: Sun Feb 05, 2012 3:03 am
by jriley
A final followup: In the end, after advice Papywizard crowd, I ran a simulation in Papywizard with the same number of rows and columns and it looks pretty good. I haven't optimized yet and it looks like the attached image. I am just glad to avoid editing every one of the 344 pitch values in the XML! :P