I'm currently documenting the script syntax used by hugin and nona.
I have found the following definition of the crop parameters of the 'o'
lines in doc/stitch.txt:
# S100,600,100,800 Selection(l,r,t,b), Only pixels inside the
# rectangle will be used for conversion.
# Original image size is used for all image
# parameters(e.g. field-of-view) refer to the
# original image.
# Selection can be outside image dimension.
#C100,600,100,800 Crop(l,r,t,b), Only pixels inside the rectangle
# will be used for conversion.
# Cropped image size is used for all image
# parameters (e.g. field-of-view) refer to the
# cropped part of the image.
Since nona also supports cropping, I'm using this syntax as well.
However, I do not use the cropped image size for the image parameters
(v, abc etc.). This means I should use S to specify the crop area.
Btw. should the circular cropping done on circular fisheye images mentioned
However, I have noticed that S does behave excactly the same way as C:
1.) Crop area partially outside image:
o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 C46,3026,-466,2514
If the cropped area is partially outside of the image. This occurs for example
with 8 mm fisheye on DSLR Bodies with a APS sized sensor, like the 20D, D70
etc. Here, the original image size is used for the parameters, not the expanded
one. This is the behaviour described by S.
2.) Crop area inside image
o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 C957,2115,445,1603
If the crop area is completely inside, it seems to use the cropped size for
computation of v etc, like it is mentioned for C.
Is this difference by design?
Since I'm using digital fisheye images, I just implemented the S behaviour, to
crop away the black corners.
However, for printed images, it might make sense to do the crop as described by
C, because the image might on some other area, or maybe even scale, depending
on the scanning etc.
This message was sent using IMP, the Internet Messaging Program.