As far as I'm ware Panotour adn Panotour Pro (PT/PTP) can now handle the following types of imput image:
3. Cube faces derived from equirectangular panoramic spherical projections using third party software (APT/APG cannot currently generate cube faces) - a feature new to PTP and not found in APT.
But at present Panotour doesn't handle:
3. Image strips and so on, such as can be created (and handled) by Pano2VR ("Pano2VR supports cylindrical, spherical (equirectangular), cube faces, cross, T, strip and QuickTime VR as input formats with the added ability to convert between these formats for retouching the cube faces.").
I have to point out that Panotour (at least the Pro version) actually handles Importation AND exportation from/to cube faces. Go into the File>Import or File>Export section.
We chose to only handle separate files for the moment. And this format is as defensible as the others (T-strips, ...) if not simpler and better. Theoretically speaking, you are more likely to handle 6 separate pictures of 6000px (or even 50000px if you push the limits of Photoshop) in your retouch software than a single one six time larger.
If this custom EXIF tag is found by APT/PTP then it is used to set the pano Input FOV values which are the key to the correct display of the partial pano image when generating a Flash virtual tour.
However most image editing programs remove the custom EXIF tag so that if any post-processing is performed between stitching and use of the panio image as input to APT/APT, a common scenerio, then APT/PTP will no longer find the Pano Input FOV data and these values will default to those for a 360x180 spherical image which will of course be incorrect for any other sort of panoramic image.
This has been a issue from the outset but because APT was only available bundled with APG it could be considered 'excusable' because APG did create the custom EXIF tag, even if it may be removed by third party image editing software, so if the user made a note of it before post-processing the pano they could still manually enter the correct pano Input FOV values in APT.
PTP will alert the user to the fact that pano Input FOV data has not been found (see screenshot - quite why it came up with that horizontal FOV value, which is quite wrong, I don't know) but how is the user supposed to determine what the correct values should be?
As far as I can see the only safe and relaible way to handle partial panos in PTP will be always to create 360x180 spherical projections of a partial pano - despite the fact that the image does not cover 360x180 - and then use the PTP Hotspot Editor crop tool on the pano after import into PTP.
I should point out that this issue - determining the FOV of a partial pano input image - is not unique to APT/PTP. You have to enter the Horizontal FOV value manually for partial panos with Pano2VR too; but the program appears to calculate the Vertical FOV once given the Horizontal FOV - I guess APT/PTO could (be made to) do that too?
A few beta version back (maybe beta 9, if not 7) we announced that Fov information were now computed from the EXIF (as usual), and then from the image ratio (if no EXIF info available). And setting an horizontal or vertical fov info should compute the equivalent other one. If not then it is a bug, could you confirm it?
So, normal behavior (considering input image is spherical projection) :
Case 1 - Input image has EXIF info (direct from either APP or APG) : right FOV info should be specified
Case 2 - No exif info, image is width:3000px height:1000px; we set horizontal fov to 360° and compute vertical FOV accordingly : hFov:360° vFov:120°
Case 3 - No exif info, image is width:1000px height:3000px; we set vertical fov to 180° and compute horizontal FOV accordingly : hFov:60° vFov:180°
Case 5 - Values are false : change one, it should adjust the other according to the ratio
We have to assume one value (360 or 180, depending on the image) to guess the other, the little icon is there to warn the user values may be false.