 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
Pages: 1
I am very glad to see that this new version of APT is now showing my tours in good quaility at regular resolution. I am using partial panoramas e.g. 360 x 150 with no nadir. I have found that maniplulating the fov offset to 30 degrees does a good job in displaying the pano but changing the vertical fov paramater makes little difference and likewise when using the camera parameters. When I run the auto rotation option the tour seem to tilt upward towards the ceiling even when I reduce the offset angle. Is the auto rotation feature dependant on any of the variables, I cannot determine what is causing it to do this.
I would also like to create tours with partial panos with limited horizontal and vertical fov but there do not seem to be sufficent control of parameters to enable the tour not to go into areas that are not to be viewed. For example with a 360 x 120 view the top and bottom of the tour are pinched to a single point, it would be useful to prevent viewing below or above a certain angle.
So it seems to me that at present working with partial panos is problematic without further controls, or may be more information on how the paramaters can be manipluated effectively?
Last edited by BrianLR (2009-05-18 00:28:08)
Offline
Brian,
I think the problem may be that in APT-speak a 360x150 is not a partial pano.
A partial pano in APT-speak would have a HFOV of less than 360.
So if you wish to have a 360 HFOV in the virtual tour I think you would be better off rendering your pano at 360x180 even if you don't have image data covering the entire pano FOV.
If you then want to have some panos with a restricted FOV then crop them in APP/APG before rendering to be a partial pano with the desired max. HFOV (of less than 360) and VFOV (of less than 180) before rendering and import into APT.
I thinnk you may get the results you are looking for.
Last edited by mediavets (2009-05-18 11:18:59)
Offline
Brian,
Had another think about your problem - and have done some experiments - and I believe I have the answer (or at least an explanation).
When APP/ASPG v2.x renders a pano it adds a User Comment tag in the EXIF which records (amongst other things) the pano FOV - see screenshot below.
This data is read by APT to set the HFOV and VFOV for each pano correctly.
BUT... if you post-process the panos from APP/APG before loading them into APT your image editor will most likely not preserve the EXIF pano FOV data so APT then by default assigns a pano FOV of 360x180 which is obviously not correct for any pano with less than 360x180 FOV.
In such cases you will have to enter the correct values for HFOV and VFOV for each pano yourself (in APT GUI); if you don't you'll end up seeing exactly the sort of pano projection problems you describe.
Last edited by mediavets (2009-05-18 02:11:02)
Offline
Renan,
Is there some other form/type of image metadata, XMP perhaps, in which the stuff currently stored in the user Comment tag in the EXIF could be stored which would be more likely to survive the post-processing of pano images?
It is not uncommon that you would wish to post process panos before importing them into APT but without that data (currently in the EXIF before post-processing and usually stripped out by the post-processing) you have to read the EXIF before post-processing, record it, and then enter it manually in APT and that's a PITA.
http://en.wikipedia.org/wiki/Extensible … a_Platform
Last edited by mediavets (2009-05-18 11:55:25)
Offline
BrianLR wrote:
So it seems to me that at present working with partial panos is problematic without further controls, or may be more information on how the paramaters can be manipluated effectively?
All FOV options are here to know how was projected the original panorama. Is not a good way to play with them for changing the 3D projected. You risk to
have some distortions in the panorama. This can explain why top and bottom limits are not good (original data are curved, bottom and top limits are not straight anymore).
Current auto-rotation go to the vertical centre of the panorama (if you change the fov offset, data centre stays the same) and use the setted "start view" for the zoom level. By writing this, I think it's can be a good idea to use the vertical "start view" position for auto-rotation (and not the centre of the panorama).
Are you thinking this comportment will answer to your needs ?
mediavets wrote:
Is there some other form/type of image metadata, IPTC/XMP perhaps, in which the stuff currently stored in the user Comment tag in the EXIF could be stored which would be more likely to survive the post-processing of pano images?
IPTC/XMP can also disappear in post processing...
FOV data are also stored in the .pano file. We can add a feature to read FOV information from this file. Can this help you in your way to work ?
Offline
renan wrote:
mediavets wrote:
Is there some other form/type of image metadata, IPTC/XMP perhaps, in which the stuff currently stored in the user Comment tag in the EXIF could be stored which would be more likely to survive the post-processing of pano images?
IPTC/XMP can also disappear in post processing...
FOV data are also stored in the .pano file. We can add a feature to read FOV information from this file. Can this help you in your way to work ?
XMP seems to be becoming 'the' imaging metadata standard and evere more widely supported by imaging tools - so I think that should perhaps be the longer term 'way to go'.
All Adobe tools support XMP and although I don't use Adobe imaging tools (except Premiere Elements) many (most?) do, and there seems to be growing support from other software developers, including Microsoft.
The workaround using the .pano file could be a good interim measure. Would the .pano file have to be in the same folder/directory or would the user be able to browse for it?
Of course this wouldn't help people who used other stitchers (poor souls 
) should APT ever be made available as a standalone application (as opposed to being solely available as a bundle with APG)
Perhaps you could implement both approaches - that should cover everyone?
Last edited by mediavets (2009-05-18 13:13:09)
Offline
mediavets and Renan,
Thanks for your thoughtful responses, I will need some time to digest these and experiment with them. Meanwhile I will post a link tomorrow to the tour I am describing so you can see what I am talking about.
Thanks again, Brian
Offline
Here is a link to the tour with the rotation that tilts up to the ceiling. All rooms are set with a 30 degree vertical fov offset and a 30 degree fov minimum, except for the exterior view with is limited to 5 degrees on both.
http://www.middlesexcc.edu/faculty/Bria … ation.html
Offline
BrianLR wrote:
Here is a link to the tour with the rotation that tilts up to the ceiling. All rooms are set with a 30 degree vertical fov offset and a 30 degree fov minimum, except for the exterior view with is limited to 5 degrees on both.
http://www.middlesexcc.edu/faculty/Bria … ation.html
Yes, I see what you mean about 'pinching' - and this is because of what I described in my earlier post:
http://www.autopano.net/forum/p45565-ye … -09#p45565
The Field of view values in the paporama properties tab should be automatically retrieved by APT from the User comment tag in the EXIF written when the pano is rendered in APG. Renan says the same data is available in the .pano file. It is not intended that the user should normally have to enter or modify these values.
Anyway....if you post-process any of the panos before loading them them in APT you will most likely lose that data; in which case APT will assign the values 360,180,0 - which is the case of a partial pano will of course be incorrect and result in the pinching exhibited by your partial panos in the tour. You could then retrrieve the data from the .pano file and enter it manually. Of course if you have changed the crop of the pano in post-processing you are on your own!
Last edited by mediavets (2009-05-19 18:00:11)
Offline
hi!
it looks as if you configured the pano with pannini projection, which (at the moment) gives that kind of distorted zenith and nadir...
Offline
mediavets wrote:
Anyway....if you post-process any of the panos before loading them them in APT you will most likely lose that data; in which case APT will assign the values 360,180,0 - which is the case of a partial pano will of course be incorrect and result in the pinching exhibited by your partial panos in the tour. You could then retrrieve the data from the .pano file and enter it manually. Of course if you have changed the crop of the pano in post-processing you are on your own!
I have found the easiest way is to load the pre and post processed files into APT and then copy the values across, which is fine as long as I kept a copy of the pre-processed files. Anyway I managed to do that in most cases, which helped a lot in creating the following Panoramic Virtual Tour of Sandy Hook Bay.
Thanks mediavets for your help and I hope they find a way to pass the EXIF data that does not get lost in future releases of APG/APT.
Last edited by BrianLR (2009-08-27 02:33:10)
Offline
what would be nice would to be able to set the limitview="range" or limitview="off" and the degrees for vlookatmin="-75" vlookatmax="75" via the tour define screens. That wouldn't have any effect on image distortion and allow us to limit the vertical tilt up and or down per image. I do this now by editing the xml files, but that is a pain and if you have to rebuild the tour, you have to do it again. Or at least tell where to edit the apt file so the tours will always be rebuilt with the same ranges.
The are many reasons for limiting the view that haven't anything to do with a tripo or ceiling mismatch during rendering. Like maybe an ugly floor or stains on a ceiling.
Last edited by billjones (2009-08-08 19:52:18)
Offline
Pages: 1
