From: Pablo d'A. <pab...@we...> - 2005-07-26 17:39:07
|
Hi all, 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 here? However, I have noticed that S does behave excactly the same way as C: 1.) Crop area partially outside image: Example: 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 Example: 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. ciao Pablo |
From: Jim W. <jim...@ro...> - 2005-07-28 22:56:30
|
Pablo d'Angelo wrote: > Hi all, > > 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: I was the one that updated the stitch.txt file. I created it by running some test and looking at the source. I tried to write it as what the parameters actually do and not what they should do. I may have made a mistake. > > # 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 here? > > However, I have noticed that S does behave excactly the same way as C: > > 1.) Crop area partially outside image: > Example: > 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 > > Example: > 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? There are reasons to have both S and C. When I first learned to use S I went back to some of my old fisheye pans that were part way between full frame and circular ( black in corners only ). All I had to do was add some S (selection) to the images change them from fullframe to circular and regenerate the pans. All pre-calculated v,a,b, ... were all still correct. Crop is better used when using true circular fisheye images that have border all around. > > 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. I believe that scanning negatives is probably the best use of crop instead of S. C or S are important when using the color match feature too - don't want to match black to some other color. > > ciao > Pablo Jim Watters Graphic Software Developer http://photocreations.ca |
From: Pablo d'A. <pab...@we...> - 2005-08-02 07:18:45
|
Hi Jim, Jim Watters wrote: > > Pablo d'Angelo wrote: > > I was the one that updated the stitch.txt file. I created it by running > some test and looking at the source. I tried to write it as what the > parameters actually do and not what they should do. I may have made a > mistake. Thanks a lot for writing it! No worries about the mistakes, I'm not puzzled about the documentation but about the behaviour. >> # 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. >> However, I have noticed that S does behave excactly the same way as C: This is the main point, and where PTStitcher, (I tried on linux using PTStitcher and the current libpano CVS) Both C and S have the same behaviour, at least when I checked using the examples below. >> 1.) Crop area partially outside image: >> Example: >> o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 >> C46,3026,-466,2514 Behaviour as like S (v etc. relate to the original image width) I get exactly the same output when using: o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 S46,3026,-466,2514 >> 2.) Crop area inside image >> >> Example: >> o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 >> C957,2115,445,1603 Behaviour like C (v etc. dependent on crop width) As above, I get the same output when C is substituted by S: o w3072 h2048 f2 y0 p0 r90 a0 b0 c0 d0 e0 g0 t0 v162.129 S957,2115,445,1603 > There are reasons to have both S and C. When I first learned to use S I > went back to some of my old fisheye pans that were part way between full > frame and circular ( black in corners only ). All I had to do was add > some S (selection) to the images change them from fullframe to circular > and regenerate the pans. All pre-calculated v,a,b, ... were all still > correct. Hmm, this is the case 2) described above. Can you recheck your example, please? I'm also appending my test scripts, in case I have made some stupid error... ciao Pablo |