Can you tell by reading the exif data if the image was cropped or
There was an issue a little while back on the PTGui list that
discussed how different Raw converters produced images on different
widths. Will this cause a problem? Or will this fix this problem.
Sorry don't have time right now to look it up.
On 2011-01-24 12:04 AM, Thomas Sharpless wrote:
On Sun, Jan 23, 2011 at 10:03 PM, Thomas Sharpless <firstname.lastname@example.org>
I've just finished what I hope will be the final revision of the
Wiki page http://wiki.panotools.org/Lens_Correction_in_PanoTools
It is now, I hope, a clear statement of how PT computes
correction parameters, why those are not portable between image
formats, and what needs to be done to make them portable.
Bottom line, I think:
- add the physical pixel width in microns and the fitted
focal length in mm as new 'i/o' parameters.
- compute the source fl in pixels from these if present
(portable input), from fov if not (trad input)
- provide calls to get and set pixel width in microns. If
no size has been set (trad input) get should return 0.
Passing 0 to set should be ok and mean "use input value" (0
if input is trad).
Save params as portable when a nonzero pixel width has been
posted (portable input or app set new width).
- use 'portable' radial() parameters internally when script
has portable params. Otherwise use trad ones and convert
the params on output if a pixel width has been posted.
for trad input and trad app only, use and save trad
This reduces the job of front ends to the bare minimum, of
acquiring and posting sensor specs. It requires no new
behavior when the source format has not changed -- that covers
all presently valid use cases. And eliminates the rotated
source problem (provided the camera has square pixels) .
The most important benefit, IMO, is that apps that need lens
correction would be able to use PT parameters, even if they
don't use libpano.