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.
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.
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 ).