[Fwd: Re: [ptx] using hugin to stitch large scans]

[Marek Januszewski]

Since there's lack of any other documentation of that kind,
I think this should go to the hugin website (or at least be available 
somewhere). It would be great if it was available in wiki form with 
possibility of users posting feedback (I know too much requests for one 
time)

anyway, I'm waiting for large map files to arrive via email. I will 
definitely try your manual. My biggest concern was v (fov). Since it's a 
flat image (no lens distortions) should it start with some large value? 
I would think that theoretically the optimizer should be constantly 
optimizing v towards infinity?

best regards,
Marek

HaJo Schatz wrote:
> One day (in the near future) I will patch my MUA to reply to the "List-
> ID:" header rather than the "Reply-To:" header...
>  
> -------- Forwarded Message --------
> From: HaJo Schatz <hajo at hajo.net>
> To: Marek Januszewski <spec at webtech.pl>
> Subject: Re: [ptx] using hugin to stitch large scans
> Date: Tue, 22 Feb 2005 00:15:57 +0800
> On Mon, 2005-02-21 at 10:34 -0500, Marek Januszewski wrote:
> 
>>Hello,
>>
>>  I have a large map I would like to stitch from 4 A4 scans with minimum 
>>of work. Autopano will find the same points without a problem, but 
>>what's next? should I setup some very large FOV? Did anyone do this before?
> 
> I'm doing exactly this quite successfully with hugin -- even though
> hugin is today not really "tailored" for it, you'll have to intervene
> manually to get it done. 
> 
> The idea is essentially to optimize the shift parameters only. I have
> collected my own "readme" for this task a while ago. Let me just post it
> for you. Any questions, let me know...
> 
> 
> Greetings,
> HaJo
> 
> ---------
> 
> October 6, 2004, HJS, V 0.1
> 
> These are the HK Country Side Series maps, all scanned with some
> overlap. File naming is as follows:
> 
> front-a-1.jpg
>   I   I I  
>   I   I +- horizontal sequence from left to right
>   I   I 
>   I   +--- vertical sequence from top to bottom
>   I
>   +------- front/back for page 1/2 of the map
> 
> If individual blocks are to be used, note that they usually have to be
> rotated first as these are raw blocks as scanned. Save them with the
> correct adjustment (and name xxxx-adjusted.jpeg) for later re-use!
> 
> It's not practical to stitch all parts together to recosntruct the
> whole original paper map -- in a decent resolution, this would lead to
> an extremely large file size not processable with an avg
> computer. Note, however, Panotools can stitch the map OK, the only
> problem is picture viewers & editors processing it later. Ie you may
> stitch a low-resolution map ok.
> 
> 
> Hence, stitch individual blocks as you need them. All segments are
> scanned with overlap and can be stitched with PanoTools/Hugin as
> follows:
> 
> * Load Pics:
> - Load all the required blocks into Hugin
> 
> * Lens parameters:
> - Set the lens of each pic to Equirectangular
> - Make sure d/e/g/t are _not_ inherited
> - Set the focal length to about 50
> 
> * Control points:
> - As first step, define control points for Image pair 0/1 _only_
> 
> * Project:
> - Set the stitch project to Equirectangular
> 
> * Optimizer:
> - Set "Optimize Custom parameteres below"
> - Disable all parameters
> - Choose "Edit script before optimizing"
> - In the script, look for the v-line, add a "v d1 e1" to optimize only
>   d and e of pic 1
> - In a next step, choose r1, optimize and again enter "v d1 e1"
> - Note: Preview shows a distorted image, final stitch should be ok
> though
> 
> - Repeat above steps with Image pair 1/2, ...
> - Finally, optimize a/b/c/d/e/g/t. Do _never_ optimize y/p !!
> 
> ! Hugin has a bug handling more than 9 pics (in the lenses tab). If
> you have >9 pics, save the project, fix the file in a text editor and
> re-load it in Hugin, then it's OK.
> 
> ! If lat/long lines are not straight, introduce intra-block
> horizontal/vertical lines as required and re-optimize. It may help to
> adjust r0 correlty first. Accurate r0 can be measured eg with the
> Gimp's roate function which shows a grid.
> 
> ! If loading a project which has control points set for several blocks
> already, d/e of all blocks has to be optimized in one step.
> 
> ! It helps to have some scratch open in eg Emacs to be copied into the
> optimizer script, eg something like:
> 
> v d1 e1
> v d2 e2
> v d3 e3
> v d4 e4
> v d5 e5
> 
> And for a final optimizer run:
> 
> v a1 b1 c1 d1 e1 g1 t1
> v a2 b2 c2 d2 e2 g2 t2
> v a3 b3 c3 d3 e3 g3 t3
> v a4 b4 c4 d4 e4 g4 t4
> v a5 b5 c5 d5 e5 g5 t5
> 
> 
> 
>>--
>>best regards,
>>Marek