klausesser wrote:

Positioning locations are very carefully and precisely determined by the head. So detecting CPs is redundant.
best, Klaus

I doubt that its possible to get a nice rendered sphere using the XML only. Most likely it is necessary to do some finetuning/optimizing.
The image below show what I get when I do an import using the XML from the VR drive 2, without any optimizing at all.  The rendered pano is unusable.
Maybe Josef's can do it better, but I doubt it will be usable without some kind of optimizing. Time will show.

leifs

leifs wrote:

I doubt that its possible to get a nice rendered sphere using the XML only. Most likely it is necessary to do some finetuning/optimizing.

What would we otherwise need xml for if not for precise positioning? If "finetuning and optimizing" kills already correct positioned cps i´m wondering about for what it´s really useful!?
If i have head which very precisely positions the camera and which writes very exact positioning files because of that: tell me the reason why the optimizer doesn´t optimize but kills these alreadx very exact positioned cps?

leifs wrote:

The image below show what I get when I do an import using the XML from the VR drive 2, without any optimizing at all.  The rendered pano is unusable.
Maybe Josef's can do it better, but I doubt it will be usable without some kind of optimizing. Time will show.

I don´t know whether Josef´s head can do it better - the VR drive is very precise anyway.

I know people who have made themselves templates to use them in PTGui resp. PanoTools with the use of minimal optimization. I saw them stitching spherical panos in minutes and high-res mosaics effortlessly also
needing just a minimum of optimization.
They use minimalized manual heads and let their cameras/lenss fixd to them all the time.

I guess one of the reasons which rise issues is comes from wanting to be as flexible as possible in terms of cameras and lenses. Here the calculating quality of a controlling device, the precision of an alignment of camera/lens on the head and of course the precision of the head are definitely essential.

I can´t imagine any logical reason for your issues besides of having an alignment-mismatch, an issue with mechanics or a calculation-issue or - more likely - an issue with the settings in APG. I doubt it´s a real application issue basically but a problem which rises whith the meanings of several settings. Here i experienced to need the try and error method to find what to do in which situation. The descriptions are very vague.

We need a (!)good(!) handbook and/or a (!)well made(!) tutorial ehich goes into details. The speedy progress of the appication makes that difficult to do, i understand.

best, Klaus

klausesser wrote:

leifs wrote:

I doubt that its possible to get a nice rendered sphere using the XML only. Most likely it is necessary to do some finetuning/optimizing.

What would we otherwise need xml for if not for precise positioning? If "finetuning and optimizing" kills already correct positioned cps i´m wondering about for what it´s really useful!?
If i have head which very precisely positions the camera and which writes very exact positioning files because of that: tell me the reason why the optimizer doesn´t optimize but kills these already very exactly positioned cps?

leifs wrote:

The image below show what I get when I do an import using the XML from the VR drive 2, without any optimizing at all.  The rendered pano is unusable.
Maybe Josef's can do it better, but I doubt it will be usable without some kind of optimizing. Time will show.

I don´t know whether Josef´s head can do it better - the VR drive is very precise anyway.

I know people who have made themselves templates to use them in PTGui resp. PanoTools with the use of minimal optimization. I saw them stitching spherical panos in minutes and high-res mosaics effortlessly also
needing just a minimum of optimization.
They use minimalized manual heads and let their cameras/lens fixd to them all the time.

I guess one of the reasons which rise issues comes from wanting to be as flexible as possible in terms of cameras and lenses. Here the calculating quality of a controlling device, the precision of an alignment of camera/lens on the head and of course the precision of the head are definitely essential.

I can´t imagine any logical reason for your issues besides of having an alignment-mismatch, an issue with mechanics or a calculation-issue or - more likely - an issue with the settings in APG. I doubt it´s a real application issue basically but a problem which rises whith the meanings of several settings. Here i experienced to need the try and error method to find what to do in which situation. The descriptions are very vague.

We need a (!)good(!) handbook and/or a (!)well made(!) tutorial ehich goes into details. The speedy progress of the appication makes that difficult to do, i understand.

best, Klaus

XML from the VR Drive is only to the nearest 0.1 degree. I can't imagine that would be accurate enough for stitching without further optimisation using control points.

Accurate stitching needs to be pixel perfect - must be at least another couple of orders of magnitude of detail.

klausesser wrote:

gddxb wrote:

XML from the VR Drive is only to the nearest 0.1 degree. I can't imagine that would be accurate enough for stitching without further optimisation using control points.

Accurate stitching needs to be pixel perfect - must be at least another couple of orders of magnitude of detail.

Yes - i know

best, Klaus

Then I muat be misunderstanding what you're saying.

I thought your point was that with accurate heads, all that would be needed would be the XML to carry out a satisfactory stitch?

I've just shot a full spherical with a 300mm lens on a 1D Mk IV. At a guess, that's probably in the single digit arc-second FoV per pixel. No head will deliver that. And even if it did, vibration would kill thr accuracy.

Apologies if I've misinterpreted what you've been saying.

Hi Klaus
Thank you for this hint to Josef's project. I didn't read that before.
About this problem with prepositioned images from XML: For definitively stitching it could never be the solution. Pixel sharpness with modern DSLR means a angular accuracy of about the angle of view divide by the resolution. So we are in the digits of an degree - with fisheyes. When using a 600mm tele, we are in the digits of an arc second.
Our best Leica theodolites (surveying equipment) are in the range of this accuracy (1/10'000 degree). A panoramic head is probably never be able to achieve this.
But very interesting could be a new function in APG that can hold (over anchor points ?) the XML position from images with bad CP's. And it should hold the position relativ to the neighbour images wich are well positioned over the CP's. This could be the solution for all our problems (and many hours of fumbling around) with sky- or near out of focus grass-images ;-)
What do You thing about this ?

Last edited by lumelix (2012-01-05 09:47:45)

Here is a small annoyment in the Papywizard import as of today:
when shooting a sphere the rows above 60-70 deg the camera will erroneously record the images in landscape mode.
Ofcourse all images are shot in the same mode (portrait) and the XML from the head states roll="90.0" for all images.

But the Papywizard import use the EXIF, not the XML, and therefore lines up the upper rows in landscape mode.
I can rotate the images 90 deg CCW before importing them, but in my opinion this should not be neccesary.
The Papywizard import should use the XML and put all images accordingly.

leifs

AlexandreJ wrote:

Yes, this is complicated because we rely first on the mercury sensor inside exif. So the orientation can change also because of that sensor.
We need to find a way to authorize the use of this sensor in general mode and disable it when done through papywizard.

Hi Alexandre!

Regarding to avoid the use of any automated settings on the camera it would be logical to switchoff the import of any automated function to the stitcher i mean . . . .
Especially if they do what THEY like . .

best, Klaus

Last edited by klausesser (2012-01-09 14:31:41)

klausesser wrote:

As i remenber you use the Seitz VFR drive 2? Isn´t there a dedicated import-module, as it is with the Rodeon head?
Are you sure PapyWizard is the best import for the Seitz?

best, Klaus

Yes I use a VR drive 2, and it produces XML-files in the Papywizard syntax. Therefore it is the only option and as far I can see this import transfers all the information that the head has about each image:  pic-number, bracket, yaw, roll, pitch  (in the xml head there are info on lens-type, focal, ..)
In APG there are three other import plugins: Clauss, Gigapan, Panotools
I don't know much about them, but what other info can they provide ?
I guess the only difference is the syntax.

leifs

gddxb wrote:

When it all comes together, this combination is amazing.

Just stitched a 61.4 gigapixel image.

Hi!

Which combination are you talking of?

best, Klaus

To Leifs ( first poster in this topic ) : I analysed this case with your files ( images / xml ). Several problems in fact, but all have a solution :
- One bug in autopano that prevent the straight usage of the XML generated by the VRDrive : it doesn't store the sensor scale, so I need to cope with this case too.
- Sources images are in tiff without exif. Or the focal length stored in the XML is 50mm. The images are 100mm. Autopano has then some trouble figuring out itself that the provided focal is not the right one. It is supposed to be good first in the images ( no exif here ), then in the XML file ( 50mm wrong ). You need to patch the XML in this case

2.6.1 version should have everything ready to treat this case in one click ( assuming the XML is patched ).

AlexandreJ wrote:

- Sources images are in tiff without exif. Or the focal length stored in the XML is 50mm. The images are 100mm. Autopano has then some trouble figuring out itself that the provided focal is not the right one. It is supposed to be good first in the images ( no exif here ), then in the XML file ( 50mm wrong ). You need to patch the XML in this case

Hi Alexandre!

Does that mean the information in the head´s xml is not read out completely by the import-module and APG instead relates on the picture´s EXIFs? The head´s xml contain information about sensor and focal-length.
Using only the picture´s EXIFs means trouble for those users who combine cameras and lenses of different brands which don´t provide EXIFs at all!

When there´s sensor and lens information in the xml: why not use it?

best, Klaus