Hi Jim

2011/1/24 Jim Watters <jwatters@photocreations.ca>
Can you tell by reading the exif data if the image was cropped or resized?
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.

I don't know much about exif, but there should be no problem, as long as the pixel width is right.  Cropping doesn't change that, so I would not expect any difficulty there.  Resizing would have to adjust pixel width.  I would guess all raw file EXIFs have focal plane resolution (which is pixels per inch, as I recall), so any self respecting raw converter should output that field corrected for whatever resizing it did.

Sorry don't have time right now to look it up.


On 2011-01-24 12:04 AM, Thomas Sharpless wrote:
Hi all

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

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.

Best, Tom

On Sun, Jan 23, 2011 at 10:03 PM, Thomas Sharpless <tksharpless@gmail.com> wrote:

Jim Watters

Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
PanoTools-devel mailing list