Panotools::Script 0.24 released
Bruno Postle
Hash: SHA1
Panotools::Script is a perl module for reading/writing and
manipulating hugin .pto project files, this 0.24 release fixes some
bugs, has some major refactoring, and adds some new tools:
- - match-n-shift is a control point generator wrapper that
understands about bracketed stacks. It has been split into two
tools: match-n-shift still takes a list of photos, but now creates
a .pto project with as much information as can be read from EXIF
data; ptoanchor is the complementary tool that reads a .pto
project and adds control points.
- - ptochain and ptobind are specialist control point generators and
have an identical interface to ptoanchor: ptochain only tries to
connect consecutive photos (such as a movie sequence) and ptobind
tries to connect just the first and last photos in any existing
connected groups.
- - ptofill is another specialist control point generator with the
same interface as ptoanchor: it looks at the relative positions
of photos and only adds points to overlapping photos, i.e. the
project needs to be approximately correctly laid-out for this tool
to be effective.
- - gigastart is a specialist tool similar to panostart. Whereas
panostart takes a list of photos, splits it into likely panoramas
and writes a Makefile for the full panorama workflow from
generating control-points to stitching; gigastart takes a list of
photos comprising a single multi-row panorama and writes a
Makefile for every step from generating control points to
stitching.
- - All the above tools make extensive use of Makefiles for managing
sub-processes, so they are inherently suitable for parallel
processing. This Makefile generation has been split to a separate
perl module.
A Panotools::Script tarball is available on CPAN:
http://search.cpan.org/dist/Panotools-Script/
0.24 changes:
- - new tool: ptoanchor - add control points to a Hugin project
- - new tool: ptochain - add control points to a Hugin project between
consecutive photos
- - new tool: ptobind - Join the ends of linked photos in a Hugin
project
- - new tool: ptofill - add control points to a Hugin project between
likely overlapping photos
- - new tool: pto2mk2 - Create a Makefile for stitching
- - new tool: gigastart - assemble multi-row panoramas
- - rewrite panostart to use ptoanchor
- - rewrite match-n-shift to use ptoanchor
- - rewrite ptovariable, CLI not the same
- - bugfix: crash in Subset() when project has no image metadata
- - bugfix: tif2svg,enblend-svg fix --jpeg-proxies option (Thomas
Modes)
- - bugfix: match-n-shift fix detection of longest exposure in
bracketed sets
- - bugfix: a full set of defaults are written to new .pto projects
- - bugfix: support P parameter in p-lines
- - bugfix: ptomerge fix mixing absolute and relative paths
- - feature: match-n-shift will get FoV and Eev from EXIF data
- - feature: panostart and match-n-shift use EXIF ExposureMode for
detection of bracketed stacks
- - feature: erect2cubic --face option to optionally specify cubeface
pixel size
- - feature: ptoinfo reports on stacks and exposure layers
- - feature: support i-line TiX,TiY,TiZ,TiS 'tilt' and TrX,TrY,TrZ
'XYZ transform' parameters in libpano13-2.9.1
- - factored Makefile generator to Panotools::Makefile
- - factored EXIF handling to Panotools::Photos
- - Panotools::Script new methods: Stacks() ExposureLayers()
ConnectedGroups() Connections() UnifyLenses() LinkStacks()
AngularDistance()
- - Panotools::Script::Line::Image new accessor methods: Path(), v()
a() b() etc...
SHA1SUM: e5a25accc5950abc44a375802ae58e364a298abb Panotools-Script-0.24.tar.gz
- --
Bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFLO7jyFqOhwCjyCLoRAkKdAKDNqzJv3zD7/wUxrIVNzxQaNftPNwCdHTeK
10gIZLJXVoL5mA/niot28sA=
=c3fP
-----END PGP SIGNATURE-----
Bruno Postle
>
> - match-n-shift is a control point generator wrapper that
> understands about bracketed stacks. It has been split into two
> tools: match-n-shift still takes a list of photos, but now creates
> a .pto project with as much information as can be read from EXIF
> data; ptoanchor is the complementary tool that reads a .pto
> project and adds control points.
I'll try and explain where this is going...
A long time ago Pablo figured-out that the best interface for
passing input to a control point generator is to give it a .pto file
and for it to return the same .pto file with control points added.
This is because there is potentially a huge amount of information
that can be passed: lens parameters, stacks and positions can all be
useful for generating control points.
Up until now, the only tool that supports this interface is
autopano-sift-c, but we didn't have a tool for creating these input
.pto files. So this is what match-n-shift now is, at its most
basic you give it a list of photos and it creates an unaligned .pto
project for those photos. e.g. you can now select some photos in a
file manager, right-click, and instantly create a .pto project:
http://www.flickr.com/photos/36383814@N00/4238784980/
This project can be used as input for autopano-sift-c, or just
open it with Hugin; Align... and Stitch...
Alternatively you can now use 'ptoanchor' to add control points to
this project. ptoanchor actually does everything that the Hugin
Align.. button does, plus it intelligently deals with both kinds of
bracketed panoramas.
ptoanchor is just a wrapper around all sorts of other command-line
tools, it runs so many sub-processes, many of them potentially in
parallel, that is uses a Makefile and gnu 'make' to do it. This is
analogous to the current Hugin stitching system which uses 'make' to
manage the stitching process - Actually it is so similar that it
wouldn't be difficult to plug this into the Hugin Batch Processor
and have end-to-end alignment and stitching.
So although these tools are fully usable as they are, this is
actually a prototype design for a more flexible way of dealing with
the Hugin Align step: to make it scriptable, distributable,
parallel, batchable and debuggable, but still work within the GUI as
it does now.
[more tomorrow, I ought to have blog for this stuff...]
--
Bruno
Bruno Postle
>
> ptoanchor is just a wrapper around all sorts of other command-line
> tools, it runs so many sub-processes, many of them potentially in
> parallel, that is uses a Makefile and gnu 'make' to do it. This
> is analogous to the current Hugin stitching system which uses
> 'make' to manage the stitching process - Actually it is so similar
> that it wouldn't be difficult to plug this into the Hugin Batch
> Processor and have end-to-end alignment and stitching.
The hugin code for creating Makefiles mixes the stitching logic with
all the complexity of the `make' syntax, so for Panotools::Script
I've created a library that separates out the low level Makefile
stuff:
http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm
I do think this is quite cute, executing thousands of sub-processes
is easy to code, and something similar could be done in c++ to make
the Hugin stitching process more transparent and extensible.
--
Bruno
Battle
What am I missing here? How did you get from a command line script to
a right clickable application?
thanks,
Battle
bruno.postle
>
> The hugin code for creating Makefiles mixes the stitching logic with
> all the complexity of the `make' syntax, so for Panotools::Script
> I've created a library that separates out the low level Makefile
> stuff:
>
> http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm
So as an example, here is another control point generator, this time a
wrapper around generatekeys, autopano, cpclean, ptomerge, ptosplit,
celeste and autooptimiser:
http://search.cpan.org/dist/Panotools-Script/bin/ptochain
All ptochain does is match consecutive photos in the project together,
no other possible matches are checked, so one of the things it is
suitable for is stitching the frames of a movie:
http://www.flickr.com/photos/36383814@N00/4207656698/
An advantage of doing this with a Makefile is that this is massively
parallisable, the other is that there were no 'bad' control points
whatsoever.
This should also be usable as a Hugin control point generator plugin
(untested).
--
Bruno
bruno.postle
> What am I missing here? How did you get from a command line script to
> a right clickable application?
On Linux, all you need to do to add a 'right-click' action to all file
browsers (and some photo management tools too) is to install a
single .desktop file.
--
Bruno
Bruno Postle
>
> All ptochain does is match consecutive photos in the project together,
> no other possible matches are checked, so one of the things it is
> suitable for is stitching the frames of a movie:
> http://www.flickr.com/photos/36383814@N00/4207656698/
>
> An advantage of doing this with a Makefile is that this is massively
> parallisable, the other is that there were no 'bad' control points
> whatsoever.
Actually stitching frames of a movie isn't the reason for writing
ptochain... The big problem is generating control-points for
multi-row panoramas:
autopano-sift-c compares features between all photos simultaneously,
this consumes a lot of memory and results in a significant number of
'bad' control points between photos that don't actually overlap. In
the past we have had discussions where the solution looked like a
new tool that understands the approximate relative positions of
photos and only creates control points between photos that are known
to overlap.
This is the new 'ptofill' tool in Panotools::Script. As with the
other tools, it takes an existing .pto project as input, it then
looks at the roll, pitch and yaw positions, and only matches pairs
of photos that are 'near' to each other:
http://search.cpan.org/dist/Panotools-Script/bin/ptofill
This works well, but the problem here is creating this input
project, we discussed a GUI that distributed photos based on user
input - but I'm not convinced this will work in the real world,
people don't shoot photographs in nice regular grids, and I can
never remember what I did anyway.
So here is my recipe for efficiently matching a multi-row panorama:
1. First use ptochain to connect all consecutive photos in the
project, the result will be a project with one or more groups of
connected photos - With luck each of these groups will correspond
with a 'row' of the panorama.
2. Then take the first and last photos from each group and match
them all together in one go (this is another tool with the same
interface: ptobind). With luck there will be a single group of
connected photos in the project (if not you can open this subset in
Hugin and manually add points before continuing).
3. Next optimise this project, but only optimise pitch and yaw (not
roll), this will distribute the photos around the scene even if
there is only one control point between each photo.
4. Use ptofill to place control points between the remaining
overlapping photos that are not already linked.
For example, here is Bernhard Vogl's gigapixel test set consisting
of 337 photos:
http://www.flickr.com/photos/36383814@N00/4224767699/
In the Hugin layout mode you can see that nearly every overlap
between photos has control points:
http://www.flickr.com/photos/36383814@N00/4224767703/
You can also see that Bernhard didn't shoot in a regular grid:
http://www.flickr.com/photos/36383814@N00/4224767709/
Identify and Show Control Points modes:
http://www.flickr.com/photos/36383814@N00/4224767713/
http://www.flickr.com/photos/36383814@N00/4224767717/
There are just 4 'bad' control points out of 19163 in this whole
project. Since it is all managed with 'make', features are only
identified once per photo and pairs of photos are only compared
once. Practically all comparisons of photos have resulted in a
match so this process scales linearly with the number of photos in
the project. It is also very parallisable with `make -j`'
Though this works fine for me, and there is another tool called
'gigastart' to manage all the steps, there is no reason why the same
steps couldn't happen in a different standalone tool at some point.
http://search.cpan.org/dist/Panotools-Script/bin/gigastart
--
Bruno
Pablo d'Angelo
Bruno Postle wrote:
> So here is my recipe for efficiently matching a multi-row panorama:
> 1. First use ptochain to connect all consecutive photos in the project,
> the result will be a project with one or more groups of connected photos
> - With luck each of these groups will correspond with a 'row' of the
> panorama.
>
> 2. Then take the first and last photos from each group and match them
> all together in one go (this is another tool with the same interface:
> ptobind). With luck there will be a single group of connected photos in
> the project (if not you can open this subset in Hugin and manually add
> points before continuing).
>
> 3. Next optimise this project, but only optimise pitch and yaw (not
> roll), this will distribute the photos around the scene even if there is
> only one control point between each photo.
>
> 4. Use ptofill to place control points between the remaining overlapping
> photos that are not already linked.
>
> Though this works fine for me, and there is another tool called
> 'gigastart' to manage all the steps, there is no reason why the same
> steps couldn't happen in a different standalone tool at some point.
> http://search.cpan.org/dist/Panotools-Script/bin/gigastart
This is really great! Now I just have to finish the work on the patent
free control point detector (btw. has anybody tested it?) and it should
be possible to replace autopano-sift-c with a truly free solution.
For typical point and click users, a script similar to gigastart (or
small wrapper), that expects a pto file (or image list or so) and runs
the whole process would be great. This could then be used directly as a
control point generator from within hugin.
ciao
Pablo
Oskar Sander
Substituting, yaw, pitch with X, and Y, this flow should work with mosaics as well.
About manual movements via GUI, an interface for dragging need to be able to distinguish between different kinds of "moving" For example moving a picture to the right could be described as a Yaw movement, but also as a camera-X movement (and, heaven forbid, an image center shift)
There is potential for finding new creative ways to point out starting connection between groups too. But even now with tricky scenarios, hugin can then be used to manually find one or two connections between each group, if not the end-shots is matching with ptobind. (I have to get perl up and running...)
/O
--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
/O
T. Modes
>
> 1. First use ptochain to connect all consecutive photos in the
> project, the result will be a project with one or more groups of
> connected photos - With luck each of these groups will correspond
> with a 'row' of the panorama.
>
> 2. Then take the first and last photos from each group and match
> them all together in one go (this is another tool with the same
> interface: ptobind). With luck there will be a single group of
> connected photos in the project (if not you can open this subset in
> Hugin and manually add points before continuing).
>
> 3. Next optimise this project, but only optimise pitch and yaw (not
> roll), this will distribute the photos around the scene even if
> there is only one control point between each photo.
>
> 4. Use ptofill to place control points between the remaining
> overlapping photos that are not already linked.
>
I implemented this algorithm inside hugin. To use it please create a
new cp detector setting and set type to multi-row.
I added also a variant for stacked projects.
Thomas
Oskar Sander
/Cheers
I implemented this algorithm inside hugin. To use it please create a
new cp detector setting and set type to multi-row.
I added also a variant for stacked projects.
Thomas
/O
Tduell
On Jan 11, 6:04 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> I implemented this algorithm inside hugin. To use it please create a
> new cp detector setting and set type to multi-row.
> I added also a variant for stacked projects.
I tried this (trunk svn 4880), using the simple multi-row set of
photos used in the multi-row tutorial.
It all worked flawlessly using only the 'Assistant' tabs, but it is
probably close to the simplest multi-row one could imagine.
The main thing is that works as described.
The settings in 'Preferences' > 'Control Point Detectors' are as
follows...
Description: Gigastart
Type: Multi-row panorama
Program: gigastart
Arguments: %i
Cheers,
Terry
Bruno Postle
I'm pretty sure this is not how it is supposed to work. Thomas has
actually reimplemented all the logic from gigastart within Hugin,
i.e. what you enter for Program and Arguments are settings for a
'normal' control point detector such as autopano-sift-c or
panomatic.
--
Bruno
Tduell
OK. Thanks for that comment, that clarified things a bit.
I assume from this that the trick is to set up a number of new
detector definitions, all using APSC (or whatever) but each having a
different 'Type', and a different name so that they can be selected
from the 'images' tab for a particular project.
To add a bit of grist to the mill, I tried an amendment to the
definition of the APSC detector, choosing 'mutil-row panorama' and it
appears to be quite a lot slower than using gigastart as the hugin
detector. That is my impression.
Cheers,
Terry
Bruno Postle
>On Jan 13, 9:16 am, Bruno Postle <br...@postle.net> wrote:
>>
>> I'm pretty sure this is not how it is supposed to work. Thomas has
>> actually reimplemented all the logic from gigastart within Hugin,
>> i.e. what you enter for Program and Arguments are settings for a
>> 'normal' control point detector such as autopano-sift-c or
>> panomatic.
>I assume from this that the trick is to set up a number of new
>detector definitions, all using APSC (or whatever) but each having a
>different 'Type', and a different name so that they can be selected
>from the 'images' tab for a particular project.
Yes, I think that is the idea.
>To add a bit of grist to the mill, I tried an amendment to the
>definition of the APSC detector, choosing 'mutil-row panorama' and it
>appears to be quite a lot slower than using gigastart as the hugin
>detector. That is my impression.
gigastart creates a vast number of temporary files, but these are
reused by the Makefile system, so images are only opened once for
classifying features (though looking at the code, I don't see how
gigastart would work from the Hugin GUI as it is).
Calling autopano-sift-c multiple times will result in a lot of
duplicated work, probably what is needed is to go back to the old
autopano-c-complete.sh script which will cache features as .key
files between runs. Arguments would be (untested as usual):
--points %p --size 1600 --output %o %i
--
Bruno
Tduell
On Jan 13, 10:31 am, Bruno Postle <br...@postle.net> wrote:
[snip]
> gigastart creates a vast number of temporary files, but these are
> reused by the Makefile system, so images are only opened once for
> classifying features (though looking at the code, I don't see how
> gigastart would work from the Hugin GUI as it is).
It does work, unless there is something else going on that I'm unaware
of.
I just re-ran my multi-row tutorial project using the 'Assistant' and
using gigastart as the hugin detector, as defined in my earlier
posting.
I needed to be sure that I hadn't been imagining things, or had only
gone to the preview stage or somesuch.
It did the whole business, no problem, producing a nice stitched
pano.
My earlier impression that using gigastart this way was faster than
having APSC defined as a 'multi-row' type, is probably wrong. having
been through the process again I would say there is probably not much
in it.
>
> Calling autopano-sift-c multiple times will result in a lot of
> duplicated work, probably what is needed is to go back to the old
> autopano-c-complete.sh script which will cache features as .key
> files between runs. Arguments would be (untested as usual):
>
> --points %p --size 1600 --output %o %i
OK.
Cheers,
Terry
T. Modes
> >> I'm pretty sure this is not how it is supposed to work. Thomas has
> >> actually reimplemented all the logic from gigastart within Hugin,
> >> i.e. what you enter for Program and Arguments are settings for a
> >> 'normal' control point detector such as autopano-sift-c or
> >> panomatic.
> >I assume from this that the trick is to set up a number of new
> >detector definitions, all using APSC (or whatever) but each having a
> >different 'Type', and a different name so that they can be selected
> >from the 'images' tab for a particular project.
>
> Yes, I think that is the idea.
>
You are right, that was the idea.
> gigastart creates a vast number of temporary files, but these are
> reused by the Makefile system, so images are only opened once for
> classifying features (though looking at the code, I don't see how
> gigastart would work from the Hugin GUI as it is).
>
> Calling autopano-sift-c multiple times will result in a lot of
> duplicated work, probably what is needed is to go back to the old
> autopano-c-complete.sh script which will cache features as .key
> files between runs.
I'm aware of this drawback. Using the current approach enables the use
of any cp detector (autopano-sift-c, panomatic or even Pablos new
patent-free generator). I implemented some checks so that each image
pair is only checked once. Implementing a two step approach would be
possible. This would limit this setting to autopano-sift-c and it
would create many temporary files.
Thomas
T. Modes
> > duplicated work, probably what is needed is to go back to the old
> > autopano-c-complete.sh script which will cache features as .key
> > files between runs.
>
I implemented also the two step approach. Now for multi-row panorama
the feature descriptor is only running once per image, and then only
the feature matcher runs agains all pairs. This will speed up the
detection of cp with autopano-sift-c for multi-row panoramas.
For autopano-sift-c try follow options:
Type: Multi-row
Detector: Two-step
Feature descriptor: generatekeys
Args: %i %k 800
Feature matcher: autopano
Args: %o %k
This will produce many temporary files. So have enough space in the
temp path.
Thomas
Yemi Harris
Bruno Postle
On 12 Sep 2013 20:15, "Yemi Harris" <ye...@newspin360.com> wrote:
>
> Please could you shed some light on this particular issue I keep running into. I've ran match-n-shift multiple times on the same set of 4 images and every time I get slightly different .pto files. I've done tests to check if the exif data is modified somehow after each run but that, thankfully, isn't happening. I'm not sure why this is happening, but I would extremely grateful if you could point me in the right direction.
> match-n-shift -o output.pto -a -r -f 2 image1.jpg image2.jpg image3.jpg image4.jpg
The -r option doesn't do anything, but the -a option will run the Hugin cpfind and vig_optimize tools.
The Hugin photometric (exposure/vignetting) optimisation uses a random sample of from each photo, so you will get slightly different photometric parameters each time.
--
Bruno
Yemi Harris
Bruno Postle
>Ah, I see, thank you for getting back to me. Knowing this sheds a
>lot of light on why my final stitched photo looks slightly
>different every time I run the same set of images. Is it possible
>to specify what sample it uses from each photo for exposure and
>vignetting optimization, so that the final stitched image looks the
>same even if I run it through the pipeline multiple times?
seed every time would be considered - I can't at the moment think
why this would be a problem.
Alternatively you could save a 'good' set of photometric parameters
and apply them to all photos.
--
Bruno
>On Thursday, September 12, 2013 2:26:34 PM UTC-5, Bruno Postle
>wrote:
>>
Yemi Harris
Bruno Postle
When you say a "good" set of photometric parameters, what exactly do you mean? Sorry for my ignorance, i'm kind of new to the game.
Rogier Wolff
On Tue, Oct 22, 2013 at 05:13:41PM +0100, Bruno Postle wrote:
> On 22 October 2013 16:22, Yemi Harris <ye...@newspin360.com> wrote:
>
> >
> > When you say a "good" set of photometric parameters, what exactly do you
> > mean? Sorry for my ignorance, i'm kind of new to the game.
> >
>
> In theory the 'camera response' parameters will stay the same for all
> photos from the same camera (though your RAW converter can mess this up),
> similarly the 'vignetting' parameters will stay if you use the same
> lens/aperture.
>
> So if you get a 'good' panorama stitch once, then there is no need to let
> Hugin recalculate all these parameters for the next panorama, you can just
> reuse them.
these parameters. Thus it is not always certain that something that
"fit" on pano-1 will "fit" on pano-2.
This sometimes has to do with little "freedom" to determine these
parameters. For example, if you just overlay the images left-to-right
by 10 or 20 percent, then there is very little vignetting difference
between the left and right side of the "overlap". So determining the
vignetting parameters becomes "difficult". So large errors result and
the resulting parameter may not fit will on another pano.
But if your first pano provided "good" data, you can surely consider
transporting them to the next pano.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
Yemi Harris
Bruno Postle
On 22 Oct 2013 18:33, "Yemi Harris" <ye...@newspin360.com> wrote:
>
> So if i'm understanding your suggestion correctly. if at the end of this process I get a desirable result, I should be able to reuse the pto file that was generated but change the image paths in the i-lines of the pto file, and replace the control points for each new set of images. Does this make sense?
This is definitely one way to use a project as a template, and probably the simplest as long as you are comfortable editing the .pto file with a script.
--
Bruno