[APG 2.5 b2 WinXP/32] Papywizard Import performance poor vs APG 2.0.9  

Archive of all bug reports. This forum is closed - you cannot create new topics or comments here! If you think a specific topic was moved here by mistake, please contact the moderators!
no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

[APG 2.5 b2 WinXP/32] Papywizard Import performance poor vs APG 2.0.9

by mediavets » Fri Nov 05, 2010 12:48 am

Mosaic pano shot with Merlin orientated on its side of a church roof interior.

Yes, I know the exposure is not quite right nor the white balance.

APG 2.0.9 with Papywizard Import did OK.

APG 2.5 beta 2 with Papywizard Import performed very badly.








Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Mon Nov 08, 2010 5:01 pm

Can you share this case Andrew ?

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Mon Nov 08, 2010 9:03 pm

AlexandreJ wrote:Can you share this case Andrew ?

I have uploaded churchroof03.zip to your FTP server.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Tue Nov 09, 2010 10:48 am

After analysis, I confirm a serious issue with that case. Issue opened : 415

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Mon Nov 22, 2010 7:15 pm

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.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Wed Dec 08, 2010 5:57 pm

fixed for RC release

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Thu Dec 09, 2010 3:32 pm

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.

As I pointed out in my initial report this pano was shot with the Merlin head mounted at 90 degrees to the vertical and camera in portait orientation relative to the head.

You are correct in spottiing my mistake in not setting the head orientation correctly so it was recorded in the Papywizard data file as 'up'.

However I've now tried editing the Papywizard data file to record the head orientation as either' left' or 'right' and the result using the Import wizard is still very poor, and not as good as that achieved with V2.0.9.

It's also noticeable that the image orientation sensor data in the EXIF - which seems to be 'confused' by the upward facing mounting of the camera - seems to be taking precedence over the image orientation value in the Papywizard data file. Is that a correct interpretation of what I see?

How many of these factors does your modified Papywizard Import wizard/filter take into account in the RC version?
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Fri Dec 10, 2010 2:14 pm

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.
So you can manually patch this issue.
If unckecking use recorded location ( means roll parameters ), the xml won't be used as well.

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Thu Dec 16, 2010 1:30 pm

AlexandreJ wrote:fixed for RC release

I don't think so; at least not with APG 2.5 RC on Windows XP/32.

No matter what options I try with that church roof dataset the results are poor.

2.0.9 could do it but 2.5 can't.

Is that progress?




Last edited by mediavets on Thu Dec 16, 2010 2:22 pm, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7884
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Thu Dec 16, 2010 2:45 pm

AlexandreJ wrote:If unckecking use recorded location ( means roll parameters )

wouldn´t it be clever to use more precise descriptions?
I mean "use recorded location" . . i would interprete that as some kind of GPS or so :cool: . . no way to assoziate that with "roll parameters" unless you´re one of the programmers . .

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Thu Dec 16, 2010 3:43 pm

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.

I don't see why the Papywizard Import wizard/filter ever uses the image orienation from the EXIF - when shooting with Merlin Papywizard/Panogear all the images will have the same orientation and that can be defined in the Papywizard data file.

My experience is that even if I use the 'turn left' or 'turn right' buttons the preview still displays the thumbnails in a mix of orientations.


Last edited by mediavets on Thu Dec 16, 2010 3:44 pm, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Thu Dec 16, 2010 3:52 pm

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.

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Thu Dec 16, 2010 5:23 pm

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.

If this post gives the impression of my being rather annoyed that's because I am...

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.

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.

So why is that? Have you failed to incorporate all the fixes to the code in the RC or am I applying the options incorrectly?

The promise of the Merlin/Papywizard/Panogear plus APG combination was that it should/would be capable of producing a near perfect stitch of any image set. But it does not. Why not?

How long is it now since APP/APG first offerdan Import wizard/filter for Papywizard? Do you not consider the refinement of the Papywizard Import wizard/filter worth the effort?

I realise that it may seem a 'small thing' compared to the major revisions of the rendering engine and colour correction and so on (which in itself seems to be something of a mixed blessing at present) but if the Papywizard Import wizard/filter does not - or cannot be made to - work consistently and reliably then it seems to me that the integrity and value of the entire Merlin/Papywizard/Panogear + APG robotic pano photography system is undermined.

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.
Last edited by mediavets on Thu Dec 16, 2010 5:43 pm, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Thu Dec 16, 2010 6:08 pm

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, please calm down. It's not about an effort to make or not. It's about a development. The fact that we remove just for papywizard the use of exif orientation is not a task due to Kolor but the library that we are using to read image.
I find far more cool to have good orientated thumbnail everywhere in the software ( especially in the groups view for example ), than having one example in papywizard that display wrongly oriented thumbnail because shooting the roof.

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.

False. I've spend the same amount of time on both plugin because there are relying on the same code in fact.
This sample has been reported and I said that it's complicated to fix in this version but I found a way to do it by adding a new option to prevent such case to happen. Did you uncheck this option ( called use location recorded. BTW : it should be called 'use roll value', I have to rename that ) ?

Why did it work in 2.0.9 ? Because of a lack of feature in the previous version. It just ignored the roll. That's it.
In this engine, we use the roll, but sometimes as in this case, we could rely on it.

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.

Try the above. I did say I fixed and it is. I rechecked with RC. See the above screenshot ( if works well if you uncheck the above flag to correct the wrong roll in the papywizard ).

We are supporting a lot the papywizard project. Have not doubt about that. In the software as well as for the best package preparation. You'll soon get also better support from us ( we're finishing an good mac installer in dmg format, for example ).



no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Thu Dec 16, 2010 7:31 pm

Hi Alexandre,

You're right I apologize for my outburst, I should 'calm down'.

But...I was feeling very frustrated.

I had tried the option you suggested - unchecked the flag for 'Use recorded location'.

I had edited the Papywizard data file to correct the roll values from 90 to zero.

Neither had made any difference.

However now I have closed APG and restarted it and this time I can get a good result which matches yours if I uncheck the 'use recorded locations' flag.

So I don't know why it didn't work before. Can APG get 'stuck' if earlier attempts at Import in the same sessions use different options or different data files with the same image set?

Some observations and questions:

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?

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?

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?
Last edited by mediavets on Thu Dec 16, 2010 8:11 pm, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Fri Dec 17, 2010 9:27 am

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?

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.
Correcting in the .xml file seems complicated because you need to compensate the roll as reported by the sensor ( one image would have +90, the second -90, the third 0, etc compensating the sensor value so that the combinaison of both value would give always a portrait or landscape layout ).

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: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?

Roll value from each image is not used in fact. They are overwritten by rotate +90 or rotation -90 button.

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Fri Dec 17, 2010 10:00 am

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.

If the camera image orientation sensor is disabled then what orientation will be given to images by APP/APG?
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
mediavets
Moderator
 
Posts: 14289
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Fri Dec 17, 2010 10:40 am

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.

Aside from shooting position Y/P/R co-ordinates values, which of these Papywizard data file values do you make use of at present?

<shooting mode>

<headOrientation>

<cameraOrientation>

<stabilizationDelay>

<startTime>

<endTime>

<timeValue>

<bracketing nbPicts>

<sensor coef ratio>

<lens type>

<focal>

<mosaic>
<nbPicts pitch yaw>
<overlap minimum pitch yaw>
Last edited by mediavets on Fri Dec 17, 2010 10:41 am, edited 1 time in total.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Fri Dec 17, 2010 2:18 pm

mediavets wrote:If the camera image orientation sensor is disabled then what orientation will be given to images by APP/APG?

Good question. I think it will always be one that is in the jpeg raw data. In the jpeg, you have 2 bitmap, the preview and the full data. We will use the orientation of the full data ( meaning the size of this chunk row x column will decide the orientation ).

User avatar
AlexandreJ
Kolor Team
 
Posts: 5918
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Fri Dec 17, 2010 2:22 pm

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?
<shooting mode>
<headOrientation>
<cameraOrientation>
<stabilizationDelay>
<startTime>
<endTime>
<timeValue>
<bracketing nbPicts>
<sensor coef ratio>
<lens type>
<focal>
<mosaic>
<nbPicts pitch yaw>
<overlap minimum pitch yaw>

What I found in my code :
* in shoot element: pict, id, bracket, position, yaw, pitch, roll, time
* in the header / general : title, gps, comment
* in header / camera : sensor, coef, bracketing, nbPicts
* in header / lens : focal
* in header / shooting : cameraOrientation ( but it's used after => I don't do anything out of that value ).


Return to Archive

Who is online

Users browsing this forum: No registered users and 1 guest