lumelix wrote:

Hi Leifs
Is there at the bottom a repeating pattern like grass or anything else, so the CP-detection fails ? It looks like out of focus too. But it's clear that APG don't use the recorded location, but it trys to find CP's ?

Yes, there are grass at the bottom. And shooting a sphere at 100mm (eq) will make the grass out of focus. But I have shot two spheres with different focus and focus-stacked them using Helicon Focus.

Is APG using "recorded location" only when it can't find any CP's at all, and optimizing as usual when there are CP's ? In the sky there is no CP's and the images are lined up fine.

leifs

Last edited by leifs (2012-01-03 10:20:20)

lumelix wrote:

Hi Leifs
Is there at the bottom a repeating pattern like grass or anything else, so the CP-detection fails ? It looks like out of focus too. But it's clear that APG don't use the recorded location, but it trys to find CP's ?

Hi!

nevertheless the xml must write the recorded locations corectly and APG must interprete them correctly. Otherwise writing xml would make no sense . .

I can´t imagine an issue at the VR drive - guess it´s an interpreting- or setting-issue of the import-module.

best, Klaus

klausesser wrote:

leifs wrote:

With a VR drive 2 it is easy to shoot spheres and it is supposed to easy to stitch them using the XML-file from the head. But strange things happens and I am out of ideas.
Have a look at the image below. Everything is ok to image 295 of 354. Then the images are completely scrambled.
I have told APG to use recorded location. Also to delete CP's with RMS>10, therefore the global RMS is ok. But the rendered result is not.
the XML can be inspected at http://www.rundskuer.no/ymse/vrdrive2.xml
Anybody ?

leifs

Hey leifs!

What lens did you use? Maybe the drive´s calculation for three bottom-rows isn´t correct - or the camera/lens moved on the rail . .

best, Klaus

I think either of these would be highly unlikely scenarios - certainly in the instances where I've seen identical behaviour. I'm pretty sure it's something to do with multiple small panoramas being created.

gddxb wrote:

I'm pretty sure it's something to do with multiple small panoramas being created.

Hi!

Don´t know what you mean precisely - could you explain?

best, Klaus

klausesser wrote:

gddxb wrote:

I'm pretty sure it's something to do with multiple small panoramas being created.

Hi!

Don´t know what you mean precisely - could you explain?

The pattern MUST be symmetrical - but the two or three lower rows are chaotic.

So either the head produces an issue here or APG produces an issue while interpreting the head´s xml and
trying to get grip of them (or "on" them?)

best, Klaus

Hi Klaus -

In the example where I had something very similar to what Leifs has shown, despite APG being provided with a full XML file from the VR Drive 2, and despite selecting the "force all images to be in one panorama" option, APG reported that multiple panoramas had been found.

There was the main one (with probably 95% of the images in it), plus at least a dozen instances of panoramas with just two images in them. I believe that these were the images that were wrongly placed - clearly the XML location for the images had been ignored.

I don't think it's anything to do with the lens, nor the head, nor the XML produced - I suspect something is awry with the APG process.

AlexandreJ wrote:

Pretty sure that the sky gives issue because of lens dust. The software detects dust and it creates such ugly distortion because of them.
I have to look at that case more closely, but I'm pretty sure it is the cause.

Hi Alexandre -

But why would APG ignore the XML so dramatically? I thought the whole point of providing XML was to give a guide as to where the images should be placed?

The sphere is symmetrical and the pitch-change in the XML is the same in upper half as in the lower half.

Jump from image 60->61 is 13.0 deg
<pict id="60" bracket="1">
<time/>
<position yaw="346.1" roll="90.0" pitch="52.2"/>
</pict>
<pict id="61" bracket="1">
<time/>
<position yaw="0.0" roll="90.0" pitch="39.2"/>
</pict>

Jump from image 295->296 is also 13.0 deg
<pict id="295" bracket="1">
<time/>
<position yaw="348.3" roll="90.0" pitch="-39.1"/>
</pict>
<pict id="296" bracket="1">
<time/>
<position yaw="0.0" roll="90.0" pitch="-52.1"/>
</pict>

In the detected result the distance between rows 60-61 and 295-296 should be exactly the same, 13.0 deg.
Which it is not.

leifs

Last edited by leifs (2012-01-03 15:39:38)

Screenshot 1 => papywizard plugin : in option I disabled auto-detection to be able to go in group option before detection.
Screenshot 2 => group option : disable everything in optimization 
Screenshot 1 => editor : you can see all images located at the recorded image coordinates with detected control point. One issue in the sky up right.
Screenshot 1 => control point editor on this images pair => delete the pair
Screenshot 1 => go again in optimization and put everything back like in this screenshot.
Screenshot 1 => optimize and done

AlexandreJ wrote:

Screenshot 1 => papywizard plugin : in option I disabled auto-detection to be able to go in group option before detection.
Screenshot 2 => group option : disable everything in optimization 
Screenshot 1 => editor : you can see all images located at the recorded image coordinates with detected control point. One issue in the sky up right.
Screenshot 1 => control point editor on this images pair => delete the pair
Screenshot 1 => go again in optimization and put everything back like in this screenshot.
Screenshot 1 => optimize and done

Hi Alexandre!

In my understanding of the process auto-detection should be disabled by default when positioning xml are used. It´s a contradiction indeed: we wouldn´t need positioning files when we use
CP-detection, do we?

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

I sometimes also face issues by using the wrong settings - because in the case of blue sky the auto-detection "kills" my correct positionings by xml.

best, Klaus

lumelix wrote:

Hi Klaus
What is the angular accuracy of your panorama head ?
I'm reading in the tech spec for the kolor panogear:
Reading precision 0.25 degrees
Applicable mechanical tolerance: from 0,15 degrees to 0,55 degrees

When I'm using the 300mm tele with 2x converter I need a offset of 1,66 degrees between the images.
And in this case, a head-tolerance of 0,55 degrees is a lot - it's too mutch !

So is there an other head with better tolerance ?

Josef´s new head is by far more precise than the Merlin (no wonder: it´s far more expensive too )
It´s in the range of the Seitz VR2 - but i don´t have numbers at hand.
I just called Josef - his wife told me he´s at the gym and will call me back in an hour. Will post his answer here.

best, Klaus

I have no idea why the bottom part is not straight through papywizard plugin. I would need all images to get an accurate answer to that.

lumelix wrote:

Hi Klaus
What is the angular accuracy of your panorama head ?
I'm reading in the tech spec for the kolor panogear:
Reading precision 0.25 degrees
Applicable mechanical tolerance: from 0,15 degrees to 0,55 degrees

When I'm using the 300mm tele with 2x converter I need a offset of 1,66 degrees between the images.
And in this case, a head-tolerance of 0,55 degrees is a lot - it's too mutch !

So is there an other head with better tolerance ?

Josef´s called me back right now:

Mechanical precision is 0,036°
Controller´s positioning- precision is 0,1° (because setting it to mechanical precision would mean heaps of redundance)

A 360° turn makes 10000 steps. They are 100% reproducable because of stepper-motors. So you can shoot several 360° turns one after the other and they are equal.

As an example:
For using a 1000mm lens you need on fullframe: 2,0°/1,5°
For using a 1000mm lens you need on a DX      : 1,2°/0,8°

So even when using a 1000mm lens you´re on the absolutely safe side.

best, Klaus