From: Thomas S. <tks...@gm...> - 2011-01-24 14:58:45
|
Hi Jim 2011/1/24 Jim Watters <jwa...@ph...> > 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. > > Jim > > > > 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 <tks...@gm... > > wrote: > > > -- > Jim Wattershttp://photocreations.ca > > > > ------------------------------------------------------------------------------ > 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! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |