Align time lapse stack

[Hansjörg Temperli]

Hi Folks

I recently started with timelapse photography, and the main problem is, due to the lack of a very sturdy tripod, that i need to align the images afterwards.

My current projects have at least 800 images, so i have to call align_image_stack on the command line. During the last night, i ran a 800 image batch that ultimatively failed because in some images, ships move through the imageand the program somehow tried to align these moving objects instead of the horizon.

Now i have this idea to make it work:

Select some 10-15 points on a reference frame, then the program tries to find each point in one of the images, aligns this image and then goes on to the next image. And if it cant find a point in the vicinity (because this point is hidden by an object that moves by), it just goes on and tries the other points. 

Now if only someone could program such an algorithm... or has another idea how to align huge stacks?

Thanks!

[Thomas Pryds]

It sounds like what you need is image stabilization. This is possible
with Hugin. I successfully accomplished this, following the guide at
http://imgur.com/a/3qfWQ . Also, the Panotools wiki has something on
the subject at http://wiki.panotools.org/Time_lapse_stabilization

Thomas P.

> --
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> ---
> You received this message because you are subscribed to the Google Groups
> "hugin and other free panoramic software" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hugin-ptx+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hugin-ptx/f4d79567-4d21-4ef8-87c2-a6189cd4e130%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hansjörg Temperli]

Yes, image stabilisation is what i need.

These tutorials surely work fine for a few small images - but my current heap consists of 800 18MP tiffs. Downscaling is not really an option because i plan to do some panning.

I started hand-tuning the results from the align procedure, but this is very tedious because it takes some 30-60seconds for one operation, be it deleting or adding a controll point.

I use the 2014.0.0 x64 release for windows and there is still plenty of empty RAM ;)

[David W. Jones]

Hmmm, just to add a bit of personal experience with Hugin, memory and
image sizes.

I shoot 6MP, 48-bit files. I decided one time, a few years ago, to run
cpfind on some of my full-rez images (no downscaling). I wasn't aligning
stacks, just my usual handheld panorama. On my old laptop with 2GB of
RAM, running Linux. I started it from my GUI (XFCE). It seemingly
stalled. After about 12 hours, I stopped it and long minutes afterwards,
the machine began responding again. So I decided to try it again, only I
used no GUI and ran it from the command line on one image. With another
login terminal monitoring memory usage.

It used up just about 2GB of RAM to process 1 6MP 48-bit TIFF. I can't
project from there to how much memory running cpfind (or other image
feature recognition sw) on an 18MP image would use ... but I bet it's a
lot more than a mere 2GB. So just how much memory DO you have on your
machine?

I think the 30-60 second response time (when manually creating control
points) sounds like an issue someone mentioned a good while ago when he
put forth his idea of replacing Hugin's present text-based PTO format
with a database format - figuring it would speed up the process of
handling really big image sets. I don't remember what happened with that
discussion, although I think the idea of changing the PTO format didn't
go anywhere?

BTW, I like image stabilization. My camera has it built into the body,
makes quite a difference.

David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

[Hansjörg Temperli]

I have 24GB RAM, max used was about 10GB.

This problem cannot be solved with a hardware IS, as the camera does not "save" the position of the last image. It just takes all n seconds an image.

Thanks to the text based PTO format, i figured out a solution that might work or at least get me some 95% or more "good" CP's.

I run align_image_stack on the command line without creating the realigned tiffs.

The resulting pto file gets fed to a script which removes all CP's that are not in a specific range, in my case it's y-Value must be between 1750 and 1915. For a future project, i might need to create a more complex mask, but... that's rather easy.

When this is done, i will have a look and manually adjust what has to be...

[David W. Jones]

Cool. Only reason I mentioned the old thread about replacing the
text-based PTO format with a database was because that poster's
complaint was the same as yours: the long time it too Hugin to respond
when manually creating or editing a CP when you have a large photo set.

[Michael Witten]

On Tue, Apr 15, 2014 at 6:05 AM, David W. Jones wrote:

> Only reason I mentioned the old thread about replacing the text-based PTO
> format with a database was because that poster's complaint was the same as
> yours: the long time it too Hugin to respond when manually creating or
> editing a CP when you have a large photo set.

I don't see how this could be a fundamental problem with the text-based format.

[Hansjörg Temperli]

I do not know what causes this long delay, i can only confirm it is real. I currently have 800 pics with some 12k CP's

[paul womack]

Hansjörg Temperli wrote:
> I do not know what causes this long delay, i can only confirm it is real. I currently have 800 pics with some 12k CP's

If code has a O(3) or O(4) algorithm, long delays can be caused by quite small
(in RAM terms) data sets.

BugBear

[David W. Jones]

I've never done anything close to that size (in number of images or
control points), so I've never encountered it. I was just remembering
what someone on the list a few years ago had complained about that
problem and proposed replacing the text-based PTO format with some
database approach instead.

It was on this list, so it's probably somewhere in the list archives. It
may have been mentioned as part of a thread about profiling Hugin
performance to speed things up? FWIW, I don't see anything wrong with
the PTO format, although I'm still puzzled that if Hugin can find
vertical lines - why can't it find horizontal lines? They're essentially
the same, separated only by a 90-degree rotation ...

[Hansjörg Temperli]

I have nearly finished the project, there are some minor bumps left as I was not aware that the ships on the left side also move. The result can be seen here: https://www.dropbox.com/s/j97egbagvy6kiwh/lake_zurich_timelapse.mp4
There is still some more de-birding to do, and of course a soundtrack and so on...

But a time lapse video can be aligned with hugin.

Workflow (best do most of it on the command line):

• Deflicker raw image stack with LRTimeLapse or similar
• crop what your really really never will need away
• render jpegs with some oversize in Lightroom
• pto_gen to generate a file that contains all jpegs
• cpfind --celeste --linearmatch
• delete all CP's that are not in a designate area (script)
• check if all images are connected (GUI)
• run optimizer in GUI or autooptimizer (took only... a day or a half)
• Hope for god results
• delete CP's that are way off
• the CP list is your friend!
• sort by distance
• select all "bad" CP's ie CP's that are on a moving object
• whether you delete a single CP or many, the delay is approx. the same.
• reoptimze (took only 6.5hr)
• output the now aligned image stack
• ready for the video app

I wasted only some 2 days of computing time, but the final product is quite OK and the next will be better ;)

[Jim Watters]

Results look pretty good.
For a large stack of images you might want to try a divide and conquer approach to save some time.
For a stack of 100 images.
 - First align every 10th image.
 - Then align the ten stacks keeping the end points anchored.

For even larger stacks take the cube-route. But might need a python script to automate the process.

Jim

-- 
Jim Watters
http://photocreations.ca