AlexandreJ wrote:Can you share this case Andrew ?
AlexandreJ wrote:Okay. Complicated case and complicated to solve. The story :
- in v2.0.9, the support for roll parameter in xml was rather limitated => in fact, wasn't used at all.
- in v2.5.0, this roll support has been extended.
This shooting seems to have recorded wrong roll values, giving so initial location for each images quite wrong ( reversed +180° ).
The optimizer then has a wrong initial state which has also a good minimal solution ( local not global ).
In v2.0.9, as the initial state was not using roll, it worked, in 2.5.0 series, it didn't because of that fact.
I added a new option in papywizard to solve such case : 'use recorded location'. this option tells the software to use as a starting point the recorded location or just to do a standard optimization. It then works great with 2.5 version.
AlexandreJ wrote:fixed for RC release
AlexandreJ wrote:If unckecking use recorded location ( means roll parameters )
AlexandreJ wrote:In the RC version, if you hit one of the turn left, turn right button, it will say that exif rotation won't be used for orientation.
AlexandreJ wrote:Yes. That's due to the underlying file reading library. We made the chose to always use exif orientation everywhere in the software ( it would be complicated to remove that just on the papywizard plugin). That's why you have this mix. So we need to cope with the consequences.
mediavets wrote:I don't really see why you can't instead use the orientation value from the Papywizard data file for the Papywizard Import wizard/filter. When you say "it would be complicated to remove that just on the Papywizard plugin" does that mean you not consider the Papywizard Import wizard/filter important enough to make the effort? It wouldn't really matter whether you set all images to portrait orientation or all images to landscape orientation because the user could rotate them if required, the point is that all images should have the same orientation.
mediavets wrote:I may be mistaken (I hope I am) but I have the impression that Kolor has invested a lot of development effort in refining the Gigapan Import wizard/filter and very much less effort in the Papywizard Import wizard/filter despite your selling the latter system and not the former.
You reported that the RC version of the Papywizard Import wizard handled my church roof dataset perfectly - well it doesn't when I try it. The fact is that the APG 2.0.9 version of the Papywizard Import wizard/filter - which you claim is less sophisticated than the V2.5 RC version - still handles this church roof data set very much better than the V2.5 RC version of the Papywizard Import wizard/filter.
mediavets wrote:If the Papywizard Import wizard/filter is still not quite right I'd rather you said so than claim it to be close to perfection when it plainly isn't.
mediavets wrote:1. It doesn't seem to make any difference what the roll values are - if I don't uncheck the 'Use recorded locations' flag I can't get a good result. Does that make sense? So the issue doesn't seem to relate to incorrect roll values but perhaps is down to the fact that the images do not all have the same orientation in the EXIF because having the Merlin head on its side and the camera facing upwards confuses the camera orientation sensor. Would it be better to disable the camera orientation sensor?
mediavets wrote:2. It doesn't seem to make any difference what value is set for the Head Orientation field in the data file. Does the Import filter use that value at all? If not why not?
mediavets wrote:3. What is the implication of unchecking the 'Use recorded location' flag - if it is unchecked which values in the Papywizard data file are used if any?
AlexandreJ wrote:As said before, we cannot disable easily in Autopano engine the fact that we use everywhere the camera orientation sensor for reading image. It would be disabled everywhere, not only in one part.
So, disabling the camera sensor directly in the camera could be a perfect solution.
AlexandreJ wrote:mediavets wrote:2. It doesn't seem to make any difference what value is set for the Head Orientation field in the data file. Does the Import filter use that value at all? If not why not?
No, I don't use this value yet. I rely on the roll value per image.
mediavets wrote:If the camera image orientation sensor is disabled then what orientation will be given to images by APP/APG?
mediavets wrote:Aside from shooting position Y/P/R co-ordinates values, which of these Papywizard data file values do you make use of at present?
<sensor coef ratio>
<nbPicts pitch yaw>
<overlap minimum pitch yaw>
Users browsing this forum: No registered users and 2 guests