Re: [PTGui] Crop factor source?
PTGui Support
PTGui has a built in sensor size database; the EOS 30d is listed as 22.7
x 15.1mm, but it appears this should have been 22.5 x 15. Will be fixed.
It should not matter too much though, keep in mind that there can be
large inaccuracies in the EXIF focal length anyway.
Joost
Tom Sharpless wrote:
> Hi,
>
> In connection with revising autopano-sift-c, I've been comparing how
> recent versions of Hugin (0.8) PTAssembler ( 5.0) and PTGui (8.1)
> report lens parameters and image fields of view. I'd like to call
> your attention to an odd discrepancy.
>
> My Canon EOS 30D records these EXIF data in each full size jpeg image:
> # Image Width = 3504 pixels
> # Image Height = 2336 pixels
> # Focal Plane X-Resolution = 3504000/885 = 3959.32
> # Focal Plane Y-Resolution = 2336000/590 = 3959.32
> # Focal Plane X/Y-Resolution Unit = inch (2)
> According to the EXIF standard, these are the primary data for
> computing fov from focal length. The EXIF data from the 30D don't
> include sensor dimensions, or a nominal crop factor, and indeed I
> don't think there are public EXIF tags defined for those.
>
> The EXIF data give identical horizontal and vertical crop factors of
> 1.6015, which is equal within 0.1% to the nominal factor of 1.60 that
> Canon specifies for the 30D. The specified sensor dimensions in mm
> give a crop factor of 1.6000.
>
> Hugin and PTAsm both report crop factors of 1.6 when fed these images,
> but oddly enough PTGui reports 1.587. I wonder where that number is
> coming from?
>
> On the positive side, PTGui correctly recognizes both 8mm Sigma and
> 15mm Canon lenses as fisheyes, which Hugin and PTAsm do not; and PTGui
> computes the field of view for fisheye lenses according to the equal-
> area formula, which is right for all recent fisheye lenses, while
> Hugin and PTAssembler are still using the inappropriate equal-angle
> formula. The correctness of the formula is somewhat spoiled by the
> incorrect crop factor, however.
>
> Regards, Tom
>
>
> >
Tom Sharpless
On Jul 21, 3:35 am, PTGui Support <supp...@ptgui.com> wrote:
> Hi Tom,
>
> PTGui has a built in sensor size database; the EOS 30d is listed as 22.7
> x 15.1mm, but it appears this should have been 22.5 x 15. Will be fixed.
> It should not matter too much though, keep in mind that there can be
> large inaccuracies in the EXIF focal length anyway.
and I'd like to be able to take advantage of that.
>
Here are two more infelicities you might want to at least think about.
1) PTGui, like Hugin, won't let you say whether your fisheye is equal-
area or equal-angle. At least it assumes equal-area, which is almost
always right, while Hugin still assumes equal-angle. PTAssembler
allows you to choose, but unfortunately computes fov wrong when you
specify equal-area.
2) For the "circular fisheye" format, you apparently set hfov
according to the diameter of the cropping circle. That makes it very
hard to work out, from the information in the PTGui project file, the
actual angular scale of the image. The most direct way to specify
angular scale is of course to state the focal length in pixels --
Dersch's "distance parameter". The longstanding PT practice of
relying on hfov to store this crucial parameter is a mistake, because
in hfov it is mixed with two other parameters (image width and
projection function) each of which is subject to uncertainties and
misinterpretations. But as long as you do stick to that practice, it
would be better if hfov always corresponds to the stated image width.
3) When the exif specifies an image orientation, you record the
dimensions in the project file as if the image were oriented that way
(and don't, as far as I can see, also record whether those dimensions
are transposed from the filed dimensions). That is no harm so long as
the stated "hfov", "width", and "format" agree, and it is understood
that the angular scale is to be computed from those quantities before
even looking at the image file. But it can easily lead to more
confusion.
What I'm really saying in 2) and 3) is, wouldn't it be better to state
the angular scale of each image in the project file directly, as focal
length in pixels? Then all these difficulties of interpreting
"hfov" (I could cite a half-dozen more) would disappear.
Regards, Tom
HansNyberg
You seems to a theoretical guy, but you obviously never worked with a
lot of fisheyes
There is absolutely no way that you can calculate accurately from any
EXIF data.
Lenses are very different especially fisheyes. A 10mm Sigma. and a
10,5mm Nikkor has exactly the same image circle but the Sigma is
around 182-184 degrees and the Nikkor is 200.
The Tokina 10-17mm has a slightly larger image circle at 10mm and is
184 degrees.
It does not matter what data you use to calculate it. It will never be
exactly correct from EXIF or from measured cropcircle
And calculating a theoretical exact full resolution output is also
impossible.
It does not matter where you measure the resolution. For example the
10.5 should in theory have 5% larger image in centre than the Tokina
at 10mm but it is only 1%.And at 140 degree the 10.5mm has 10% less
resolution.
As far as I know they are both defined with the same projection even
if they are very different.
The only way you can set an exact full cropcircle would be to have a
database of Cameras and Lenses in PTGui.
But actually what we do is just use a template which is just as good.
You just have to set it up once.
Hans
PTGui Support
> No doubt; but I think high end DSLR's probably give accurate f.l.s,
> and I'd like to be able to take advantage of that.
Not really; I've read that most zoom lenses encode the zoom position
using only a few bits. Also I remember the Sigma 4.5 being reported as
5mm by nikon cameras..
> 1) PTGui, like Hugin, won't let you say whether your fisheye is equal-
> area or equal-angle. At least it assumes equal-area, which is almost
> always right, while Hugin still assumes equal-angle. PTAssembler
> allows you to choose, but unfortunately computes fov wrong when you
> specify equal-area.
I think PTGui does equal angle as well.. Adding more fisheye models is
on my list, in particular the Nikon 10.5 doesn't fit well in the current
model.
> 2) For the "circular fisheye" format, you apparently set hfov
> according to the diameter of the cropping circle. That makes it very
> hard to work out, from the information in the PTGui project file, the
> actual angular scale of the image. The most direct way to specify
> angular scale is of course to state the focal length in pixels --
> Dersch's "distance parameter". The longstanding PT practice of
> relying on hfov to store this crucial parameter is a mistake, because
> in hfov it is mixed with two other parameters (image width and
> projection function) each of which is subject to uncertainties and
> misinterpretations. But as long as you do stick to that practice, it
> would be better if hfov always corresponds to the stated image width.
Whether the fov should refer to the cropped or the uncropped part of the
image is a matter of preference I think. PTGui indeed does this
different from Hugin.
> 3) When the exif specifies an image orientation, you record the
> dimensions in the project file as if the image were oriented that way
> (and don't, as far as I can see, also record whether those dimensions
> are transposed from the filed dimensions). That is no harm so long as
> the stated "hfov", "width", and "format" agree, and it is understood
> that the angular scale is to be computed from those quantities before
> even looking at the image file. But it can easily lead to more
> confusion.
Actually PTGui Pro can do it both ways, see the 'Physically rotate
images with EXIF orientation tag upon loading' in the Project Settings
tab. Both behaviours have pros and cons, it was discussed in this forum
several times.
> What I'm really saying in 2) and 3) is, wouldn't it be better to state
> the angular scale of each image in the project file directly, as focal
> length in pixels? Then all these difficulties of interpreting
> "hfov" (I could cite a half-dozen more) would disappear.
I completely agree. The current behaviour is a Panotools heritage, I
would like to change it but this has to be done carefully in order to
stay compatible with previous versions.
Joost
Ken Warner
The black background merges into the roll off at the edges of
the circular image and there is (usually) always the footprint of the
pano head in the darkest part of the image which (usually)makes the
exact location of the lower edge of the crop circle difficult to
place.
And when using an NN3/5 I always see the shadow of the lower and
upper arm on the bottom and side of the circular image -- if I
don't zoom in -- and that also makes placing of the crop circle
difficult.
Anything you can do to make setting of the crop circle easier (for
me) would be appreciated.
michel thoby
Le 24 juil. 09 à 10:16, HansNyberg a écrit :
Hans said it all and clear. I may give another personal answer:
contrasting from standard rectilinear, the radial mapping of a real
fisheye lens is similar to an optical "finger print" or "individual
signature". No fisheye follows exactly a canonical law (i.e.
mathematical / optical way of categorization).
In short: no **real fisheye lens** projection is strictly
equidistant, orthographic, equisolid angle or stereographic.
Furthermore the individual signatures of a given category from the
list above may appear strikingly different one from another.
The weirdest measurement results I have ever seen was got only two
days ago and concerns the new Samyang 8 mm "aspherical" 8 mm f3.5 CS
fisheye (which I shaved last monday):
http://michel.thoby.free.fr/SAMYANG/Samyang Projection.pdf
It belongs to the Stereographic category and could be the first one
of this kind that is affordable (very cheap indeed). Moreover and as
all fisheyes do, this lens doesn't follow the canonical Stereographic
mathematical model exactly and doesn't not even follow rules of the
categories governed by "cousin" equations.
You may compare with a set of graph for other fisheyes, most of them
were cited above by Hans:
http://michel.thoby.free.fr/SAMYANG/Sigma_Nikkor_Tokina_etc.pdf
BTW: you can also buy this lens as a...7 mm fisheye from Vivitar
(series 1).
This is in itself another related subject: is affecting a fisheye
lens with a "single" focal length really reasonable? The actual
optical changing behavior which depends directly on the angle that
the light is entering the lens (from 0 to more than 90° sometimes)
make the definition of a sole focal length a vain endeavor.
Michel
John Houghton
Control Points tab makes the image edge better defined. Only
available on the Pro version though.
I would like to be able to adjust the crop circle diameter while
keeping it centered - e.g. by dragging the edge with shift+ctrl (like
Photoshop).
John
>
> - Show quoted text -
Ken Warner
shopping list.
I've thought about keeping the crop circle centered but that assumes
you or PTGui knows where the center of the image circle is. Not
an easy task but I think can be done.
But if PTGui can automatically find the center of the image circle
then the crop circle could be moved precisely to the edge of the
image circle and then the user could lock the center or not and move
the crop circle as he chooses. But not easy to do.
John Houghton
>
> I've thought about keeping the crop circle centered but that assumes
> you or PTGui knows where the center of the image circle is.
circle is. It's just that having set the crop circle reasonably
accurately with the brightness turned up, you want to then shrink the
circle so that it lies just inside the blue edge (which is largely
eliminated by turning up the brightness).
John
Ken Warner
Tom Sharpless
On Jul 24, 4:16 am, HansNyberg <hans...@gmail.com> wrote:
> Tom
>
> You seems to a theoretical guy, but you obviously never worked with a
> lot of fisheyes
>
> There is absolutely no way that you can calculate accurately from any
> EXIF data.
> Lenses are very different especially fisheyes. A 10mm Sigma. and a
> 10,5mm Nikkor has exactly the same image circle but the Sigma is
> around 182-184 degrees and the Nikkor is 200.
> The Tokina 10-17mm has a slightly larger image circle at 10mm and is
> 184 degrees.
>
> It does not matter what data you use to calculate it. It will never be
> exactly correct from EXIF or from measured cropcircle
> And calculating a theoretical exact full resolution output is also
> impossible.
> It does not matter where you measure the resolution. For example the
> 10.5 should in theory have 5% larger image in centre than the Tokina
> at 10mm but it is only 1%.And at 140 degree the 10.5mm has 10% less
> resolution.
> As far as I know they are both defined with the same projection even
> if they are very different.
fisheye image just from knowing the focal length. But you also can't
compute them without knowing the focal length.
> The only way you can set an exact full cropcircle would be to have a
> database of Cameras and Lenses in PTGui.
>
> But actually what we do is just use a template which is just as good.
> You just have to set it up once.
maybe not complete, but enough for how you actually use it. That
camera and lens data base should contain not just data on sensor size,
designed focal length and so on, but for fisheye lenses, complete
calibration curves -- the actual relation between angle of view and
radial distance in the focal plane, determined experimentally (and
ideally on the example you own). Here are some such curves, from
Michel Thoby's web site:
http://michel.thoby.free.fr/Blur_Panorama/Nikkor10-5mm_or_Sigma8mm/Sigma_or_Nikkor/Syhthese_courbes_tous_fisheyesREDUCED.jpg
Most were apparently determined by Coastal Optical, Michel mapped two
of the lenses himself.
It isn't at all out of the question for normal humans to calibrate
their own lenses, given the right software. All the data you really
need is some clear photos containing plenty of straight lines (I mean
lines that are straight in reality; in the picture, they can curve --
indeed if they don't there is no need to calibrate the lens). There
is now a GSOC project under Hugin to try to develop a program to do
the rest.
There are several other ways, such as John Houghton's method using
photographs of the night sky, or carefully shining a laser at the lens
at a series of known angles, which is how Thoby (and I believe the
optical labs) do it. But the straight line method has been standard
in photogrammetry for years, because it is easy to get the test data,
and the results are generally almost as good as the laboratory
methods.
Tom Sharpless
Very glad to hear from you on this subject, in which you are a real
expert.
I posted the preceding remarks before noticing your post. But I don't
need to change anything except to say that your experimental work
demonstrates very clearly what you are saying here, and that anyone
interested in processing fisheye images would do well to study your
web pages carefully.
Unlike rectilinear lenses, fisheyes don't have to be designed to
deliver a single standard projection, so designers feel free to trade
off the shape of the projection curve against other desirable
qualities -- or just to experiment with projections. The result is
that we have a wonderful variety of these tools for capturing big
pieces of the world with our cameras, but each one needs its own
special mapping function if we wish to accurately place it on the
panosphere for stitching.
Regards, Tom
Tom Sharpless
On Jul 24, 5:23 am, PTGui Support <supp...@ptgui.com> wrote:
> Tom Sharpless wrote:
> > No doubt; but I think high end DSLR's probably give accurate f.l.s,
> > and I'd like to be able to take advantage of that.
>
> Not really; I've read that most zoom lenses encode the zoom position
> using only a few bits. Also I remember the Sigma 4.5 being reported as
> 5mm by nikon cameras..
>
for ignoring good data. I take almost all my panos with prime lenses,
and believe the focal lengths stated by the manufacturers.
It should be noted, too, that the exact focal length used for lens
correction is not critical, as the radial distortion function is
independent of focal length, and the stitcher will probably optimize
fov later to make the images fit together. FL only needs to be close,
but the radial correction has to be spot-on.
> > 1) PTGui, like Hugin, won't let you say whether your fisheye is equal-
> > area or equal-angle. At least it assumes equal-area, which is almost
> > always right, while Hugin still assumes equal-angle. PTAssembler
> > allows you to choose, but unfortunately computes fov wrong when you
> > specify equal-area.
>
> I think PTGui does equal angle as well.. Adding more fisheye models is
> on my list, in particular the Nikon 10.5 doesn't fit well in the current
> model.
governed by a single continuous parameter. It seems that all known
fisheye projections fall in an "envelope" bounded by the stereographic
projection R = 2 f tan( A / 2) and the equal-area R = 2 f sin( A /
2 ). Equal-angle R = A is right in the middle of the envelope. So a
linear combination, K * equal-angle() + (1 - K) * stereographic(), 0
<= K <= 1, could be a pretty good model for any fisheye. I would go
so far as to suggest that this model function be teamed with a
simplified radius correction polynomial having only even terms (as is
pretty universal for lens correction except in the PT world) i.e.
eliminate the cubic coefficient b and replace it with K (and with
nothing at all in the case of a rectilinear lens; but that is a
different argument). That would not increase the number of lens
correction parameters, but I predict it would make their optimization
far more reliable.
>
> > 2) For the "circular fisheye" format, you apparently set hfov
> > according to the diameter of the cropping circle. That makes it very
> > hard to work out, from the information in the PTGui project file, the
> > actual angular scale of the image. The most direct way to specify
> > angular scale is of course to state the focal length in pixels --
> > Dersch's "distance parameter". The longstanding PT practice of
> > relying on hfov to store this crucial parameter is a mistake, because
> > in hfov it is mixed with two other parameters (image width and
> > projection function) each of which is subject to uncertainties and
> > misinterpretations. But as long as you do stick to that practice, it
> > would be better if hfov always corresponds to the stated image width.
>
> Whether the fov should refer to the cropped or the uncropped part of the
> image is a matter of preference I think. PTGui indeed does this
> different from Hugin.
horizontal image dimension.
> > 3) When the exif specifies an image orientation, you record the
> > dimensions in the project file as if the image were oriented that way
> > (and don't, as far as I can see, also record whether those dimensions
> > are transposed from the filed dimensions). That is no harm so long as
> > the stated "hfov", "width", and "format" agree, and it is understood
> > that the angular scale is to be computed from those quantities before
> > even looking at the image file. But it can easily lead to more
> > confusion.
>
> Actually PTGui Pro can do it both ways, see the 'Physically rotate
> images with EXIF orientation tag upon loading' in the Project Settings
> tab. Both behaviours have pros and cons, it was discussed in this forum
> several times.
>
transposed dimensions in the project file, because it further
complicates the "angular resolution problem".
> > What I'm really saying in 2) and 3) is, wouldn't it be better to state
> > the angular scale of each image in the project file directly, as focal
> > length in pixels? Then all these difficulties of interpreting
> > "hfov" (I could cite a half-dozen more) would disappear.
>
> I completely agree. The current behaviour is a Panotools heritage, I
> would like to change it but this has to be done carefully in order to
> stay compatible with previous versions.
would be happy if you and Max would help make such an improvement
universal. Let's discuss it in, say, October.
Regards, Tom
>
> Joost
michel thoby
Le 25 juil. 09 à 18:18, Tom Sharpless a écrit :
> I have been thinking that there could be a universal fisheye model,
> governed by a single continuous parameter. It seems that all known
> fisheye projections fall in an "envelope" bounded by the stereographic
> projection R = 2 f tan( A / 2) and the equal-area R = 2 f sin( A /
> 2 ). Equal-angle R = A is right in the middle of the envelope. So a
> linear combination, K * equal-angle() + (1 - K) * stereographic(), 0
> <= K <= 1, could be a pretty good model for any fisheye. I would go
> so far as to suggest that this model function be teamed with a
> simplified radius correction polynomial having only even terms (as is
> pretty universal for lens correction except in the PT world) i.e.
> eliminate the cubic coefficient b and replace it with K (and with
> nothing at all in the case of a rectilinear lens; but that is a
> different argument). That would not increase the number of lens
> correction parameters, but I predict it would make their optimization
> far more reliable.
Tom,
May I quote James Kumler and Martin Bauer? In their famous paper
comparing "Fisheye lens designs and their relative performance" they
proposed (and used) a simple formula that seems to fit most (if not
all) the fisheye lenses.
http://www.coastalopt.com/pdfs/FisheyeComparison_SPIE.pdf
(Page 9; § 4.2 Radial Image Mapping):
<< The radial image mapping for these lenses can be fit to the
general form r = Alpha * sin (Beta * Theta) where r is the distance
from the center of the camera image to the point of interest, Theta
is the angle between the central axis ofthe fisheye lens and the line
to the point of interest in the real image, Alpha is a scale factor,
in these cases to convert from angle in space to millimeters in the
image plane, and Beta is the radial mapping parameter. (It should be
noted that Beta effects very strongly.) The theoretical fisheye map
of r = Alpha * Theta is approached as Beta approaches zero. >>
The graph that I have drawn and that you have presented the other day
on this thread is based on this concept that needs only two parameters.
I don't know if James and Martin are the inventors, but I am amazed
that this has not yet got more attention.
Regards,
Michel
Tom Sharpless
On Jul 25, 1:21 pm, michel thoby <thobymic...@wanadoo.fr> wrote:
> Le 25 juil. 09 à 18:18, Tom Sharpless a écrit :
>
> > I have been thinking that there could be a universal fisheye model,
> > governed by a single continuous parameter. It seems that all known
> > fisheye projections fall in an "envelope" bounded by the stereographic
> > projection R = 2 f tan( A / 2) and the equal-area R = 2 f sin( A /
> > 2 ). Equal-angle R = A is right in the middle of the envelope. So a
> > linear combination, K * equal-angle() + (1 - K) * stereographic(), 0
> > <= K <= 1, could be a pretty good model for any fisheye. I would go
> > so far as to suggest that this model function be teamed with a
> > simplified radius correction polynomial having only even terms (as is
> > pretty universal for lens correction except in the PT world) i.e.
> > eliminate the cubic coefficient b and replace it with K (and with
> > nothing at all in the case of a rectilinear lens; but that is a
> > different argument). That would not increase the number of lens
> > correction parameters, but I predict it would make their optimization
> > far more reliable.
>
> Tom,
>
> May I quote James Kumler and Martin Bauer? In their famous paper
> comparing "Fisheye lens designs and their relative performance" they
> proposed (and used) a simple formula that seems to fit most (if not
> all) the fisheye lenses.http://www.coastalopt.com/pdfs/FisheyeComparison_SPIE.pdf
> (Page 9; § 4.2 Radial Image Mapping):
> << The radial image mapping for these lenses can be fit to the
> general form r = Alpha * sin (Beta * Theta) where r is the distance
> from the center of the camera image to the point of interest, Theta
> is the angle between the central axis ofthe fisheye lens and the line
> to the point of interest in the real image, Alpha is a scale factor,
> in these cases to convert from angle in space to millimeters in the
> image plane, and Beta is the radial mapping parameter. (It should be
> noted that Beta effects very strongly.) The theoretical fisheye map
> of r = Alpha * Theta is approached as Beta approaches zero. >>
>
> The graph that I have drawn and that you have presented the other day
> on this thread is based on this concept that needs only two parameters.
> I don't know if James and Martin are the inventors, but I am amazed
> that this has not yet got more attention.
of the envelope (the Samyang 8mm, brought to my attention by your
review) I don't think a formula containing only the sin function can
be considered universal any more. No scaled sin function can
adequately model the stereographic curve because sin and tan have
opposite curvatures.
The formula I propose cannot be made to approach the equal-angle curve
with arbitrarily small error, as Kumler & Bauer's can, but it can come
pretty close, and I think that is enough, given the ability of the
radius correction polynomial to take up small disparities. And
considering how rarely one is likely to encounter a highly accurate
equal-angle lens. We are concerned with panography here, after all,
not photogrammetry.
As to whether there is anything to be gained by adding parameters to
scale the arguments of the sin and tan functions, as in the K-B
formula, my answer is maybe, maybe not. It would take a full analysis
of error, using real data, to settle that, because in the real world
we must estimate these parameters from noisy data. In general adding
more parameters, or more "powerful" ones, increases the error variance
of all estimated parameters, so has to be approached cautiously. My
real motive here is to try to reduce the noise sensitivity of the
estimation procedure, which is already too high with the present
PanoTools lens model.
Best, Tom
> Regards,
>
> Michel
PTGui Support
If you drag the 'diagonal' edges of the circle (e.g. the top right
side), the circle stays centered..
Joost
Ken Warner
Sorry, but the crop circle does not stay centered if you drag inward
from a 'diagonal' or from the top, bottom or side.
I just tried it.
Ken
HansNyberg
If you move the cursor along the circle you will see that there is a
point where the cursor changes from diagonal to vertical or
horisontal.
The diagonal will not change the centre point.
It makes it very easy to adjust it to your image circle.
Hans
John Houghton
> If you drag the 'diagonal' edges of the circle (e.g. the top right
> side), the circle stays centered..
"Help for this tab", though.
John
Ken Warner
arrow pair -- a diagonal arrow pair -- a left right arrow pair or
a cross if in the middle of the crop circle.
And on my computer the crop circle does not stay automatically centered.
Now this could be yet another problem with using a real old computer
with a real old operating system. I run Win2K on a PIII.
But the crop circle does not stay centered automatically no matter which
way I drag the cursor.
PTGui Support
Yes I guess I should add this to the help file..
Joost
PTGui Support
It should work fine on a PIII or win2k. Could you show a 'before' and
'after' screenshot of the entire crop tab?
Joost
Ken Warner
http://pancyl.com/images/Before.jpg
http://pancyl.com/images/After.jpg
I placed the cursor on the upper right hand edge --
the cursor changed to a double headed arrow pointing NE/SW --
I dragged toward the center of the image and you see
the result.
John Houghton
> It's worked like this for many years, and you never discovered :-)
on this occasion I tried all the likely things that were familiar from
Photoshop and other programs. It doesn't help that there is no
obvious feature like a corner that would otherwise help to prompt one
to try dragging in that area. I nearly always apply a crop via a
template for my own images and deliberately don't shrink or grow the
circle. I see that dragging the corners of a rectangular crop don't
keep that crop centered.
It's early days - I'll soon get the hang of PTGui!
John
Ken Warner
be because GTK+ is loosing mouse events during the drag.
On a slow machine, it is possible that not all mouse events
are sent by the OS. Or maybe my mouse is defective. I will
try a different mouse and see if that changes anything.
More later...
PTGui Support
PTGui Support
Looks fine to me; both images have the crop centered at (1944, 1296)..
Joost
Ken Warner
Doesn't it mean anything that the crop circle is off center?
HansNyberg
This is most certainly because the sensor has a large shift.
PTGui can not know in any way how large this shift is.
I have seen that recently some Nikon cameras has had shift of 50-60
pixels.
The image you used is the examples from the Superfisheye 5.6
I have them also. Open one of them in Photoshop and use your centre
point from Photoshop to drag a circle and you will see that the lens
circle is not centered.
You have to either use a crop circle which is the centre of the image
and always optimize for shift.
Or you can set the exact lens circle which at least in theory should
give you a perfect optimizing without shift optimize.
Hans
> http://pancyl.com/images/Before.jpghttp://pancyl.com/images/After.jpg
Ken Warner
Yes, I can see that the image circle is not centered in
the image frame.
I try to move the crop circle so that it is just inside
the purple fringe of the image circle. It's hard to place
the crop circle accurately. I do optimize for shift and
I do see large shift corrections.
I guess that's the best I can do with that image then?
Ken
John Houghton
> Can't you see that the crop circle is off center?
>
> Doesn't it mean anything that the crop circle is off center?
the crop circle about its current centre point, not necessariy about
the centre of the image frame nor about the centre of the image
circle.
John
Ken Warner
that useful...
HansNyberg
image centre.
By using that to drag it to the size of the lens circle you can always
see if there is a large sensor shift.
Hans