Hugin for time lapse frame stabilization.
rew
Did you see the modern NASA videos , where the FRAME bounces around
the object being filmed, while the rocket remains perfectly stable in
view?
We can now do something similar with hugin! I wrote a simple tutorial,
attached below.
Is this something for the central Hugin tutorials page? Suggestions
for improvement?
------------------------------------------------
Hugin handheld Timelapse tutorial.
Sometimes you find yourselves with some time on your hand, a nice
camera, a nice scene that would look nice in a time lapse movie, but
no tripod and/or computer to take shots in exactly the same position
in an exact time-sequence.
Just point the camera at what you want in your timelapse, and take
shots, at regular intervals, as consistent in time delay and direction
as you want/can.
You can play a sequence of jpgs using mplayer with:
mplayer -mf fps=12 mf://\*.jpg
If you put the shots together like this the image will bounce and
shake a lot, because you didn't point the camera in exactly the same
direction every time.... This is where tripods excel above humans.
So, hugin to the rescue!
First, I reduced the size of all the jpgs by a factor of 4 in each
direction. This gave me frames of about video quality, greatly
reducing the amount of CPU time required to process the many images.
mkdir small
for i in *.jpg; do
echo "$i "
djpeg $i | pnmscale 0.25 | cjpeg > small/$i
done
cd small
I then started up hugin and loaded all the images.
Now to match all the images I have to do the control points manually,
because this is not the "normal" use of hugin. However, for someone
intimate with the workings of Hugin and the surrounding tools, it
should be quite possible to modify one of the tools to allow doing
this automatically in the future.
On the control-points tab, select image 0 on the left, and image 1 on
the right. Now match two or three points in the image.
Next, you would normally match image 1 to image 2, and so on. In this
case I recommend you match every image to image 0. So next you create
several controlpoint matches on images 0 against image 2.
Next, I selected "equirectangular" for both the source images (under
the
"camera and lens" tab) and the destination (under the "stitcher" tab)
Next, click "optimize now".
Next, I selected "high quality tiff" and "nona" as the stitcher. This
triggers the creation of intermediate TIFF files which we're
interested in.
Next click: "calculate field of view" in the stitcher tab, and
"calculate optimal size".
Next, click "stitch now". In my case, the final enblend step crashed
due to an installation error. This is ideal: We don't need
it. Consider making the binary not executable for the duration of this
project, or putting another program of the same name in your path, or
configuring hugin to call some program that doesn't exist.
After entering the name "test.tif" as the output file, you will be
left
with realigned tiff files called test????.tif! You can then convert
these to jpeg with:
for i in test????.tif ; do
tifftopnm $i | cjpeg > $i.jpg
done
now you can play them with:
mplayer -mf fps=12 mf://\test\*.tif.jpg
The bouncing should be greatly reduced!
This tutorial was written in a few minutes, while I had done this
myself a few days earlier. So it might be slightly inaccurate in some
points. If you find a problem, or for example a step I forgot to
describe, please report it so that I can fix this tutorial.
Todo for the programmers: Autopano should have "time lapse
stabilizing" mode. This should, given a few control points on the
first image try to find the same points on the other images. This
should be alot faster than normal, as much less match candidates need
comparing..... Or Hugin can aid by greatly reducing the number of
clicks required by, in time-lapse mode, leaving the "left" control
points in place when I click to the next image. And the right image
can be auto-guessed, as just placing the control points in the same
spot and then "auto fine-tune" should simply work!
If you add more control points than two per image-pair, the
distortions of the lens might be corrected for as well. I haven't
tried this yet.
Bruno Postle
>
>Did you see the modern NASA videos , where the FRAME bounces around
>the object being filmed, while the rocket remains perfectly stable in
>view?
>Is this something for the central Hugin tutorials page? Suggestions
>for improvement?
Yes, definitely something for the tutorials page as it is these
unconventional uses that illustrate the strengths and limitations of
the tools.
Can you work it up into some HTML with images? It doesn't have to
cover every click, just the general idea with a link to the final
video.
--
Bruno
Bruno Postle
>
>>Is this something for the central Hugin tutorials page?
>>Suggestions for improvement?
>Can you work it up into some HTML with images?
..or you could add it to the panotools wiki as a short howto:
--
Bruno
Erik Krause
> >Can you work it up into some HTML with images?
>
> ..or you could add it to the panotools wiki as a short howto:
>
> http://wiki.panotools.org/
... where it would be easier to supplement commands for other OS,
f.e. using ImageMagick...
BTW.: Does hugin support anti aliasing interpolators? If yes, it
would be probably better let hugin do the resizing by simply reducing
output size. This would add alignment accuracy.
best regards
Erik Krause
http://www.erik-krause.de
Bruno Postle
>
>BTW.: Does hugin support anti aliasing interpolators?
Not at the moment, you'd have to stitch with PTmender, which doesn't
currently work with the hugin stitch system - It doesn't support
enough of the nona features.
I plan on writing a wrapper that will make it mostly-work, but not
any time soon.
--
Bruno
rew
> BTW.: Does hugin support anti aliasing interpolators? If yes, it
> would be probably better let hugin do the resizing by simply reducing
> output size. This would add alignment accuracy.
(in this case) about
6 megapixel quality movie, or to get slightly better interpolation
done by Hugin.
However, I find that on my not-state-of-the-art computer(*), hugin is
too slow, when
working with the original images. So I always usually downscale
the images before working with hugin. This can be considered a "hit"
to the developers:
it should be possible to work with the highres images, almost without
performance loss.
(there is no point in lugging around a 6 megapixel image, if all my
previews are displayed
on my 1.3 mpixel screen).
I will see if I can add it to the wiki mentioned. That sounds
"easy". :-)
It might take me a few days to get hold of the images/results again.
They are still
on my friends laptop.
(*) In fact I did this on my friends laptop, also not "state-of-the-
art".
rew
Yuval Levy
> http://wiki.panotools.org/Time_lapse_stabilization
well done, Roger.
why do you select equirectangular for both the source images? aren't
they rectilinear?
I like the idea for the "time lapse stabilizing" mode.
Another stabilizing application was what I did for
<http://geoimages.berkeley.edu/worldwidepanorama/wwp307/html/YuvalLevy.html>
yes, the right way to do that would have been with a rail and a dolly,
but I am no Hollywood $tudio, and for that entry I was fighting with an
uneven surface, cold temperatures and fatigue.
I don't recall exactly, but it was a two steps process - first
synchronize the orientation of all the frames so that they are parellel
to the line going through the center of rotation and then shift them in
their plane to reduce shaking.
Also I did not "match every image to image 0", but rather to the
previous image.
Yuv
rok senk
I find align_image_stack command line tool very useful for automatic
alignment of many images.
rew
> why do you select equirectangular for both the source images? aren't
> they rectilinear?
After my first trial run, I saw hugin distort the image due to some
projection
going on. So I wanted hugin to keep its "hands off" the projection. I
saw
something with "equi" and thought I had found the option to make hugin
just rotate and shift the images.
This is a display of my lack of knowledge. I was "amost completely"
offline
when I did that, so didn't get to read up on the issue. Will do so
soon.... Done.
It seems that equirectangular did what I wanted, and that
"rectilinear" was
the default selection, which didn't do what I wanted. I probably
should have
selected rectilinear for the lens, as that's simply the case. The FOV
was
by default way too large. (At home I downsize the images with a script
that now transfers the exif info, including FOV info for hugin).
Yuval Levy
> It seems that equirectangular did what I wanted
what you really want in your specific case is to synchronize input
projection and output projection. Any synchronized pair will somewhat do
for the purpose of avoiding "distortion" (i.e. unintentional reprojection).
Sometimes you will have a timelapse in which you also need controlled
distortion, in which case the choice of input and output projection
become relevant.
If I understand correctly, you changed the input projection in the
Camera and Lens tab. You could have changed the output projection in the
Stitcher tab to Rectilinear.
Yuv