https://wiki.panotools.org/api.php?action=feedcontributions&user=Bruno&feedformat=atomPanoTools.org Wiki - User contributions [en]2024-03-19T12:13:29ZUser contributionsMediaWiki 1.35.3https://wiki.panotools.org/index.php?title=Hugin_Compiling_Fedora&diff=15448Hugin Compiling Fedora2013-04-29T19:45:58Z<p>Bruno: some better compilation instructions</p>
<hr />
<div>== Binary packages ==<br />
<br />
The [[hugin]] and [[enblend]] stable releases are part of default fedora, available via the ''Add/Remove Software'' menu.<br />
<br />
Otherwise, recent-ish hugin snapshots and other panorama-related software can usually be found at the [http://repos.fedorapeople.org/repos/bpostle/panorama/ fedora panorama repository]. To subscribe just follow this [http://repos.fedorapeople.org/repos/bpostle/panorama/fedora-19/i386/panorama-release-8-2.fc19.noarch.rpm panorama release] link, use the ''Package Installer'' option, and each time you do a ''Software Update'' hugin will be upgraded to the latest snapshot.<br />
<br />
== Compiling ==<br />
<br />
If you want to compile hugin yourself, just follow the instructions in the '''INSTALL_cmake''' file, you will need these development RPM packages (April 2013):<br />
<br />
libpano13-devel zlib-devel libtiff-devel libjpeg-devel<br />
libpng-devel gettext-devel wxGTK-devel boost-devel<br />
cmake desktop-file-utils OpenEXR-devel gcc-c++ exiv2-devel glew-devel<br />
freeglut-devel mesa-libGLU-devel libXmu-devel<br />
wxPython tclap-devel python-devel swig flann-devel lensfun-devel<br />
perl-podlators (needed for fedora 19 and above)<br />
<br />
To actually use hugin you also need make, shared-mime-info, [[enblend]] and perl-Image-ExifTool RPM packages. [[autopano-sift-C]] or [[panomatic]] are optional now that Hugin has a built-in control point generator.<br />
<br />
Basic compilation instructions are:<br />
<br />
tar -bxvf hugin-2010.4.0.tar.bz2<br />
cd hugin-2010.4.0<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
This will install Hugin and its libraries to /usr/local, this is the preferred location for any software installed without a package manager. Note that your fedora system may not actually be configured to make use of the Hugin libraries installed here, so if you get runtime library errors you need to reconfigure your system like so:<br />
<br />
sudo echo /usr/local/lib >> /etc/ld.so.conf.d/local.conf<br />
sudo echo /usr/local/lib64 >> /etc/ld.so.conf.d/local.conf<br />
sudo ldconfig<br />
<br />
To build a snapshot of the latest development version from the Mercurial repository the process is similar:<br />
<br />
hg clone http://hugin.hg.sourceforge.net/hgroot/hugin/hugin<br />
cd hugin<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
== rpm building instructions ==<br />
<br />
The source RPM package contains an hugin.spec file which is both the build documentation and the script for an automated build (other linux packaging systems work basically the same way).<br />
<br />
=== fedora configuration ===<br />
<br />
First set up your fedora system for building rpms, install some packages (as root):<br />
<br />
yum groupinstall "Development Tools"<br />
yum install rpmdevtools<br />
<br />
Using a normal user account create a build tree, by default this is ~/rpmbuild:<br />
<br />
rpmdev-setuptree<br />
<br />
=== Get a source tarball of hugin ===<br />
<br />
Either [http://sourceforge.net/projects/hugin/files/ download the current stable .tar.gz (or tar.bz2) file] from sourceforge or [http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Fetch_the_Source_Code_with_Mercurial get the latest from Mercurial].<br />
<br />
If you have fetched the code via Mercurial you can now create a tarball like so:<br />
<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make package_source<br />
<br />
('package_source' is a ''make'' target, targets are things like 'all' or 'clean' or 'install', this one just creates a tarball)<br />
<br />
=== Get a hugin.spec file ===<br />
<br />
Download an existing hugin .src.rpm file and extract the ''hugin.spec'' file by running this command as a normal user:<br />
<br />
rpm -ivh hugin-2010.2.0-1.src.rpm<br />
<br />
This should put the .spec file where rpmbuild expects to find it.<br />
<br />
~/rpmbuild/SPECS/hugin.spec<br />
<br />
The next step is to put the .tar.bz2 file where rpmbuild expects to find it:<br />
<br />
~/rpmbuild/SOURCES/hugin-2010.4.0.tar.bz2<br />
<br />
..and run rpmbuild to create both the SRPM and RPMS at the same time:<br />
<br />
rpmbuild -ba ~/rpmbuild/SPECS/hugin.spec<br />
<br />
This will fail, probably. You need to edit the .spec file to change the 'Version:' entry to match the number of the tarball, install any missing build dependency rpms, and try again.<br />
<br />
== Building with mock ==<br />
<br />
'mock' is a more sophisticated system for creating RPMS, it is possible to build multiple architectures and create packages for different releases of fedora and redhat enterprise linux on a single fedora system. <br />
<br />
Install mock as root and add yourself to the 'mock' group (use your user name, not 'myusername'):<br />
<br />
yum install mock<br />
usermod -a -G mock myusername<br />
<br />
Follow the instructions above for creating rpms, but just create the source rpm instead:<br />
<br />
rpmbuild -bs ~/rpmbuild/SPECS/hugin.spec<br />
<br />
Then you can build rpms from this src.rpm with mock like so:<br />
<br />
mock -r fedora-11-i386 rebuild ~/rpmbuild/SRPMS/hugin-2009.1.0-0.src.rpm<br />
<br />
The first time you do this it will take a very long time while it downloads and assembles a 'virtual' machine, but subsequent builds will only take a few minutes.<br />
<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Hugin]]<br />
[[Category:Software:Hugin:Compiling]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Compiling_Fedora&diff=15447Hugin Compiling Fedora2013-04-29T19:30:27Z<p>Bruno: update list of Hugin build dependencies</p>
<hr />
<div>== Binary packages ==<br />
<br />
The [[hugin]] and [[enblend]] stable releases are part of default fedora, available via the ''Add/Remove Software'' menu.<br />
<br />
Otherwise, recent-ish hugin snapshots and other panorama-related software can usually be found at the [http://repos.fedorapeople.org/repos/bpostle/panorama/ fedora panorama repository]. To subscribe just follow this [http://repos.fedorapeople.org/repos/bpostle/panorama/fedora-19/i386/panorama-release-8-2.fc19.noarch.rpm panorama release] link, use the ''Package Installer'' option, and each time you do a ''Software Update'' hugin will be upgraded to the latest snapshot.<br />
<br />
== Compiling ==<br />
<br />
If you want to compile hugin yourself, just follow the instructions in the '''INSTALL_cmake''' file, you will need these development RPM packages (April 2013):<br />
<br />
libpano13-devel zlib-devel libtiff-devel libjpeg-devel<br />
libpng-devel gettext-devel wxGTK-devel boost-devel<br />
cmake desktop-file-utils OpenEXR-devel gcc-c++ exiv2-devel glew-devel<br />
freeglut-devel mesa-libGLU-devel libXmu-devel<br />
wxPython tclap-devel python-devel swig flann-devel lensfun-devel<br />
perl-podlators (needed for fedora 19 and above)<br />
<br />
To actually use hugin you also need make, shared-mime-info, [[enblend]] and perl-Image-ExifTool RPM packages. [[autopano-sift-C]] or [[panomatic]] are optional now that Hugin has a built-in control point generator.<br />
<br />
Basic compilation instructions are:<br />
<br />
tar -bxvf hugin-2010.4.0.tar.bz2<br />
cd hugin-2010.4.0<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
This will install Hugin and its libraries to /usr/local, this is the preferred location for any software installed without a package manager.<br />
<br />
== rpm building instructions ==<br />
<br />
The source RPM package contains an hugin.spec file which is both the build documentation and the script for an automated build (other linux packaging systems work basically the same way).<br />
<br />
=== fedora configuration ===<br />
<br />
First set up your fedora system for building rpms, install some packages (as root):<br />
<br />
yum groupinstall "Development Tools"<br />
yum install rpmdevtools<br />
<br />
Using a normal user account create a build tree, by default this is ~/rpmbuild:<br />
<br />
rpmdev-setuptree<br />
<br />
=== Get a source tarball of hugin ===<br />
<br />
Either [http://sourceforge.net/projects/hugin/files/ download the current stable .tar.gz (or tar.bz2) file] from sourceforge or [http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Fetch_the_Source_Code_with_Mercurial get the latest from Mercurial].<br />
<br />
If you have fetched the code via Mercurial you can now create a tarball like so:<br />
<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make package_source<br />
<br />
('package_source' is a ''make'' target, targets are things like 'all' or 'clean' or 'install', this one just creates a tarball)<br />
<br />
=== Get a hugin.spec file ===<br />
<br />
Download an existing hugin .src.rpm file and extract the ''hugin.spec'' file by running this command as a normal user:<br />
<br />
rpm -ivh hugin-2010.2.0-1.src.rpm<br />
<br />
This should put the .spec file where rpmbuild expects to find it.<br />
<br />
~/rpmbuild/SPECS/hugin.spec<br />
<br />
The next step is to put the .tar.bz2 file where rpmbuild expects to find it:<br />
<br />
~/rpmbuild/SOURCES/hugin-2010.4.0.tar.bz2<br />
<br />
..and run rpmbuild to create both the SRPM and RPMS at the same time:<br />
<br />
rpmbuild -ba ~/rpmbuild/SPECS/hugin.spec<br />
<br />
This will fail, probably. You need to edit the .spec file to change the 'Version:' entry to match the number of the tarball, install any missing build dependency rpms, and try again.<br />
<br />
== Building with mock ==<br />
<br />
'mock' is a more sophisticated system for creating RPMS, it is possible to build multiple architectures and create packages for different releases of fedora and redhat enterprise linux on a single fedora system. <br />
<br />
Install mock as root and add yourself to the 'mock' group (use your user name, not 'myusername'):<br />
<br />
yum install mock<br />
usermod -a -G mock myusername<br />
<br />
Follow the instructions above for creating rpms, but just create the source rpm instead:<br />
<br />
rpmbuild -bs ~/rpmbuild/SPECS/hugin.spec<br />
<br />
Then you can build rpms from this src.rpm with mock like so:<br />
<br />
mock -r fedora-11-i386 rebuild ~/rpmbuild/SRPMS/hugin-2009.1.0-0.src.rpm<br />
<br />
The first time you do this it will take a very long time while it downloads and assembles a 'virtual' machine, but subsequent builds will only take a few minutes.<br />
<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Hugin]]<br />
[[Category:Software:Hugin:Compiling]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Compiling_Fedora&diff=15446Hugin Compiling Fedora2013-04-29T19:24:29Z<p>Bruno: fix links to fedora panorama repository</p>
<hr />
<div>== Binary packages ==<br />
<br />
The [[hugin]] and [[enblend]] stable releases are part of default fedora, available via the ''Add/Remove Software'' menu.<br />
<br />
Otherwise, recent-ish hugin snapshots and other panorama-related software can usually be found at the [http://repos.fedorapeople.org/repos/bpostle/panorama/ fedora panorama repository]. To subscribe just follow this [http://repos.fedorapeople.org/repos/bpostle/panorama/fedora-19/i386/panorama-release-8-2.fc19.noarch.rpm panorama release] link, use the ''Package Installer'' option, and each time you do a ''Software Update'' hugin will be upgraded to the latest snapshot.<br />
<br />
== Compiling ==<br />
<br />
If you want to compile hugin yourself, just follow the instructions in the '''INSTALL_cmake''' file, you will need these development RPM packages (January 2011):<br />
<br />
libpano13-devel zlib-devel libtiff-devel libjpeg-devel<br />
libpng-devel gettext-devel wxGTK-devel boost-devel<br />
cmake desktop-file-utils OpenEXR-devel gcc-c++ exiv2-devel glew-devel<br />
freeglut-devel mesa-libGLU-devel libXmu-devel<br />
<br />
To actually use hugin you also need make, shared-mime-info, [[enblend]] and perl-Image-ExifTool RPM packages. [[autopano-sift-C]] or [[panomatic]] are optional now that Hugin has a built-in control point generator.<br />
<br />
Basic compilation instructions are:<br />
<br />
tar -bxvf hugin-2010.4.0.tar.bz2<br />
cd hugin-2010.4.0<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make<br />
sudo make install<br />
<br />
This will install Hugin and its libraries to /usr/local, this is the preferred location for any software installed without a package manager.<br />
<br />
== rpm building instructions ==<br />
<br />
The source RPM package contains an hugin.spec file which is both the build documentation and the script for an automated build (other linux packaging systems work basically the same way).<br />
<br />
=== fedora configuration ===<br />
<br />
First set up your fedora system for building rpms, install some packages (as root):<br />
<br />
yum groupinstall "Development Tools"<br />
yum install rpmdevtools<br />
<br />
Using a normal user account create a build tree, by default this is ~/rpmbuild:<br />
<br />
rpmdev-setuptree<br />
<br />
=== Get a source tarball of hugin ===<br />
<br />
Either [http://sourceforge.net/projects/hugin/files/ download the current stable .tar.gz (or tar.bz2) file] from sourceforge or [http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Fetch_the_Source_Code_with_Mercurial get the latest from Mercurial].<br />
<br />
If you have fetched the code via Mercurial you can now create a tarball like so:<br />
<br />
mkdir BUILD<br />
cd BUILD<br />
cmake ..<br />
make package_source<br />
<br />
('package_source' is a ''make'' target, targets are things like 'all' or 'clean' or 'install', this one just creates a tarball)<br />
<br />
=== Get a hugin.spec file ===<br />
<br />
Download an existing hugin .src.rpm file and extract the ''hugin.spec'' file by running this command as a normal user:<br />
<br />
rpm -ivh hugin-2010.2.0-1.src.rpm<br />
<br />
This should put the .spec file where rpmbuild expects to find it.<br />
<br />
~/rpmbuild/SPECS/hugin.spec<br />
<br />
The next step is to put the .tar.bz2 file where rpmbuild expects to find it:<br />
<br />
~/rpmbuild/SOURCES/hugin-2010.4.0.tar.bz2<br />
<br />
..and run rpmbuild to create both the SRPM and RPMS at the same time:<br />
<br />
rpmbuild -ba ~/rpmbuild/SPECS/hugin.spec<br />
<br />
This will fail, probably. You need to edit the .spec file to change the 'Version:' entry to match the number of the tarball, install any missing build dependency rpms, and try again.<br />
<br />
== Building with mock ==<br />
<br />
'mock' is a more sophisticated system for creating RPMS, it is possible to build multiple architectures and create packages for different releases of fedora and redhat enterprise linux on a single fedora system. <br />
<br />
Install mock as root and add yourself to the 'mock' group (use your user name, not 'myusername'):<br />
<br />
yum install mock<br />
usermod -a -G mock myusername<br />
<br />
Follow the instructions above for creating rpms, but just create the source rpm instead:<br />
<br />
rpmbuild -bs ~/rpmbuild/SPECS/hugin.spec<br />
<br />
Then you can build rpms from this src.rpm with mock like so:<br />
<br />
mock -r fedora-11-i386 rebuild ~/rpmbuild/SRPMS/hugin-2009.1.0-0.src.rpm<br />
<br />
The first time you do this it will take a very long time while it downloads and assembles a 'virtual' machine, but subsequent builds will only take a few minutes.<br />
<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Hugin]]<br />
[[Category:Software:Hugin:Compiling]]</div>Brunohttps://wiki.panotools.org/index.php?title=Tutorials&diff=13959Tutorials2012-05-24T22:18:03Z<p>Bruno: /* Stitching */</p>
<hr />
<div>{{RatingStarSystem}}<br />
There is also a list of all [[tutorials by rating]]<br />
== General ==<br />
* [[The why and how of panoramas]] {{RateStar|1}}<br />
* [[How stitching works]] {{RateStar|1}}<br />
<br />
== Photography ==<br />
* [[Photography Guidelines]] {{RateStar|1}}<br />
* [[DSLR spherical resolution]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=zEgLgReARxs Video tutorial on finding no-parallax point] {{RateStar|2}}<br />
* [http://www.johnhpanos.com/epcalib.htm Finding the No-Parallax Point] {{RateStar|3}}<br />
* [[Sigma 8mm Fisheye Canon 350D MrotatorCP]] {{RateStar|1}}<br />
* [[Special issues with fisheye lenses]] {{RateStar|1}}<br />
* [[ChristmasBallPanoTutor| Making a spherical panorama by photographing a christmas ball]] {{RateStar|2}}<br />
* [[Philopod pitch variation]] technique for shooting handheld {{RateStar|3}}<br />
* [http://www.youtube.com/watch?v=ouOEM4cKKGc Video tutorial on three panorama shooting techniques] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2009/12/24/nodal-ninja-calibration-tutorial/ Calibrating a panoramic head] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/02/29/parallax/ Understanding Parallax] {{RateStar|2}}<br />
<br />
== Preparation ==<br />
* [[A simple approach to HDR-blending]] {{RateStar|2}}<br />
* [[Bracketing]] {{RateStar|2}}<br />
* [[Chromatic aberration]] {{RateStar|2}}<br />
* [[Contrast Blending|Contrast Blending (Exposure Blending)]] {{RateStar|3}}<br />
* [[HDR compression]] {{RateStar|3}}<br />
* [[RAW dynamic range extraction]] {{RateStar|3}}<br />
* [[Working with RAW files in CS2|Working with RAW files in Photoshop CS2]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=mUiw3jtErxk Developing & post-processing fisheye images in LightRoom (video tutorial)] {{RateStar|1}}<br />
<br />
== Stitching ==<br />
* [http://www.dffe.at/panotools/ptgui5-00e.html Basic Panorama Stitching workflow] with PTGui 5 {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=W-WEosizCzE Basic panorama stitching in PTGui 9 Pro (video tutorial)] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/ptgtut.htm 360 vr stitching with ptgui for beginners] {{RateStar|1}}<br />
* Workflows for [[high resolution partial panoramas]] {{RateStar|2}}<br />
* Workflows for [http://www.dffe.at/pano360/ full spherical panoramas] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/optitute.htm Using the optimizer] {{RateStar|1}}<br />
* [[Full 16 bit workflow]] {{RateStar|3}}<br />
* [[Using Autopano-SIFT With PTGui]] {{RateStar|2}}<br />
* [[How to stitch flat images]] {{RateStar|1}}<br />
* [[Flat stitching for tilt-shift lenses]] {{RateStar|3}}<br />
* [http://www.dojoe.net/tutorials/linear-pano Creating linear panoramas with Hugin] {{RateStar|2}}<br />
* [[16bit_workflow_with_hugin|16bit workflow for Hugin]] {{RateStar|2}}<br />
* [[16 bit panorama blending using 8 bit Gimp]] {{RateStar|3}}<br />
* [[High resolution film transparency digitalization using macro lens and stitching]] {{RateStar|3}}<br />
* [[HDR workflow with hugin]] {{RateStar|3}}<br />
* [[Stitching Nadir Shots]] {{RateStar|2}}<br />
* [[Fixing nadir parallax errors]] {{RateStar|3}}<br />
* [[Using Celeste with hugin]] {{RateStar|3}}<br />
* [[Stiching a photo-mosaic]]<br />
* [http://bit.ly/tut_hugin_spheric Creating a Spherical Panorama with Hugin, Panor2VR and Photoshop (Video Tutorial / German)] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/02/hugin-101/ Setting control points manually with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/03/hugin-102/ Hugin Fisheye Basics] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/10/08/exposures-stacks/ Exposures Stack] {{RateStar|2}}<br />
* [http://panospace.wordpress.com/2010/09/19/linear-panoramas-mosaic-tutorial/ Linear Panoramas with Hugin 's Mosaic Mode] {{RateStar|1}}<br />
* [http://www.flickr.com/photos/36383814@N00/5830006193 Some notes on using Hugin's mosaic mode to stitch a street elevation]<br />
* [http://www.tilmanbremer.de/2011/10/panoramic-photography-revealed-part-ii-creating-perfect-panoramas-the-open-source-way/ Creating Perfect Panoramas, The Open Source Way] A complete workflow featuring Hugin, Gimp, SaladoConverter and Panini{{RateStar|2}}German Version: [http://www.tilmanbremer.de/2012/02/hinter-den-kulissen-der-panoramafotographie-teil-ii-perfekte-panoramen-open-source/ Perfekte Panoramen, Open Source]<br />
* [http://www.flickr.com/photos/36383814@N00/6327106374 Reusing bits photos to patch holes in panoramas using Hugin]<br />
<br />
== Leveling and Remapping ==<br />
* [[Leveling a Finished Panorama]] {{RateStar|2}}<br />
* [http://www.dffe.at/pano360/pano-horizont-360_en.html Straightening a (360-degree) Panorama] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/levtut.htm levelling a panorama image with ptgui] {{RateStar|1}}<br />
* [[Leveling a VR shooting setup]] {{RateStar|1}}<br />
* [[Perspective correction]] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/epcalib.htm finding the no-parallax point] {{RateStar|1}}<br />
* [[Unusual remappings]]{{RateStar|3}}<br />
<br />
== Retouching ==<br />
=== Zenith and Nadir retouching ===<br />
* [[Zenith and Nadir editing overview]] {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=WYbEHkxkOds Video tutorials showing 2 approaches: One uses PTGui, the other KRPano Tools] {{RateStar|1}}<br />
* [[How to use PTEditor]] {{RateStar|1}}<br />
* [[Extracting and inserting rectilinear Views]] {{RateStar|1}}<br />
* [[Using enblend to fill the "Hole in the floor"]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with PTGui]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with Adjust filter]] {{RateStar|2}}<br />
* [[How to use enblend for patching zenith and nadir images]] {{RateStar|2}}<br />
* [[How to remove blending error caused by enblend and enfuse at zenith and nadir (automatic)]]<br />
* [http://panospace.wordpress.com/2008/03/18/edit-the-nadir/ Edit nadir with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/03/24/edit-the-nadir-part-ii/ Edit layered nadir with Hugin] {{RateStar|1}}<br />
* [http://www.flickr.com/photos/36383814@N00/2845671569/ pafextract walkthrough] for using [[panoglview]], [[pafextract]] and [[Hugin]] as a replacement for [[PTEditor]]<br />
<br />
=== Tripod Caps ===<br />
* [[Adding a nadir cap (mirror ball)]] {{RateStar|2}}<br />
* [[Adding a nadir logo with text]] {{RateStar|3}}<br />
<br />
=== Other retouching ===<br />
* [[Upsampling a single image with ptstitcher]] {{RateStar|2}}<br />
* [[Retouching broken lines in Photoshop]] {{RateStar|2}}<br />
* [[Mending parallax errors with the shear tool]] {{RateStar|2}}<br />
* [http://www.inertia-llc.com/sandbox/tutorials/shadow-matchcolor/ Shadow Removal on Panoramic Photography] {{RateStar|2}}<br />
* [[Time lapse stabilization]] {{RateStar|3}}<br />
<br />
== Web Presentation ==<br />
* [[Partial Panoramas using ROI in PTViewer]] {{RateStar|2}}<br />
* [[HTML code for several viewers]] {{RateStar|1}}<br />
* [[Uploading Wiki Related Files]] Note: Just use the "upload file" link on the left of the page<br />
* [[create a custom ptviewer jar file]] {{RateStar|3}}<br />
* [[Geo-referencing panoramas with Google Maps]] {{RateStar|3}}<br />
* [[Have a single ptviewer jar file per website]] {{RateStar|3}}<br />
* PTViewerME2 Tutorial [http://panospace.wordpress.com/2008/06/29/ptviewerme2-tutorial-part-1/ part 1], [http://panospace.wordpress.com/2008/06/30/ptviewerme2-tutorial-part-2/ part 2], [http://panospace.wordpress.com/2008/07/17/ptviewerme2-tutorial-part-3/ part 3] {{RateStar|1}}<br />
<br />
=== Virtual Tours ===<br />
* [http://bit.ly/tut_krpano_gmap Creating a Virtual Tour with krpano and Google Maps Plugin (Video Tutorial / German)] {{RateStar|2}}<br />
<br />
== Object Movies ==<br />
* [[Create object movies]] {{RateStar|1}}<br />
* [[Self-made object turntable]] {{RateStar|1}}<br />
<br />
== Printing ==<br />
* [[Printing panoramas]] {{RateStar|2}}<br />
* [[Philosphere]] {{RateStar|1}}<br />
<br />
== Settings, values and miscellaneous==<br />
* [[How to allocate enough RAM for PTEditor]] {{RateStar|2}}<br />
* [[Circular cropping values in PTGui]] {{RateStar|1}}<br />
* [[Build pano12 from sourcecode]] {{RateStar|2}}<br />
* [[Build pano12 from sourcecode MSVC]] {{RateStar|3}}<br />
* [[How to install actions in Photoshop]] {{RateStar|1}}<br />
* [[How to install plug-ins in Photoshop]] {{RateStar|1}}<br />
* [[Enable windows file extensions]] {{RateStar|2}}<br />
* [[Embed QTVR into Powerpoint]] {{RateStar|1}}<br />
* [[Animating panoramas in Blender]] {{RateStar|3}}<br />
<br />
===Community===<br />
* How to use a [[Panotools:newsreader|NNTP newsreader]] to read the [[mailing list]]<br />
<br />
== External links ==<br />
* A growing list of very good tutorials can be found on http://www.johnhpanos.com/tuts.htm<br />
<br />
[[Category:List]]</div>Brunohttps://wiki.panotools.org/index.php?title=Tutorials&diff=13958Tutorials2012-05-24T22:15:44Z<p>Bruno: /* Stitching */</p>
<hr />
<div>{{RatingStarSystem}}<br />
There is also a list of all [[tutorials by rating]]<br />
== General ==<br />
* [[The why and how of panoramas]] {{RateStar|1}}<br />
* [[How stitching works]] {{RateStar|1}}<br />
<br />
== Photography ==<br />
* [[Photography Guidelines]] {{RateStar|1}}<br />
* [[DSLR spherical resolution]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=zEgLgReARxs Video tutorial on finding no-parallax point] {{RateStar|2}}<br />
* [http://www.johnhpanos.com/epcalib.htm Finding the No-Parallax Point] {{RateStar|3}}<br />
* [[Sigma 8mm Fisheye Canon 350D MrotatorCP]] {{RateStar|1}}<br />
* [[Special issues with fisheye lenses]] {{RateStar|1}}<br />
* [[ChristmasBallPanoTutor| Making a spherical panorama by photographing a christmas ball]] {{RateStar|2}}<br />
* [[Philopod pitch variation]] technique for shooting handheld {{RateStar|3}}<br />
* [http://www.youtube.com/watch?v=ouOEM4cKKGc Video tutorial on three panorama shooting techniques] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2009/12/24/nodal-ninja-calibration-tutorial/ Calibrating a panoramic head] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/02/29/parallax/ Understanding Parallax] {{RateStar|2}}<br />
<br />
== Preparation ==<br />
* [[A simple approach to HDR-blending]] {{RateStar|2}}<br />
* [[Bracketing]] {{RateStar|2}}<br />
* [[Chromatic aberration]] {{RateStar|2}}<br />
* [[Contrast Blending|Contrast Blending (Exposure Blending)]] {{RateStar|3}}<br />
* [[HDR compression]] {{RateStar|3}}<br />
* [[RAW dynamic range extraction]] {{RateStar|3}}<br />
* [[Working with RAW files in CS2|Working with RAW files in Photoshop CS2]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=mUiw3jtErxk Developing & post-processing fisheye images in LightRoom (video tutorial)] {{RateStar|1}}<br />
<br />
== Stitching ==<br />
* [http://www.dffe.at/panotools/ptgui5-00e.html Basic Panorama Stitching workflow] with PTGui 5 {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=W-WEosizCzE Basic panorama stitching in PTGui 9 Pro (video tutorial)] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/ptgtut.htm 360 vr stitching with ptgui for beginners] {{RateStar|1}}<br />
* Workflows for [[high resolution partial panoramas]] {{RateStar|2}}<br />
* Workflows for [http://www.dffe.at/pano360/ full spherical panoramas] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/optitute.htm Using the optimizer] {{RateStar|1}}<br />
* [[Full 16 bit workflow]] {{RateStar|3}}<br />
* [[Using Autopano-SIFT With PTGui]] {{RateStar|2}}<br />
* [[How to stitch flat images]] {{RateStar|1}}<br />
* [[Flat stitching for tilt-shift lenses]] {{RateStar|3}}<br />
* [http://www.dojoe.net/tutorials/linear-pano Creating linear panoramas with Hugin] {{RateStar|2}}<br />
* [[16bit_workflow_with_hugin|16bit workflow for Hugin]] {{RateStar|2}}<br />
* [[16 bit panorama blending using 8 bit Gimp]] {{RateStar|3}}<br />
* [[High resolution film transparency digitalization using macro lens and stitching]] {{RateStar|3}}<br />
* [[HDR workflow with hugin]] {{RateStar|3}}<br />
* [[Stitching Nadir Shots]] {{RateStar|2}}<br />
* [[Fixing nadir parallax errors]] {{RateStar|3}}<br />
* [[Using Celeste with hugin]] {{RateStar|3}}<br />
* [[Stiching a photo-mosaic]]<br />
* [http://bit.ly/tut_hugin_spheric Creating a Spherical Panorama with Hugin, Panor2VR and Photoshop (Video Tutorial / German)] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/02/hugin-101/ Setting control points manually with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/03/hugin-102/ Hugin Fisheye Basics] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/10/08/exposures-stacks/ Exposures Stack] {{RateStar|2}}<br />
* [http://panospace.wordpress.com/2010/09/19/linear-panoramas-mosaic-tutorial/ Linear Panoramas with Hugin 's Mosaic Mode] {{RateStar|1}}<br />
* [http://www.tilmanbremer.de/2011/10/panoramic-photography-revealed-part-ii-creating-perfect-panoramas-the-open-source-way/ Creating Perfect Panoramas, The Open Source Way] A complete workflow featuring Hugin, Gimp, SaladoConverter and Panini{{RateStar|2}}German Version: [http://www.tilmanbremer.de/2012/02/hinter-den-kulissen-der-panoramafotographie-teil-ii-perfekte-panoramen-open-source/ Perfekte Panoramen, Open Source]<br />
* [http://www.flickr.com/photos/36383814@N00/6327106374 Reusing bits photos to patch holes in panoramas using Hugin]<br />
<br />
== Leveling and Remapping ==<br />
* [[Leveling a Finished Panorama]] {{RateStar|2}}<br />
* [http://www.dffe.at/pano360/pano-horizont-360_en.html Straightening a (360-degree) Panorama] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/levtut.htm levelling a panorama image with ptgui] {{RateStar|1}}<br />
* [[Leveling a VR shooting setup]] {{RateStar|1}}<br />
* [[Perspective correction]] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/epcalib.htm finding the no-parallax point] {{RateStar|1}}<br />
* [[Unusual remappings]]{{RateStar|3}}<br />
<br />
== Retouching ==<br />
=== Zenith and Nadir retouching ===<br />
* [[Zenith and Nadir editing overview]] {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=WYbEHkxkOds Video tutorials showing 2 approaches: One uses PTGui, the other KRPano Tools] {{RateStar|1}}<br />
* [[How to use PTEditor]] {{RateStar|1}}<br />
* [[Extracting and inserting rectilinear Views]] {{RateStar|1}}<br />
* [[Using enblend to fill the "Hole in the floor"]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with PTGui]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with Adjust filter]] {{RateStar|2}}<br />
* [[How to use enblend for patching zenith and nadir images]] {{RateStar|2}}<br />
* [[How to remove blending error caused by enblend and enfuse at zenith and nadir (automatic)]]<br />
* [http://panospace.wordpress.com/2008/03/18/edit-the-nadir/ Edit nadir with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/03/24/edit-the-nadir-part-ii/ Edit layered nadir with Hugin] {{RateStar|1}}<br />
* [http://www.flickr.com/photos/36383814@N00/2845671569/ pafextract walkthrough] for using [[panoglview]], [[pafextract]] and [[Hugin]] as a replacement for [[PTEditor]]<br />
<br />
=== Tripod Caps ===<br />
* [[Adding a nadir cap (mirror ball)]] {{RateStar|2}}<br />
* [[Adding a nadir logo with text]] {{RateStar|3}}<br />
<br />
=== Other retouching ===<br />
* [[Upsampling a single image with ptstitcher]] {{RateStar|2}}<br />
* [[Retouching broken lines in Photoshop]] {{RateStar|2}}<br />
* [[Mending parallax errors with the shear tool]] {{RateStar|2}}<br />
* [http://www.inertia-llc.com/sandbox/tutorials/shadow-matchcolor/ Shadow Removal on Panoramic Photography] {{RateStar|2}}<br />
* [[Time lapse stabilization]] {{RateStar|3}}<br />
<br />
== Web Presentation ==<br />
* [[Partial Panoramas using ROI in PTViewer]] {{RateStar|2}}<br />
* [[HTML code for several viewers]] {{RateStar|1}}<br />
* [[Uploading Wiki Related Files]] Note: Just use the "upload file" link on the left of the page<br />
* [[create a custom ptviewer jar file]] {{RateStar|3}}<br />
* [[Geo-referencing panoramas with Google Maps]] {{RateStar|3}}<br />
* [[Have a single ptviewer jar file per website]] {{RateStar|3}}<br />
* PTViewerME2 Tutorial [http://panospace.wordpress.com/2008/06/29/ptviewerme2-tutorial-part-1/ part 1], [http://panospace.wordpress.com/2008/06/30/ptviewerme2-tutorial-part-2/ part 2], [http://panospace.wordpress.com/2008/07/17/ptviewerme2-tutorial-part-3/ part 3] {{RateStar|1}}<br />
<br />
=== Virtual Tours ===<br />
* [http://bit.ly/tut_krpano_gmap Creating a Virtual Tour with krpano and Google Maps Plugin (Video Tutorial / German)] {{RateStar|2}}<br />
<br />
== Object Movies ==<br />
* [[Create object movies]] {{RateStar|1}}<br />
* [[Self-made object turntable]] {{RateStar|1}}<br />
<br />
== Printing ==<br />
* [[Printing panoramas]] {{RateStar|2}}<br />
* [[Philosphere]] {{RateStar|1}}<br />
<br />
== Settings, values and miscellaneous==<br />
* [[How to allocate enough RAM for PTEditor]] {{RateStar|2}}<br />
* [[Circular cropping values in PTGui]] {{RateStar|1}}<br />
* [[Build pano12 from sourcecode]] {{RateStar|2}}<br />
* [[Build pano12 from sourcecode MSVC]] {{RateStar|3}}<br />
* [[How to install actions in Photoshop]] {{RateStar|1}}<br />
* [[How to install plug-ins in Photoshop]] {{RateStar|1}}<br />
* [[Enable windows file extensions]] {{RateStar|2}}<br />
* [[Embed QTVR into Powerpoint]] {{RateStar|1}}<br />
* [[Animating panoramas in Blender]] {{RateStar|3}}<br />
<br />
===Community===<br />
* How to use a [[Panotools:newsreader|NNTP newsreader]] to read the [[mailing list]]<br />
<br />
== External links ==<br />
* A growing list of very good tutorials can be found on http://www.johnhpanos.com/tuts.htm<br />
<br />
[[Category:List]]</div>Brunohttps://wiki.panotools.org/index.php?title=Tutorials&diff=13957Tutorials2012-05-24T22:13:39Z<p>Bruno: /* Zenith and Nadir retouching */</p>
<hr />
<div>{{RatingStarSystem}}<br />
There is also a list of all [[tutorials by rating]]<br />
== General ==<br />
* [[The why and how of panoramas]] {{RateStar|1}}<br />
* [[How stitching works]] {{RateStar|1}}<br />
<br />
== Photography ==<br />
* [[Photography Guidelines]] {{RateStar|1}}<br />
* [[DSLR spherical resolution]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=zEgLgReARxs Video tutorial on finding no-parallax point] {{RateStar|2}}<br />
* [http://www.johnhpanos.com/epcalib.htm Finding the No-Parallax Point] {{RateStar|3}}<br />
* [[Sigma 8mm Fisheye Canon 350D MrotatorCP]] {{RateStar|1}}<br />
* [[Special issues with fisheye lenses]] {{RateStar|1}}<br />
* [[ChristmasBallPanoTutor| Making a spherical panorama by photographing a christmas ball]] {{RateStar|2}}<br />
* [[Philopod pitch variation]] technique for shooting handheld {{RateStar|3}}<br />
* [http://www.youtube.com/watch?v=ouOEM4cKKGc Video tutorial on three panorama shooting techniques] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2009/12/24/nodal-ninja-calibration-tutorial/ Calibrating a panoramic head] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/02/29/parallax/ Understanding Parallax] {{RateStar|2}}<br />
<br />
== Preparation ==<br />
* [[A simple approach to HDR-blending]] {{RateStar|2}}<br />
* [[Bracketing]] {{RateStar|2}}<br />
* [[Chromatic aberration]] {{RateStar|2}}<br />
* [[Contrast Blending|Contrast Blending (Exposure Blending)]] {{RateStar|3}}<br />
* [[HDR compression]] {{RateStar|3}}<br />
* [[RAW dynamic range extraction]] {{RateStar|3}}<br />
* [[Working with RAW files in CS2|Working with RAW files in Photoshop CS2]] {{RateStar|2}}<br />
* [http://www.youtube.com/watch?v=mUiw3jtErxk Developing & post-processing fisheye images in LightRoom (video tutorial)] {{RateStar|1}}<br />
<br />
== Stitching ==<br />
* [http://www.dffe.at/panotools/ptgui5-00e.html Basic Panorama Stitching workflow] with PTGui 5 {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=W-WEosizCzE Basic panorama stitching in PTGui 9 Pro (video tutorial)] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/ptgtut.htm 360 vr stitching with ptgui for beginners] {{RateStar|1}}<br />
* Workflows for [[high resolution partial panoramas]] {{RateStar|2}}<br />
* Workflows for [http://www.dffe.at/pano360/ full spherical panoramas] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/optitute.htm Using the optimizer] {{RateStar|1}}<br />
* [[Full 16 bit workflow]] {{RateStar|3}}<br />
* [[Using Autopano-SIFT With PTGui]] {{RateStar|2}}<br />
* [[How to stitch flat images]] {{RateStar|1}}<br />
* [[Flat stitching for tilt-shift lenses]] {{RateStar|3}}<br />
* [http://www.dojoe.net/tutorials/linear-pano Creating linear panoramas with Hugin] {{RateStar|2}}<br />
* [[16bit_workflow_with_hugin|16bit workflow for Hugin]] {{RateStar|2}}<br />
* [[16 bit panorama blending using 8 bit Gimp]] {{RateStar|3}}<br />
* [[High resolution film transparency digitalization using macro lens and stitching]] {{RateStar|3}}<br />
* [[HDR workflow with hugin]] {{RateStar|3}}<br />
* [[Stitching Nadir Shots]] {{RateStar|2}}<br />
* [[Fixing nadir parallax errors]] {{RateStar|3}}<br />
* [[Using Celeste with hugin]] {{RateStar|3}}<br />
* [[Stiching a photo-mosaic]]<br />
* [http://bit.ly/tut_hugin_spheric Creating a Spherical Panorama with Hugin, Panor2VR and Photoshop (Video Tutorial / German)] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/02/hugin-101/ Setting control points manually with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/08/03/hugin-102/ Hugin Fisheye Basics] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/10/08/exposures-stacks/ Exposures Stack] {{RateStar|2}}<br />
* [http://panospace.wordpress.com/2010/09/19/linear-panoramas-mosaic-tutorial/ Linear Panoramas with Hugin 's Mosaic Mode] {{RateStar|1}}<br />
* [http://www.tilmanbremer.de/2011/10/panoramic-photography-revealed-part-ii-creating-perfect-panoramas-the-open-source-way/ Creating Perfect Panoramas, The Open Source Way] A complete workflow featuring Hugin, Gimp, SaladoConverter and Panini{{RateStar|2}}German Version: [http://www.tilmanbremer.de/2012/02/hinter-den-kulissen-der-panoramafotographie-teil-ii-perfekte-panoramen-open-source/ Perfekte Panoramen, Open Source]<br />
<br />
== Leveling and Remapping ==<br />
* [[Leveling a Finished Panorama]] {{RateStar|2}}<br />
* [http://www.dffe.at/pano360/pano-horizont-360_en.html Straightening a (360-degree) Panorama] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/levtut.htm levelling a panorama image with ptgui] {{RateStar|1}}<br />
* [[Leveling a VR shooting setup]] {{RateStar|1}}<br />
* [[Perspective correction]] {{RateStar|1}}<br />
* [http://www.johnhpanos.com/epcalib.htm finding the no-parallax point] {{RateStar|1}}<br />
* [[Unusual remappings]]{{RateStar|3}}<br />
<br />
== Retouching ==<br />
=== Zenith and Nadir retouching ===<br />
* [[Zenith and Nadir editing overview]] {{RateStar|1}}<br />
* [http://www.youtube.com/watch?v=WYbEHkxkOds Video tutorials showing 2 approaches: One uses PTGui, the other KRPano Tools] {{RateStar|1}}<br />
* [[How to use PTEditor]] {{RateStar|1}}<br />
* [[Extracting and inserting rectilinear Views]] {{RateStar|1}}<br />
* [[Using enblend to fill the "Hole in the floor"]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with PTGui]] {{RateStar|2}}<br />
* [[Edit zenith and nadir in one go with Adjust filter]] {{RateStar|2}}<br />
* [[How to use enblend for patching zenith and nadir images]] {{RateStar|2}}<br />
* [[How to remove blending error caused by enblend and enfuse at zenith and nadir (automatic)]]<br />
* [http://panospace.wordpress.com/2008/03/18/edit-the-nadir/ Edit nadir with Hugin] {{RateStar|1}}<br />
* [http://panospace.wordpress.com/2008/03/24/edit-the-nadir-part-ii/ Edit layered nadir with Hugin] {{RateStar|1}}<br />
* [http://www.flickr.com/photos/36383814@N00/2845671569/ pafextract walkthrough] for using [[panoglview]], [[pafextract]] and [[Hugin]] as a replacement for [[PTEditor]]<br />
<br />
=== Tripod Caps ===<br />
* [[Adding a nadir cap (mirror ball)]] {{RateStar|2}}<br />
* [[Adding a nadir logo with text]] {{RateStar|3}}<br />
<br />
=== Other retouching ===<br />
* [[Upsampling a single image with ptstitcher]] {{RateStar|2}}<br />
* [[Retouching broken lines in Photoshop]] {{RateStar|2}}<br />
* [[Mending parallax errors with the shear tool]] {{RateStar|2}}<br />
* [http://www.inertia-llc.com/sandbox/tutorials/shadow-matchcolor/ Shadow Removal on Panoramic Photography] {{RateStar|2}}<br />
* [[Time lapse stabilization]] {{RateStar|3}}<br />
<br />
== Web Presentation ==<br />
* [[Partial Panoramas using ROI in PTViewer]] {{RateStar|2}}<br />
* [[HTML code for several viewers]] {{RateStar|1}}<br />
* [[Uploading Wiki Related Files]] Note: Just use the "upload file" link on the left of the page<br />
* [[create a custom ptviewer jar file]] {{RateStar|3}}<br />
* [[Geo-referencing panoramas with Google Maps]] {{RateStar|3}}<br />
* [[Have a single ptviewer jar file per website]] {{RateStar|3}}<br />
* PTViewerME2 Tutorial [http://panospace.wordpress.com/2008/06/29/ptviewerme2-tutorial-part-1/ part 1], [http://panospace.wordpress.com/2008/06/30/ptviewerme2-tutorial-part-2/ part 2], [http://panospace.wordpress.com/2008/07/17/ptviewerme2-tutorial-part-3/ part 3] {{RateStar|1}}<br />
<br />
=== Virtual Tours ===<br />
* [http://bit.ly/tut_krpano_gmap Creating a Virtual Tour with krpano and Google Maps Plugin (Video Tutorial / German)] {{RateStar|2}}<br />
<br />
== Object Movies ==<br />
* [[Create object movies]] {{RateStar|1}}<br />
* [[Self-made object turntable]] {{RateStar|1}}<br />
<br />
== Printing ==<br />
* [[Printing panoramas]] {{RateStar|2}}<br />
* [[Philosphere]] {{RateStar|1}}<br />
<br />
== Settings, values and miscellaneous==<br />
* [[How to allocate enough RAM for PTEditor]] {{RateStar|2}}<br />
* [[Circular cropping values in PTGui]] {{RateStar|1}}<br />
* [[Build pano12 from sourcecode]] {{RateStar|2}}<br />
* [[Build pano12 from sourcecode MSVC]] {{RateStar|3}}<br />
* [[How to install actions in Photoshop]] {{RateStar|1}}<br />
* [[How to install plug-ins in Photoshop]] {{RateStar|1}}<br />
* [[Enable windows file extensions]] {{RateStar|2}}<br />
* [[Embed QTVR into Powerpoint]] {{RateStar|1}}<br />
* [[Animating panoramas in Blender]] {{RateStar|3}}<br />
<br />
===Community===<br />
* How to use a [[Panotools:newsreader|NNTP newsreader]] to read the [[mailing list]]<br />
<br />
== External links ==<br />
* A growing list of very good tutorials can be found on http://www.johnhpanos.com/tuts.htm<br />
<br />
[[Category:List]]</div>Brunohttps://wiki.panotools.org/index.php?title=Pto_gen&diff=13796Pto gen2011-12-22T22:52:53Z<p>Bruno: Note that PTO project is now created in same folder as first photo.</p>
<hr />
<div>'''pto_gen''' assembles a [[Hugin]] .pto project file that is suitable as input for<br />
further tools such as the [[cpfind]] control-point generator, or for opening<br />
with the Hugin panorama GUI itself. Functionality is similar to<br />
[[match-n-shift]].<br />
<br />
The general use is<br />
pto_gen *.jpg<br />
This creates a project file from all jpg images, in the same folder as the first photo.<br />
The project file is named ''first_file''-''last_file''.pto using the same convention as the Hugin GUI.<br />
<br />
== Options ==<br />
<br />
* '''-o | --output output.pto''' Output a pto file with the given filename (instead of the default).<br />
<br />
* '''-p | --projection number''' Sets the projection type for all images (0 - rectilinear, 2 - equirectangular, 3 - full-frame fisheye, ...).<br />
<br />
* '''-f | --fov number''' Sets the horizontal field of view for all images. Useful if your lens does not store the focal length and/or crop factor correctly in the EXIF data.<br />
<br />
* '''-s | --stacklength number''' Sets the number of images in each stack (default: 1, meaning no stacks).<br />
<br />
* '''-l | --linkstacks''' When given links the image positions in stacks.<br />
<br />
* '''-h | --help''' Display help.<br />
<br />
[[Category:Software:Platform:Windows]]<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Platform:Mac OS X]]<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Linefind&diff=13793Linefind2011-12-13T15:46:52Z<p>Bruno: categorise</p>
<hr />
<div>= General and description =<br />
'''Linefind''' is a detector for vertical features in images. It tries to find vertical lines using the same algorithm as [[Calibrate lens gui#Line detection|Calibrate_lens_gui]] and assigns [[Vertical control points|vertical control points]] to them. The detection runs on the source images, if the input images are [[Rectilinear Projection|rectilinear images]]. In the other cases (e. g. [[Fisheye Projection|fisheye images]]) the input images are reprojected to an [[Equirectangular Projection|equirectangular projection]] and the detection works on the reprojected images.<br />
It uses the [[roll|roll value]], saved in the pto project file, to determine what is "top" and "bottom". So before running '''linefind''' check that your [[roll|roll values]] are correct (E. g. when using images straight from the camera, use a roll value of 0 for landscape and a value of 90 or 270 for portrait images. If your camera has an orientation sensor, [[Hugin]] can detect this information automatically and sets the roll value accordingly when adding such images into Hugin.<br />
<br />
= Usage =<br />
<br />
The general usage is<br />
linefind -o output.pto input.pto<br />
If the --output/-o switch is missing then the suffix "_line" is added to the filename.<br />
<br />
The maximal number of lines added per image can be given with the --lines switch (or short -l):<br />
linefind --lines=10 -o output.pto input.pto<br />
By default maximal 5 lines per image are added to the project file. <br />
<br />
'''Attention:''' Keep in mind that more [[Vertical control points|vertical control points]] will dominate the optimisation in favour of [[Control points|"normal" control points]]. <br />
<br />
Normally '''linefind''' tries to find vertical lines in all images of the project file. If you want to limit the detection to some selected images, you can use the --image/-i switch, e.g.<br />
linefind --image=0 --image=4 -o output.pto input.pto<br />
will only search for vertical lines in image 0 and 4.<br />
<br />
[[Category:Software:Platform:Windows]]<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Platform:Mac OS X]]<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Pto_gen&diff=13792Pto gen2011-12-13T15:40:27Z<p>Bruno: linkify</p>
<hr />
<div>'''pto_gen''' assembles a [[Hugin]] .pto project file that is suitable as input for<br />
further tools such as the [[cpfind]] control-point generator, or for opening<br />
with the Hugin panorama GUI itself. Functionality is similar to<br />
[[match-n-shift]].<br />
<br />
The general use is<br />
pto_gen *.jpg<br />
This creates a project file from all jpg images in the current directory.<br />
The project file is named First file-last file.pto.<br />
<br />
== Options ==<br />
<br />
* '''-o | --output output.pto''' Output a pto file with the given filename (instead of the default).<br />
<br />
* '''-p | --projection number''' Sets the projection type for all images (0 - rectilinear, 2 - equirectangular, 3 - full-frame fisheye, ...).<br />
<br />
* '''-f | --fov number''' Sets the horizontal field of view for all images. Useful if your lens does not store the focal length and/or crop factor correctly in the EXIF data.<br />
<br />
* '''-s | --stacklength number''' Sets the number of images in each stack (default: 1, meaning no stacks).<br />
<br />
* '''-l | --linkstacks''' When given links the image positions in stacks.<br />
<br />
* '''-h | --help''' Display help.<br />
<br />
[[Category:Software:Platform:Windows]]<br />
[[Category:Software:Platform:Linux]]<br />
[[Category:Software:Platform:Mac OS X]]<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_FAQ&diff=13747Hugin FAQ2011-10-06T22:43:20Z<p>Bruno: Patching nadir shots using XYZ mosaic mode</p>
<hr />
<div>== Common error messages ==<br />
<br />
=== enblend: no input files specified ===<br />
<br />
There are no input images relevant to the output 'panorama' so hugin had nothing to do, probably because all the input images are outside the panorama 'frame' or disabled. Open the [[Hugin Preview window]] or [[Hugin Fast Preview window]] to adjust the view, enable some images inside the panorama frame and/or adjust the crop.<br />
<br />
Note also that hugin versions up to and including 2009.2.0 allow you to draw an inverted crop frame where the top is below the bottom, this is easy to see in the Preview window as the entire panorama is 'greyed'. A crop frame drawn like this will result in an empty panorama and the above error message.<br />
<br />
=== enblend: excessive overlap detected ===<br />
<br />
This is an error new to enblend-4.0. Photos that nearly entirely overlap won't blend very well, enblend now fails instead of attempting to blend them. There are various workarounds:<br />
<br />
* Follow the error message and remove the suggested image from the set, you probably don't need it to complete the panorama.<br />
* Switch back to enblend-3.2.<br />
* Hugin will merge stacked images before blending if you select 'Exposure fusion' in the [[Hugin Stitcher tab]]. This error will go away, but Hugin will take a very different approach to variable exposure between photos.<br />
* Mask out major parts of one image.<br />
<br />
=== enblend: error writing to image swap file ===<br />
<br />
[[enblend]] needs a lot of memory and uses its own swap routine to store picture data on the disk, this message indicates that you have run out of disk space. The data is stored in the system temp folder which is specified by TMP, TEMP or TMPDIR environment variables, note that this temp folder may be on a different physical disk to your photos and panorama output.<br />
<br />
=== execvp(make ...) failed with error 2 ===<br />
<br />
Hugin requires the 'make' utility to stitch, you need to install it and/or report the problem to whoever supplied Hugin to you.<br />
<br />
=== false --compression NONE ===<br />
<br />
This error is caused by a bug in the 0.7.0 release that is fixed in 0.8.0. The problem is that your preferences are messed-up, the workaround for 0.7.0 is to go to File -> Preferences -> Enblend and click Load Defaults -> Yes -> Ok<br />
<br />
=== Enblend error: Mask is entirely black, but white image was not identified as redundant ===<br />
<br />
This is a well known "error" for [[enblend]]. Try to use the additional enblend parameter "--fine-mask" to get rid of the error. The parameter will result in generation of masks in higher resolution that will fix the problem in most cases. Sometimes the "--fine-mask" parameter may result in memory errors (malloc: ...), which are the result of not enough memory available due to the (much) bigger masks that are used.<br />
<br />
An alternative workaround would be to set the enblend --no-optimize parameter, this will place the seam directly along the middle of the image overlaps regardless of image content. This option is also considerably faster and uses less memory.<br />
<br />
This error also occurs when one photo is completely covered by another, try removing redundant photos.<br />
<br />
Note also that for the same reasons this error often appears when rendering a scene with extreme distortion such as a stereographic 'little planet'. For this and other reasons, such as overall speed, it is always preferable to render a 'normal' 360° [[Equirectangular Projection]] panorama first, then load this as a single source image into a new project and render whatever views you need.<br />
<br />
Note (Jan 2010): This should be fixed in the latest [[enblend]] 4.0 release.<br />
<br />
=== enblend: illegal option -- compression ===<br />
<br />
hugin 0.7.0 and later versions require at least [[enblend]] version 3.2. This error indicates that you need to upgrade enblend.<br />
<br />
=== enblend: Error -1073741795 ===<br />
<br />
See [[#Enblend: The system cannot execute the specified command]], in particular if you are a Windows user try switching to the 'nosse' enblend-enfuse.<br />
<br />
=== Makefile: target pattern contains no % ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== gnumake: *** No rule to make target ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== nona: GL error: Framebuffer incomplete, incomplete attachment in: ===<br />
<br />
This is a message generated by nona when using the GPU for stitching (feature available starting with Hugin-2009.2.0). See section below about [[#GPU-stitching_.28nona.29|GPU-stitching]].<br />
<br />
=== make: enfuse: command not found ===<br />
<br />
This is a message generated by make when assembling your panorama. It most likely means that enfuse is not on your computer. Enfuse is part of the enblend package, but many Linux distributions, even recent ones, ship with an older version of enblend that does not contain enfuse. You need to install enblend-3.2 or later.<br />
<br />
=== Enblend: The system cannot execute the specified command ===<br />
<br />
This message could be generated by either<br />
* the lack of Microsoft Visual C++ 2008 Redistributable Package (x86) that is necessary to run an OpenMP enabled version of Enblend. Download [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here].<br />
* the lack of [http://en.wikipedia.org/wiki/SSE2 SSE2] support. Use a non-SSE build of Enblend. See also [[#Enblend-Enfuse_OpenMP_SSE_GPU:_which_one_is_the_right_one_for_me.3F | types of Enblend-Enfuse binaries]] or [[#Selecting_right_version_of_enblend-enfuse_binary_for_Windows | types of Enblend-Enfuse binaries for Windows ]]<br />
<br />
===Windows error message "application configuration is incorrect"===<br />
<br />
Double clicking the Hugin icon to run the program produces a message like this:<br />
<pre><br />
C:\Program Files\Hugin\bin\hugin.exe<br />
This application has failed to start because the application configuration is incorrect.<br />
Reinstalling the application may fix this problem.<br />
</pre><br />
Try installing the [http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Microsoft Visual C++ redistributable].<br />
<br />
=== Stitching fails on Windows (syntax error)===<br />
<br />
If the stitching step fails on windows with a error message like<br />
<br />
<pre><br />
/usr/bin/sh: -c: line 1: syntax error near unexpected token `(6'<br />
/usr/bin/sh: -c: line 1: `echo Operating System: Windows 7 (6.1 )'<br />
make: *** [info] Error 258<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
Syntax error: "(" unexpected<br />
make: *** [info] Error 2<br />
</pre><br />
<br />
then you have probably an other shell (e.g. sh.exe or bash.exe) somewhere in your path. In this case remove the path to this executable from the PATH variable.<br />
<br />
=== Hugin Quits (Seg Faults) at Launch (Linux) ===<br />
<br />
There may be many reasons why a program dies before it has even started.<br />
<br />
One possibility is bad configuration or installation of the video drivers. See this [https://bugs.launchpad.net/hugin/+bug/679427 ticket]. To diagnose, try running glxgears. On Ubuntu (the package is probably available on most Linux distributions):<br />
<br />
<pre><br />
sudo apt-get mesa-utils<br />
glxgears<br />
</pre><br />
<br />
If glxgears does not run on your system, Hugin will not run either. See your Linux distribution's instruction on how to fix the video drivers.<br />
<br />
== Known Limitations ==<br />
<br />
=== Linux: Compiz ===<br />
<br />
Linux: Compiz interferes with the [[hugin Fast Preview window]]. This is not a hugin specific issue. Research shows all direct rendered stuff will have various problems under Compiz: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/96991<br />
<br />
This problem is fixed with DRI2, e.g with fedora 11 and intel graphics hardware you can have a 'wobbly' Fast Preview window if you really want.<br />
<br />
It's not an issue with NVidia's proprietry driver.<br />
<br />
If you're affected, the workaround is to not use Compiz.<br />
<br />
=== Windows: International Characters in Path ===<br />
<br />
Hugin is fully internationalised and can cope with special characters in file paths. However, hugin apparently fails on some Windows systems with Polish, Japanese, Russian or Czech codepages, the workaround is to use shell-safe ascii characters in file and folder names: '''A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 - _ .''' This includes the path for the temporary folder which is named after your username on Windows systems.<br />
<br />
=== OSX: error when clicking on the help button ===<br />
<br />
In a language other than English, French or Italian you get an error message when clicking on the help button. This will be fixed in Hugin-2009.4.0. In the meantime, the work around is to change language to one of the above three; or to ask for help on the mailing list. <br />
<br />
=== Non-Unique Filenames ===<br />
<br />
Some components of Hugin have been reported not to deal well with image files<br />
that have the same name in different folders. The workaround is to rename <br />
your images files so that all image files in a project are unique.<br />
<br />
=== Temporary Files ===<br />
<br />
Hugin has a preference setting for the temporary files folder. Currently it<br />
is not implemented properly and files will be written in the same folder as<br />
the project file.<br />
<br />
A partial workaround on Linux is to start Hugin from a terminal with<br />
<pre><br />
TMPDIR=/media/disk-2/tmp hugin &<br />
</pre><br />
<br />
These temporary files have to be deleted manually after the stitch.<br />
<br />
=== Special Characters in Paths ===<br />
<br />
{| style="margin: 1em auto 1em 1em;background:#FFFF99;color:#FF0000;text-align:left;border: solid #FF3300;"<br />
|-valign="top"<br />
! =<br />
! ;<br />
! :<br />
! $<br />
! "<br />
! %<br />
! #<br />
! |<br />
! '<br />
! (<br />
! )<br />
! `<br />
! &<br />
! *<br />
! +<br />
! ^<br />
! ~<br />
! <<br />
! ?<br />
! ><br />
! and the space character.<br />
|}<br />
<br />
Hugin currently does not do plausibility checks on the paths and file names that are given to it. It relies on the operating system's conventions and limitations. However Hugin uses make to run the stitching process, and make has more restrictive limitation than the operating system.<br />
<br />
Please don't use the above characters in your files and folders when you want to make sure they work with Hugin. If you absolutely need files named this way, rename them after processing. Do not file bug reports based on filenames with the above characters. The [https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2883450&group_id=77506 issue] is known, analyzed, and may be fixed in the future.<br />
<br />
=== Stitch fails when '&' is part of the Windows 7 ''user-name'' ===<br />
<br />
This is a variant of the above, but more difficult to work around. The ''user-name'' is part of all paths in the user's data area, including the temporary file locations defined by TMP and TEMP. Stitch fails almost immediately with a make path error.<br />
<br />
Work-around: Move your hugin data to a folder in the root directory such as C:\hugin. Then go to the Windows Control Panel and change ''System, Advanced, Environment, user TMP'' to a folder in the root, such as 'C:\temp' (create it if necessary).<br />
<br />
Notes: This work-around probably needs Win 7 ''Administrator'' privileges.<br />
<br />
A simpler solution should be to set hugin ''File, Preferences, Temporary dir'' to C:\hugin; but it doesn't fix<br />
the problem! Seemingly, at least one temporary file still gets created in the TMP folder.<br />
<br />
=== Hugin fails stitching some stereographics and other polar projections ===<br />
<br />
This is a known limitation caused by photos being distorted into extreme 'C' and 'O' shapes. The workaround: stitch all of your pictures into a single equirectangular, and then load the equirectangular into Hugin to generate the stereographic or other projections you wanted to do in the first place.<br />
<br />
<br />
=== OSX / iPhoto ===<br />
<br />
Dragging the photos from iPhoto to Hugin works perfectly as long as there is no forward slash in the Name of the events in iPhoto (which translates to folders inside the iPhoto Database).<br />
<br />
=== Fast Preview ===<br />
<br />
Why are there two preview windows, and which one should I use?<br />
<br />
For most purposes, the newer Fast Preview window is faster. However it is still under development and sometimes shows artefacts. The old preview still does a logarithmic tone mapping of stacked<br />
images and is the only way to preview hdr or fused output.<br />
<br />
=== Makefile based stitching process ===<br />
<br />
Can I restart a stitching process that was interrupted manually or by an error without starting everything from scratch?<br />
<br />
Unfortunately the Hugin Makefile system only supports restarting if you stitch on the command-line. The GUI tools always create new temporary .pto project and Makefile files every time they stitch, so this forces make to recreate everything for every stitch.<br />
<br />
=== Patching nadir shots using XYZ mosaic mode cuts the photos in half ===<br />
<br />
"If an image is mapped to the [[nadir]] of a panorama and all translation parameters (X,Y,Z) are set to zero, the image is properly mapped and covers the entire nadir of the shot. However, if any of the X,Y,Z parameters are non-zero, then the image is cut in half and only occupies half of the nadir."<br />
<br />
Basically the XYZ mosaic mode as it is implemented currently in [[Hugin]] requires that the mosaic photos must be mapped to a plane perpendicular to the view direction - In practice this means that what you are trying to do only works if the panorama is rotated such that the nadir is in the middle of the canvas and not at the bottom.<br />
<br />
This isn't so bad, the nadir-in-the-middle image looks a bit weird, you can just reload the stitched [[equirectangular Projection]] result into a new single-photo project and straighten it there.<br />
<br />
== Python Scripting ==<br />
<br />
=== What is Python Scripting? ===<br />
<br />
Python is a powerful scripting language. Starting with Hugin 2011.2, Hugin exposes the panorama object through hsi.py in Python. It must be explicitly activated at build time with the CMake boolean parameter -DBUILD_HSI:BOOL=ON. It is currently untested / unavailable on OSX.<br />
<br />
=== How do I start Scripting? ===<br />
<br />
<pre><br />
$ python<br />
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) <br />
[GCC 4.5.2] on linux2<br />
Type "help", "copyright", "credits" or "license" for more information.<br />
>>> import hsi<br />
>>> help (hsi)<br />
</pre><br />
<br />
=== What is the difference between a Plugin and a Script? ===<br />
<br />
Strictly speaking, they are both Python scripts. A Plugin runs inside Hugin, while a Script runs in a shell or desktop.<br />
<br />
=== Where Are the Plugins in Hugin and how do I use them? ===<br />
<br />
If Hugin was compiled with HSI, a menu Action will list categories of system-wide plugins. Just select one to run it. Moreover, you can write your own plugins and run them with the menu Edit -> Run User Python Plugin. The default location for user plugins is set in the preferences.<br />
<br />
=== Script Returned -10 ===<br />
<br />
This error message indicates that the plugin tried to import something and failed. hpi.py currently has no other way of telling hugin what's wrong than to 'return -10'. Try to start Hugin from the command line and see if there is more verbose output there. Copy the output and ask for help on hugin-ptx.<br />
<br />
=== Script Returned -11 ===<br />
<br />
The plugin failing with an exception. Ask the plugin maintainer to produce more specific error messages. It is good practice to catch such exceptions and let the user know what dependency is missing.<br />
<br />
=== Why do I read of users having access to a certain action and I don't see it on my system? ===<br />
<br />
Some actions only work with specific versions of Hugin or operating systems. It is possible that they have a different system than yours and that the plugin in question does not support your system. Often times this is just a matter of lack of testing resources on a particular platform. Help test the plugin and it may become accessible on your system as well.<br />
<br />
== Control Point creation ==<br />
<br />
=== How do I add control points ===<br />
The [[control points]] editor is quite powerful, but its usage is probably not obvious on the first try. Here are some ways the developers use the Control Point panel:<br />
<br />
1. Selecting control points in 100% zoom.<br />
<br />
This method needs some scrolling, if big images are used. You might want to try the fit to window zoom setting in that case. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: 100%<br />
[X] auto fine tune<br />
[X] auto add<br />
[X] auto estimate<br />
<br />
Click on a prominent feature in the left image. If the image pair already contains control points, [[hugin]] will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The second point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by dragging them to a better position. Press the "f" key to fine tune the point in a small area.<br />
<br />
<br />
2. Selecting control points in fit to window mode.<br />
<br />
I uses this mode if I need to set points on big images. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: fit to window<br />
[X] auto fine tune<br />
[ ] auto add<br />
[X] auto estimate<br />
<br />
Click on left image. The image will be shown in 100% view. Within the detailed view, click on a prominent feature. If the image pair already contains control points, hugin will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by clicking at the desired position. Move the point close to the desired feature and press the "f" key to fine tune the point. When the points are on the same feature, press the right mouse button, or press the "a" key to add the control point pair. It will then be shown in the list below the image.<br />
<br />
=== How do I scroll both images at the same time? ===<br />
<br />
Try pressing the shift key while moving the mouse. The control key or the middle mouse button can be used to scroll only the image under the mouse cursor.<br />
<br />
=== How do I stop Hugin pausing for a moment after every click? ===<br />
<br />
The ''preview window'' updates continuously whenever anything changes, so disable the preview auto-update, close it or make it smaller if you don't need it.<br />
<br />
Otherwise, picking [[control points]] with ''auto fine tune'' selected can involve a lot<br />
of processing. You can reduce this by ''selecting File -> Preferences -> Finetune'' and<br />
lowering the values for ''Patch width'', ''Search area width'' and ''Local search area width''.<br />
This means you can't be so sloppy when clicking to create control points, but the results will<br />
be the same.<br />
<br />
=== Windows: when user is not admin, not all cp-creators are available to choose from ===<br />
<br />
Preferences are stored in the registry on Windows. Every users has their own. To have all the cp-creator pre-sets like the admin users, hit the "Load defaults" button on the Control Points tab in the Preferences dialog.<br />
<br />
=== cpfind: not enough control points generated ===<br />
<br />
Cpfind is a recent addition to the Hugin suite and its parameters still require some fine tuning. Unlike older CP generators used with Hugin, it depends on information passed in the PTO file. Make sure that your input project file contains reasonable information about the used lens. If you are using a fisheye or wide angle lens, try increasing the parameters --sieve1width --sieve1height --sieve1size. A combinations that may work is "--sieve1width 50 --sieve1height 50 --sieve1size 300". Sometimes also the option "--fullscale" might help. Read the [[Cpfind]] documentation.<br />
<br />
== Common problems when creating a panorama ==<br />
<br />
=== I get thin horizontal black or white lines in large panoramas ===<br />
<br />
This is a known bug in the memory handling of [[enblend]] that manifests with large panoramas.<br />
<br />
You can workaround it by reducing the size of the panorama, or by adjusting the cache size in [[Hugin_Stitcher_tab]] -> '''Blender options'''. e.g. the default is 1024MB (1 GB), so if you have 4GB RAM you can try raising the cache to use most of your free memory, such as 3000MB, i.e: ''-m 3000''<br />
<br />
=== The Control Points tab shows my photos rotated ===<br />
<br />
The rotation of photos in the [[Hugin Control Points tab]] isn't necessarily<br />
related to the orientation of the files themselves.<br />
<br />
Hugin shows photos at the angle they best fit into the panorama, so if the<br />
panorama fit is bad, then you will see strange angles in the Control Points<br />
tab. Probably the problem is caused by bad alignment, you can<br />
identify 'bad' [[Control points]] in the [[Hugin Control Points table]], delete them and re-optimise.<br />
<br />
=== How can I reuse a project as a template? ===<br />
<br />
If you copy a .pto project to a different folder and open it with hugin, you will be prompted for the 'missing' images. You should delete any control points from this template project since they won't be relevant to the new photos.<br />
<br />
Alternatively you can load your images as normal, then ''Apply template''<br />
from the ''File'' menu, this will import image settings and parameters<br />
from a previous project.<br />
<br />
=== How do I straighten a curved horizon? ===<br />
If the panorama looks nice but the horizon is curved, there are various ways to improve the image and straighten the horizon.<br />
<br />
First, try clicking the '''Straighten''' button in the [[Hugin Fast Preview window]].<br />
<br />
If this doesn't work then you can use the Move/Drag tab of the [[Hugin Fast Preview window]] to visually straighten the panorama, drag the photos with the mouse, use the right mouse button to rotate. One useful tip is to drag the panorama so a vertical feature is in the middle, rotate it so the feature lines up with the 'cross hair', then drag the panorama up or down until all the vertical features in the scene are vertical on the screen (holding down the shift key while dragging limits the motion to just up/down or left/right).<br />
<br />
If it is still curved, you have to add vertical guide control points in the "Control Points" tab. Usually two [[vertical control points]] are enough to straighten the horizon nicely. Often edges of buildings, poles or other man made structures provide good vertical lines. To add a vertical control point, switch to the control point editor and select the same image on both sides. Place a control point on the left image on the upper area of the vertical feature. In the right image, select a control point on the lower area of the features, and press the Add button. Once the new point has been added, its type should automatically switch to "vertical line". You might want to switch off the auto-add and auto-estimate options while doing this to avoid naggy dialogs while adding these guide points. Two points that are roughly 90 degrees apart provide the best effect.<br />
<br />
See also the related perspective correction tutorials: [http://hugin.sourceforge.net/tutorials/architectural/en.shtml hugin tutorial on perspective correction], [[Perspective correction]], [[Leveling a Finished Panorama]]. While these are concerned with correction of the perspective in one image, the same technique can be used for<br />
leveling a panorama.<br />
<br />
=== Half the panorama is black, my pictures fill only the right half of the output ===<br />
<br />
Hugin uses the first photo as the ''anchor'' image and puts it in the middle by default. This means that if you shot a sequence from left to right, the images will fill the right hand side of the panorama. There are three ways to fix this:<br />
<br />
* Open the '''preview''' window and click the '''center''' button.<br />
* or select the middle photo, hit '''anchor this image for position''' and '''reset''' in the '''images''' tab, then reoptimise.<br />
* In the 'Fast Panorama Preview' window select 'Drag'. Left mouse drags the image, right mouse rotates the image.<br />
<br />
=== I get visible bands in the sky and other flat areas, what can I do? ===<br />
<br />
If the banding looks like [[w:Posterization|posterization]] then this is likely due to a error with estimation of the [[camera response curve]]. To get an accurate response curve, Hugin needs significant [[vignetting]] and/or [[bracketing|bracketed exposures]]. The workaround is to '''Reset...''' the '''Camera Response''' in the [[Hugin Camera and Lens tab]] and stitch again - [[Hugin]] usually produces acceptable results for a simple panorama when the camera response parameters are all zero.<br />
<br />
If there is a wave of light and dark patches in the sky this could be due to [[vignetting]] in the source photos, you can deal with this by optimising '''Vignetting (Vb, Vc, Vd)''' in the [[Hugin Exposure tab]]. Another workaround is to increase the number of [[enblend]] blending levels, try setting '-l 29' as the enblend '''Command line options''' in the [[Hugin Stitcher tab]].<br />
<br />
=== My photos never quite line up, what can I do? ===<br />
<br />
It is normal to get little stitching [[parallax]] errors if<br />
the camera moves between photos. The solution is to rotate the camera around<br />
the [[no-parallax point]] using a [[Heads|panoramic head]] or [[philopod]].<br />
<br />
Otherwise you can sometimes improve things by optimising the ''d & e'' parameters<br />
separately - When you optimise '''everything''', unselect '''Inherit''' in<br />
the '''camera and Lens''' panel for 'd & e'. Also you can open the control point window sort it by distance and check the ones large distance.<br />
<br />
If these parallax errors are still large, you need to decide which<br />
parts of the scene that you want to line-up and which parts don't<br />
matter. Select [[control points]] only on objects that you do want to<br />
line-up and which are all about the same distance from the camera.<br />
<br />
The remaining broken lines can then be retouched in a photo editor like the [[gimp]].<br />
The ''shear'' tool is ideal for bending the lines and<br />
[[Mending parallax errors with the shear tool|getting them to line up]].<br />
<br />
=== I have extracted and edited cubefaces and want to merge them together again. How do I do that ? ===<br />
<br />
Manually enter the values for [[yaw]] and [[pitch]] for each of the photos. When you stitch set the '''enblend options''' in the [[Hugin Stitcher tab]] to -l1 --fine-mask --no-optimize<br />
<br />
=== Can I stitch my HDR images ? ===<br />
<br />
Yes. If you already have merged your HDR stacks, follow the '''Normal''' Output on the '''Stitcher''' tab ('''HDR merging''' is for stacks that will be merged by Hugin). In the '''Processing''' step the output will be an HDR in TIFF format.<br />
<br />
=== Why is my panorama upside down ? ===<br />
<br />
Hugin stitches the panorama on a sphere and can't determine what is up or what is down. Even if vertical control points are assigned, there is still no notion of up and down, so the panorama can flip upside down. The solution for that is to open the Preview window, click on the Num. Trans. button in the toolbar, enter 180 in the roll field and apply. This will flip the panorama back to the right orientation.<br />
<br />
=== Why do multi-lens projects end up distorted/broken? ===<br />
<br />
You have probably optimized 'Everything'. This will cause the optimizer to try to optimize lens parameters for each of the different lenses, and there may not be a big enough spread of control points for the optimization to work well.<br />
When stitching photos from different lenses, or when you don't have a good spread of control points, optimize 'Position, view & Barrel (y,p,r,v,b).<br />
<br />
=== Why does my output covers only 180°? ===<br />
<br />
Did you observe that the output is cropped at the +-90° borders? (e.g. saw teeth like borders in the fast preview window)<br />
<br />
Then you have probably used the translation parameters X/Y/Z. This behaviour is a fundamental limitation of the used approach of the translation parameters. It is (internal) working in the rectilinear space, which is limited to maximal FOV of 180°, and therefore also the output is limited to FOV<180° (for more information see [[Stitching a photo-mosaic]]).<br />
<br />
The solution/workaround is to set all X/Y/Z values to zero or to limit the horizontal field of view (HFOV) to a value smaller than 180°.<br />
<br />
== GPU-stitching (nona) ==<br />
<br />
Starting with Hugin-2009.2 nona has a new, experimental feature: it can use the video card (GPU) to accelerate the stitching. How much acceleration you will get, if any, depends on the combination of video card and driver.<br />
<br />
=== I get a nona: GL error. Does this mean that I found a bug? ===<br />
<br />
Not necessarily. This functionality is highly experimental. It may be that you have an outdated driver, or that the functionality is not supported on your video card. Note down the version of the driver you are using and the specs of your video card (GPU and RAM). Then update to the latest driver from [http://www.nvidia.com/page/drivers.html nVidia] or [http://support.amd.com/us/gpudownload/Pages/index.aspx AMD] (ATI has been bought by AMD). Currently only these two families of GPUs support the functionality.<br />
<br />
=== How can I know if nona-GPU works on my system? ===<br />
<br />
At the moment we have too little information to predict this. We know that only nVidia and AMD(ATI) powered video cards work, and not all of them. The more recent the video card, the higher the likelihood that it works. Improve your chances by updating to the latest driver for your GPU. Look at experience reports from other users and report your experience [[Nona GPU stitching reports|here]].<br />
<br />
=== What speed improvement can I expect? ===<br />
<br />
It depends on the video card. Bandwidth is mostly the bottleneck, specifically getting the transformed data from the GPU back to the main system memory.<br />
<br />
=== Bug Reporting ===<br />
<br />
When reporting success or failure using the GPU for stitching, always report also the driver version, video card GPU and RAM. Tell us what you were doing, the size and number of input images (note that if you stitch from within Hugin or PTBatcher, it is only one input image at a time).<br />
<br />
== Postprocessing ==<br />
<br />
=== Why is the ICC profile of my input images not preserved? ===<br />
<br />
Since hugin 0.5 and enblend 2.4 [[colour profile|ICC profiles]] in the input files are transfered to the output panorama. Please update to a current version.<br />
<br />
=== How can I postprocess the image using multiple layers in The Gimp? ===<br />
<br />
* Use the [[nona]] stitcher on the command-line, to output to a multilayer [[TIFF]] format:<br />
<br />
nona -m TIFF_multilayer -o multi_layer.tif project.pto<br />
<br />
This will will produce a multi_layer.tif file, that contains all remapped images, cropped to their bounding box.<br />
<br />
* Alternatively select the '''Remapped Images''' option in the [[Hugin Stitcher tab]], this will create each ''layer'' as a separate file. Then use the '''tiffcp''' command-line tool (part of libtiff) to join them together into a multi-page TIFF:<br />
<br />
tiffcp project0000.tif project0001.tif project0002.tif multi_layer.tif<br />
<br />
* You can also use [[tif2xcf]], to combine the '''Remapped Images''' TIFF output into a multilayer XCF.<br />
Unfortunately this requires a lot of memory because it stores each remapped image in a layer with the size of the final panorama.<br />
<br />
== Installation ==<br />
<br />
=== Where can I download hugin installers ===<br />
<br />
Official releases are available from [http://hugin.sourceforge.net/download/ hugin.sf.net].<br />
<br />
=== How can I compile Hugin.app on my OSX machine? ===<br />
<br />
See [[Hugin Compiling OSX]], [[Autopano-sift-C Compiling OSX]] and [[Enblend Compiling OSX]].<br />
<br />
=== How do I compile hugin on my linux machine? ===<br />
<br />
See [[Hugin Compiling Fedora]], [[Hugin Compiling Gentoo]], [[Hugin Compiling OpenSuse]] and [[Hugin Compiling Ubuntu]]<br />
<br />
=== make[2]: *** No rule to make target `/usr/lib/libGL.so', needed by `src/hugin_base/libhuginbase.so.0.0'. Stop. ===<br />
<br />
So you're trying to build from source. Most likely you have proprietary nVidia or ATI drivers. They are a moving target and so is X. On debian based systems including Ubuntu, diagnose with `dpkg -S /usr/lib/libGL.so` and check that the linked library exist (i.e. it is not listed in red when doing `ll /usr/lib/mesa/libGL.so`). If it is listed in red, check where the library is (`ll /usr/lib/libGL*` is a good start on Ubuntu) and link it properly.<br />
<br />
=== How do I compile hugin on my Windows machine? ===<br />
<br />
See [[Hugin Compiling Windows]]<br />
<br />
=== Enblend-Enfuse OpenMP SSE GPU: which one is the right one for me? ===<br />
<br />
Enblend and Enfuse can be optimized at build time for different hardware configurations. This yields four categories of Enblend-Enfuse builds, with a few variations. If you build Enblend-Enfuse from source, check the build options in the README file. If you download a binary, you can find out how it has been built with the following command:<br />
<br />
enblend -v -V<br />
<br />
look for the following in the output text:<br />
<br />
# '''Extra feature: OpenMP: yes''' this version has OpenMP.<br />
# '''Extra feature: image cache: yes''' this version has image cache<br />
# '''Extra feature: GPU acceleration: yes''' this version has GPU support<br />
# SSE-support is not mentioned, you'll find out if you have an unsupported CPU and the binary will refuse to run.<br />
<br />
These are approximate guidelines to help you choose what may work for you:<br />
<br />
* if you have a recent, multi-core / multi-thread CPU, you probably want the OpenMP-enabled version. Note however that speed improvement does not scale well, so don't expect a 6 cores CPU to be 3x faster than a 2 cores one.<br />
* if you have a recent, fast video card, you probably want the GPU-enabled version. This is not mutually exclusive with OpenMP and a good builder will add both features to his binaries. If speed is important to you, you want to test which of the two is faster on your system. If system responsiveness is important to you, the GPU-enabled version frees CPU resources for your other tasks. Note that even if your binary is GPU-enabled, the GPU will not be used unless you specify the option `--gpu`.<br />
* if you have an old CPU without SSE2 support, you want a NOSSE build. This is the least performing version.<br />
* Last but not least, if blending fails because of large images, try the image cache variation. The image cache allows for processing of large project when memory is scarce but images are large (and disk is large enough too). Image cache is incompatible with OpenMP, but a good bilder will make this version GPU-enabled too, so test it with `--gpu` if speed is important.<br />
<br />
=== Selecting right version of enblend-enfuse binary for Windows ===<br />
<br />
There are 3 variants of enblend-enfuse binaries officially released for Windows. Each one has a special feature set: <br />
<br />
1. enblend.exe/enfuse.exe<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_openmp.exe/enfuse_openmp.exe<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache. In this case, please switch to the standard version.<br />
For running the OpenMP variants you will need [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en "Microsoft Visual C++ 2008 Redistributable Package (x86)"].<br />
<br />
<br />
3. enblend_nosse.exe/enfuse_nosse.exe<br />
<br />
If you have an old CPU without [http://en.wikipedia.org/wiki/SSE2 SSE2] support, you want a NOSSE build. This is the least performing version.<br />
You will need to download a separate package to get this version from [http://sourceforge.net/projects/enblend/files/enblend-enfuse/enblend-enfuse-4.0/enblend-enfuse-4.0-win32-nosse.zip/download sourceforge.net]<br />
<br />
All three variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
<br />
=== Selecting right version of enblend-enfuse binary for Debian/Ubuntu ===<br />
<br />
At the time of writing the official Debian/Ubuntu package ships with one executable only, however in July 2010 a change has been committed to debian-unstable that delivers two binaries:<br />
<br />
1. enblend/enfuse<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_mp/enfuse_mp<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache.<br />
<br />
Both variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
== Support ==<br />
<br />
=== Reporting Bugs ===<br />
<br />
If you think you have found a bug in Hugin, please report it to help us make Hugin better. Before reporting a bug, try a few things to make sure it is really a bug. Then collect the following information and transmit it to the developers via the bug tracker.<br />
# What version of Hugin are you using? Consider upgrading and try to reproduce the bug. Maybe it was fixed in a more recent version.<br />
# read the output log. Are there any suggested actions or messages in there? If so, follow the advice and try again. Save the output log to a text file and attach it to the report if you file a bug report. <br />
# Attach the .pto file to the bug report.<br />
# Use a meaningful title for the bug report. The line reporting the error in the output log is a good place to start. Before filing a new bug report, check for duplicates. Launchpad does already a little bit so. If the bug is already known, add yourself and you files with a comment to the bug. This will give your report and your log more visibility than if somebody looking at your bug has to mark it as duplicate.<br />
<br />
=== Why is my Bug Report marked Invalid? ===<br />
<br />
We trust you that you are experiencing the issue on your end and that it bugs you, but most likely the solution lies not in the Hugin codebase. If you feel that your report has been marked Invalid by mistake, feel free to reply and to set the status back to New for a re-evaluation. Somebody may explain to you why the report was marked as Invalid and what you can do.<br />
<br />
=== Why is my Bug Report marked Incomplete? ===<br />
<br />
Every system is different and those trying to help fixing the bugs do not see and experience what you do. In order to help you, they are likely to need more information. Without that information the bug report is of little use. We mark as Incomplete reports that require additional information. Once you provide it, please mark the report status as New again<br />
<br />
=== How do I Change the Status of my Report? ===<br />
<br />
* If you reply via the web interface: hit the yellow round button next to the current status to get a selection of stati. Unless you know what you are doing, set it to New to attract developer's attention.<br />
* If you reply by email: at the bottom of your email enter a line starting with one single space and the following words: <code> status new</code>. Read more about the [https://help.launchpad.net/Bugs/EmailInterface email interface].<br />
<br />
=== User Support: Mailing List ===<br />
<br />
Hugin has a lively and friendly user groups. Connect with expert users and ask questions on the Hugin-PTX mailing list. To subscribe send an empty email to hugin-ptx+subscribe@googlegroups.com and follow the instructions in the email you receive back.<br />
To ask questions, send an email to hugin-ptx@googlegroups.com<br />
Your first emails will be moderated, so be patient if you don't see your message right away.<br />
<br />
<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Linefind&diff=13731Linefind2011-09-18T21:28:27Z<p>Bruno: typos</p>
<hr />
<div>= General and description =<br />
'''Linefind''' is a detector for vertical features in images. It tries to find vertical lines using the same algorithm as [[Calibrate lens gui#Line detection|Calibrate_lens_gui]] and assigns [[Vertical control points|vertical control points]] to them. The detection runs on the source images, if the input images are [[Rectilinear Projection|rectilinear images]]. In the other cases (e. g. [[Fisheye Projection|fisheye images]]) the input images are reprojected to an [[Equirectangular Projection|equirectangular projection]] and the detection works on the reprojected images.<br />
It uses the [[roll|roll value]], saved in the pto project file, to determine what is "top" and "bottom". So before running '''linefind''' check that your [[roll|roll values]] are correct (E. g. when using images straight from the camera, use a roll value of 0 for landscape and a value of 90 or 270 for portrait images. If your camera has an orientation sensor, [[Hugin]] can detect this information automatically and sets the roll value accordingly when adding such images into Hugin.<br />
<br />
= Usage =<br />
<br />
The general usage is<br />
linefind -o output.pto input.pto<br />
If the --output/-o switch is missing then the suffix "_line" is added to the filename.<br />
<br />
The maximal number of lines added per image can be given with the --lines switch (or short -l):<br />
linefind --lines=10 -o output.pto input.pto<br />
By default maximal 5 lines per image are added to the project file. <br />
<br />
'''Attention:''' Keep in mind that more [[Vertical control points|vertical control points]] will dominate the optimisation in favour of [[Control points|"normal" control points]]. <br />
<br />
Normally '''linefind''' tries to find vertical lines in all images of the project file. If you want to limit the detection to some selected images, you can use the --image/-i switch, e.g.<br />
linefind --image=0 --image=4 -o output.pto input.pto<br />
will only search for vertical lines in image 0 and 4.</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_FAQ&diff=13654Hugin FAQ2011-07-15T22:35:14Z<p>Bruno: /* Common problems when creating a panorama */</p>
<hr />
<div>== Common error messages ==<br />
<br />
=== enblend: no input files specified ===<br />
<br />
There are no input images relevant to the output 'panorama' so hugin had nothing to do, probably because all the input images are outside the panorama 'frame' or disabled. Open the [[Hugin Preview window]] or [[Hugin Fast Preview window]] to adjust the view, enable some images inside the panorama frame and/or adjust the crop.<br />
<br />
Note also that hugin versions up to and including 2009.2.0 allow you to draw an inverted crop frame where the top is below the bottom, this is easy to see in the Preview window as the entire panorama is 'greyed'. A crop frame drawn like this will result in an empty panorama and the above error message.<br />
<br />
=== enblend: excessive overlap detected ===<br />
<br />
This is an error new to enblend-4.0. Photos that nearly entirely overlap won't blend very well, enblend now fails instead of attempting to blend them. There are various workarounds:<br />
<br />
* Follow the error message and remove the suggested image from the set, you probably don't need it to complete the panorama.<br />
* Switch back to enblend-3.2.<br />
* Hugin will merge stacked images before blending if you select 'Exposure fusion' in the [[Hugin Stitcher tab]]. This error will go away, but Hugin will take a very different approach to variable exposure between photos.<br />
* Mask out major parts of one image.<br />
<br />
=== enblend: error writing to image swap file ===<br />
<br />
[[enblend]] needs a lot of memory and uses its own swap routine to store picture data on the disk, this message indicates that you have run out of disk space. The data is stored in the system temp folder which is specified by TMP, TEMP or TMPDIR environment variables, note that this temp folder may be on a different physical disk to your photos and panorama output.<br />
<br />
=== execvp(make ...) failed with error 2 ===<br />
<br />
Hugin requires the 'make' utility to stitch, you need to install it and/or report the problem to whoever supplied Hugin to you.<br />
<br />
=== false --compression NONE ===<br />
<br />
This error is caused by a bug in the 0.7.0 release that is fixed in 0.8.0. The problem is that your preferences are messed-up, the workaround for 0.7.0 is to go to File -> Preferences -> Enblend and click Load Defaults -> Yes -> Ok<br />
<br />
=== Enblend error: Mask is entirely black, but white image was not identified as redundant ===<br />
<br />
This is a well known "error" for [[enblend]]. Try to use the additional enblend parameter "--fine-mask" to get rid of the error. The parameter will result in generation of masks in higher resolution that will fix the problem in most cases. Sometimes the "--fine-mask" parameter may result in memory errors (malloc: ...), which are the result of not enough memory available due to the (much) bigger masks that are used.<br />
<br />
An alternative workaround would be to set the enblend --no-optimize parameter, this will place the seam directly along the middle of the image overlaps regardless of image content. This option is also considerably faster and uses less memory.<br />
<br />
This error also occurs when one photo is completely covered by another, try removing redundant photos.<br />
<br />
Note also that for the same reasons this error often appears when rendering a scene with extreme distortion such as a stereographic 'little planet'. For this and other reasons, such as overall speed, it is always preferable to render a 'normal' 360° [[Equirectangular Projection]] panorama first, then load this as a single source image into a new project and render whatever views you need.<br />
<br />
Note (Jan 2010): This should be fixed in the latest [[enblend]] 4.0 release.<br />
<br />
=== enblend: illegal option -- compression ===<br />
<br />
hugin 0.7.0 and later versions require at least [[enblend]] version 3.2. This error indicates that you need to upgrade enblend.<br />
<br />
=== enblend: Error -1073741795 ===<br />
<br />
See [[#Enblend: The system cannot execute the specified command]], in particular if you are a Windows user try switching to the 'nosse' enblend-enfuse.<br />
<br />
=== Makefile: target pattern contains no % ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== gnumake: *** No rule to make target ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== nona: GL error: Framebuffer incomplete, incomplete attachment in: ===<br />
<br />
This is a message generated by nona when using the GPU for stitching (feature available starting with Hugin-2009.2.0). See section below about [[#GPU-stitching_.28nona.29|GPU-stitching]].<br />
<br />
=== make: enfuse: command not found ===<br />
<br />
This is a message generated by make when assembling your panorama. It most likely means that enfuse is not on your computer. Enfuse is part of the enblend package, but many Linux distributions, even recent ones, ship with an older version of enblend that does not contain enfuse. You need to install enblend-3.2 or later.<br />
<br />
=== Enblend: The system cannot execute the specified command ===<br />
<br />
This message could be generated by either<br />
* the lack of Microsoft Visual C++ 2008 Redistributable Package (x86) that is necessary to run an OpenMP enabled version of Enblend. Download [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here].<br />
* the lack of [http://en.wikipedia.org/wiki/SSE2 SSE2] support. Use a non-SSE build of Enblend. See also [[#Enblend-Enfuse_OpenMP_SSE_GPU:_which_one_is_the_right_one_for_me.3F | types of Enblend-Enfuse binaries]] or [[#Selecting_right_version_of_enblend-enfuse_binary_for_Windows | types of Enblend-Enfuse binaries for Windows ]]<br />
<br />
===Windows error message "application configuration is incorrect"===<br />
<br />
Double clicking the Hugin icon to run the program produces a message like this:<br />
<pre><br />
C:\Program Files\Hugin\bin\hugin.exe<br />
This application has failed to start because the application configuration is incorrect.<br />
Reinstalling the application may fix this problem.<br />
</pre><br />
Try installing the [http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Microsoft Visual C++ redistributable].<br />
<br />
=== Stitching fails on Windows (syntax error)===<br />
<br />
If the stitching step fails on windows with a error message like<br />
<br />
<pre><br />
/usr/bin/sh: -c: line 1: syntax error near unexpected token `(6'<br />
/usr/bin/sh: -c: line 1: `echo Operating System: Windows 7 (6.1 )'<br />
make: *** [info] Error 258<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
Syntax error: "(" unexpected<br />
make: *** [info] Error 2<br />
</pre><br />
<br />
then you have probably an other shell (e.g. sh.exe or bash.exe) somewhere in your path. In this case remove the path to this executable from the PATH variable.<br />
<br />
=== Hugin Quits (Seg Faults) at Launch (Linux) ===<br />
<br />
There may be many reasons why a program dies before it has even started.<br />
<br />
One possibility is bad configuration or installation of the video drivers. See this [https://bugs.launchpad.net/hugin/+bug/679427 ticket]. To diagnose, try running glxgears. On Ubuntu (the package is probably available on most Linux distributions):<br />
<br />
<pre><br />
sudo apt-get mesa-utils<br />
glxgears<br />
</pre><br />
<br />
If glxgears does not run on your system, Hugin will not run either. See your Linux distribution's instruction on how to fix the video drivers.<br />
<br />
== Known Limitations ==<br />
<br />
=== Linux: Compiz ===<br />
<br />
Linux: Compiz interferes with the [[hugin Fast Preview window]]. This is not a hugin specific issue. Research shows all direct rendered stuff will have various problems under Compiz: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/96991<br />
<br />
This problem is fixed with DRI2, e.g with fedora 11 and intel graphics hardware you can have a 'wobbly' Fast Preview window if you really want.<br />
<br />
It's not an issue with NVidia's proprietry driver.<br />
<br />
If you're affected, the workaround is to not use Compiz.<br />
<br />
=== Windows: International Characters in Path ===<br />
<br />
Hugin is fully internationalised and can cope with special characters in file paths. However, hugin apparently fails on some Windows systems with Polish, Japanese, Russian or Czech codepages, the workaround is to use shell-safe ascii characters in file and folder names: '''A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 - _ .''' This includes the path for the temporary folder which is named after your username on Windows systems.<br />
<br />
=== OSX: error when clicking on the help button ===<br />
<br />
In a language other than English, French or Italian you get an error message when clicking on the help button. This will be fixed in Hugin-2009.4.0. In the meantime, the work around is to change language to one of the above three; or to ask for help on the mailing list. <br />
<br />
=== Non-Unique Filenames ===<br />
<br />
Some components of Hugin have been reported not to deal well with image files<br />
that have the same name in different folders. The workaround is to rename <br />
your images files so that all image files in a project are unique.<br />
<br />
=== Temporary Files ===<br />
<br />
Hugin has a preference setting for the temporary files folder. Currently it<br />
is not implemented properly and files will be written in the same folder as<br />
the project file.<br />
<br />
A partial workaround on Linux is to start Hugin from a terminal with<br />
<pre><br />
TMPDIR=/media/disk-2/tmp hugin &<br />
</pre><br />
<br />
These temporary files have to be deleted manually after the stitch.<br />
<br />
=== Special Characters in Paths ===<br />
<br />
{| style="margin: 1em auto 1em 1em;background:#FFFF99;color:#FF0000;text-align:left;border: solid #FF3300;"<br />
|-valign="top"<br />
! =<br />
! ;<br />
! :<br />
! $<br />
! "<br />
! %<br />
! #<br />
! |<br />
! '<br />
! (<br />
! )<br />
! `<br />
! &<br />
! *<br />
! +<br />
! ^<br />
! ~<br />
! <<br />
! ?<br />
! ><br />
! and the space character.<br />
|}<br />
<br />
Hugin currently does not do plausibility checks on the paths and file names that are given to it. It relies on the operating system's conventions and limitations. However Hugin uses make to run the stitching process, and make has more restrictive limitation than the operating system.<br />
<br />
Please don't use the above characters in your files and folders when you want to make sure they work with Hugin. If you absolutely need files named this way, rename them after processing. Do not file bug reports based on filenames with the above characters. The [https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2883450&group_id=77506 issue] is known, analyzed, and may be fixed in the future.<br />
<br />
=== Stitch fails when '&' is part of the Windows 7 ''user-name'' ===<br />
<br />
This is a variant of the above, but more difficult to work around. The ''user-name'' is part of all paths in the user's data area, including the temporary file locations defined by TMP and TEMP. Stitch fails almost immediately with a make path error.<br />
<br />
Work-around: Move your hugin data to a folder in the root directory such as C:\hugin. Then go to the Windows Control Panel and change ''System, Advanced, Environment, user TMP'' to a folder in the root, such as 'C:\temp' (create it if necessary).<br />
<br />
Notes: This work-around probably needs Win 7 ''Administrator'' privileges.<br />
<br />
A simpler solution should be to set hugin ''File, Preferences, Temporary dir'' to C:\hugin; but it doesn't fix<br />
the problem! Seemingly, at least one temporary file still gets created in the TMP folder.<br />
<br />
=== Hugin fails stitching some stereographics and other polar projections ===<br />
<br />
This is a known limitation caused by photos being distorted into extreme 'C' and 'O' shapes. The workaround: stitch all of your pictures into a single equirectangular, and then load the equirectangular into Hugin to generate the stereographic or other projections you wanted to do in the first place.<br />
<br />
<br />
=== OSX / iPhoto ===<br />
<br />
Dragging the photos from iPhoto to Hugin works perfectly as long as there is no forward slash in the Name of the events in iPhoto (which translates to folders inside the iPhoto Database).<br />
<br />
=== Fast Preview ===<br />
<br />
Why are there two preview windows, and which one should I use?<br />
<br />
For most purposes, the newer Fast Preview window is faster. However it is still under development and sometimes shows artefacts. The old preview still does a logarithmic tone mapping of stacked<br />
images and is the only way to preview hdr or fused output.<br />
<br />
=== Makefile based stitching process ===<br />
<br />
Can I restart a stitching process that was interrupted manually or by an error without starting everything from scratch?<br />
<br />
Unfortunately the Hugin Makefile system only supports restarting if you stitch on the command-line. The GUI tools always create new temporary .pto project and Makefile files every time they stitch, so this forces make to recreate everything for every stitch.<br />
<br />
== Python Scripting ==<br />
<br />
=== What is Python Scripting? ===<br />
<br />
Python is a powerful scripting language. Starting with Hugin 2011.2, Hugin exposes the panorama object through hsi.py in Python. It must be explicitly activated at build time with the CMake boolean parameter -DBUILD_HSI:BOOL=ON. It is currently untested / unavailable on OSX.<br />
<br />
=== How do I start Scripting? ===<br />
<br />
<pre><br />
$ python<br />
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) <br />
[GCC 4.5.2] on linux2<br />
Type "help", "copyright", "credits" or "license" for more information.<br />
>>> import hsi<br />
>>> help (hsi)<br />
</pre><br />
<br />
=== What is the difference between a Plugin and a Script? ===<br />
<br />
Strictly speaking, they are both Python scripts. A Plugin runs inside Hugin, while a Script runs in a shell or desktop.<br />
<br />
=== Where Are the Plugins in Hugin and how do I use them? ===<br />
<br />
If Hugin was compiled with HSI, a menu Action will list categories of system-wide plugins. Just select one to run it. Moreover, you can write your own plugins and run them with the menu Edit -> Run User Python Plugin. The default location for user plugins is set in the preferences.<br />
<br />
=== Script Returned -10 ===<br />
<br />
This error message indicates that the plugin tried to import something and failed. hpi.py currently has no other way of telling hugin what's wrong than to 'return -10'. Try to start Hugin from the command line and see if there is more verbose output there. Copy the output and ask for help on hugin-ptx.<br />
<br />
=== Script Returned -11 ===<br />
<br />
The plugin failing with an exception. Ask the plugin maintainer to produce more specific error messages. It is good practice to catch such exceptions and let the user know what dependency is missing.<br />
<br />
=== Why do I read of users having access to a certain action and I don't see it on my system? ===<br />
<br />
Some actions only work with specific versions of Hugin or operating systems. It is possible that they have a different system than yours and that the plugin in question does not support your system. Often times this is just a matter of lack of testing resources on a particular platform. Help test the plugin and it may become accessible on your system as well.<br />
<br />
== Control Point creation ==<br />
<br />
=== How do I add control points ===<br />
The [[control points]] editor is quite powerful, but its usage is probably not obvious on the first try. Here are some ways the developers use the Control Point panel:<br />
<br />
1. Selecting control points in 100% zoom.<br />
<br />
This method needs some scrolling, if big images are used. You might want to try the fit to window zoom setting in that case. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: 100%<br />
[X] auto fine tune<br />
[X] auto add<br />
[X] auto estimate<br />
<br />
Click on a prominent feature in the left image. If the image pair already contains control points, [[hugin]] will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The second point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by dragging them to a better position. Press the "f" key to fine tune the point in a small area.<br />
<br />
<br />
2. Selecting control points in fit to window mode.<br />
<br />
I uses this mode if I need to set points on big images. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: fit to window<br />
[X] auto fine tune<br />
[ ] auto add<br />
[X] auto estimate<br />
<br />
Click on left image. The image will be shown in 100% view. Within the detailed view, click on a prominent feature. If the image pair already contains control points, hugin will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by clicking at the desired position. Move the point close to the desired feature and press the "f" key to fine tune the point. When the points are on the same feature, press the right mouse button, or press the "a" key to add the control point pair. It will then be shown in the list below the image.<br />
<br />
=== How do I scroll both images at the same time? ===<br />
<br />
Try pressing the shift key while moving the mouse. The control key or the middle mouse button can be used to scroll only the image under the mouse cursor.<br />
<br />
=== How do I stop Hugin pausing for a moment after every click? ===<br />
<br />
The ''preview window'' updates continuously whenever anything changes, so disable the preview auto-update, close it or make it smaller if you don't need it.<br />
<br />
Otherwise, picking [[control points]] with ''auto fine tune'' selected can involve a lot<br />
of processing. You can reduce this by ''selecting File -> Preferences -> Finetune'' and<br />
lowering the values for ''Patch width'', ''Search area width'' and ''Local search area width''.<br />
This means you can't be so sloppy when clicking to create control points, but the results will<br />
be the same.<br />
<br />
=== Windows: when user is not admin, not all cp-creators are available to choose from ===<br />
<br />
Preferences are stored in the registry on Windows. Every users has their own. To have all the cp-creator pre-sets like the admin users, hit the "Load defaults" button on the Control Points tab in the Preferences dialog.<br />
<br />
=== cpfind: not enough control points generated ===<br />
<br />
Cpfind is a recent addition to the Hugin suite and its parameters still require some fine tuning. Unlike older CP generators used with Hugin, it depends on information passed in the PTO file. Make sure that your input project file contains reasonable information about the used lens. If you are using a fisheye or wide angle lens, try increasing the parameters --sieve1width --sieve1height --sieve1size. A combinations that may work is "--sieve1width 50 --sieve1height 50 --sieve1size 300". Sometimes also the option "--fullscale" might help. Read the [[Cpfind]] documentation.<br />
<br />
== Common problems when creating a panorama ==<br />
<br />
=== I get thin horizontal black or white lines in large panoramas ===<br />
<br />
This is a known bug in the memory handling of [[enblend]] that manifests with large panoramas.<br />
<br />
You can workaround it by reducing the size of the panorama, or by adjusting the cache size in [[Hugin_Stitcher_tab]] -> '''Blender options'''. e.g. the default is 1024MB (1 GB), so if you have 4GB RAM you can try raising the cache to use most of your free memory, such as 3000MB, i.e: ''-m 3000''<br />
<br />
=== The Control Points tab shows my photos rotated ===<br />
<br />
The rotation of photos in the [[Hugin Control Points tab]] isn't necessarily<br />
related to the orientation of the files themselves.<br />
<br />
Hugin shows photos at the angle they best fit into the panorama, so if the<br />
panorama fit is bad, then you will see strange angles in the Control Points<br />
tab. Probably the problem is caused by bad alignment, you can<br />
identify 'bad' [[Control points]] in the [[Hugin Control Points table]], delete them and re-optimise.<br />
<br />
=== How can I reuse a project as a template? ===<br />
<br />
If you copy a .pto project to a different folder and open it with hugin, you will be prompted for the 'missing' images. You should delete any control points from this template project since they won't be relevant to the new photos.<br />
<br />
Alternatively you can load your images as normal, then ''Apply template''<br />
from the ''File'' menu, this will import image settings and parameters<br />
from a previous project.<br />
<br />
=== How do I straighten a curved horizon? ===<br />
If the panorama looks nice but the horizon is curved, there are various ways to improve the image and straighten the horizon.<br />
<br />
First, try clicking the '''Straighten''' button in the [[Hugin Fast Preview window]].<br />
<br />
If this doesn't work then you can use the Move/Drag tab of the [[Hugin Fast Preview window]] to visually straighten the panorama, drag the photos with the mouse, use the right mouse button to rotate. One useful tip is to drag the panorama so a vertical feature is in the middle, rotate it so the feature lines up with the 'cross hair', then drag the panorama up or down until all the vertical features in the scene are vertical on the screen (holding down the shift key while dragging limits the motion to just up/down or left/right).<br />
<br />
If it is still curved, you have to add vertical guide control points in the "Control Points" tab. Usually two [[vertical control points]] are enough to straighten the horizon nicely. Often edges of buildings, poles or other man made structures provide good vertical lines. To add a vertical control point, switch to the control point editor and select the same image on both sides. Place a control point on the left image on the upper area of the vertical feature. In the right image, select a control point on the lower area of the features, and press the Add button. Once the new point has been added, its type should automatically switch to "vertical line". You might want to switch off the auto-add and auto-estimate options while doing this to avoid naggy dialogs while adding these guide points. Two points that are roughly 90 degrees apart provide the best effect.<br />
<br />
See also the related perspective correction tutorials: [http://hugin.sourceforge.net/tutorials/architectural/en.shtml hugin tutorial on perspective correction], [[Perspective correction]], [[Leveling a Finished Panorama]]. While these are concerned with correction of the perspective in one image, the same technique can be used for<br />
leveling a panorama.<br />
<br />
=== Half the panorama is black, my pictures fill only the right half of the output ===<br />
<br />
Hugin uses the first photo as the ''anchor'' image and puts it in the middle by default. This means that if you shot a sequence from left to right, the images will fill the right hand side of the panorama. There are three ways to fix this:<br />
<br />
* Open the '''preview''' window and click the '''center''' button.<br />
* or select the middle photo, hit '''anchor this image for position''' and '''reset''' in the '''images''' tab, then reoptimise.<br />
* In the 'Fast Panorama Preview' window select 'Drag'. Left mouse drags the image, right mouse rotates the image.<br />
<br />
=== I get visible bands in the sky and other flat areas, what can I do? ===<br />
<br />
If the banding looks like [[w:Posterization|posterization]] then this is likely due to a error with estimation of the [[camera response curve]]. To get an accurate response curve, Hugin needs significant [[vignetting]] and/or [[bracketing|bracketed exposures]]. The workaround is to '''Reset...''' the '''Camera Response''' in the [[Hugin Camera and Lens tab]] and stitch again - [[Hugin]] usually produces acceptable results for a simple panorama when the camera response parameters are all zero.<br />
<br />
If there is a wave of light and dark patches in the sky this could be due to [[vignetting]] in the source photos, you can deal with this by optimising '''Vignetting (Vb, Vc, Vd)''' in the [[Hugin Exposure tab]]. Another workaround is to increase the number of [[enblend]] blending levels, try setting '-l 29' as the enblend '''Command line options''' in the [[Hugin Stitcher tab]].<br />
<br />
=== My photos never quite line up, what can I do? ===<br />
<br />
It is normal to get little stitching [[parallax]] errors if<br />
the camera moves between photos. The solution is to rotate the camera around<br />
the [[no-parallax point]] using a [[Heads|panoramic head]] or [[philopod]].<br />
<br />
Otherwise you can sometimes improve things by optimising the ''d & e'' parameters<br />
separately - When you optimise '''everything''', unselect '''Inherit''' in<br />
the '''camera and Lens''' panel for 'd & e'. Also you can open the control point window sort it by distance and check the ones large distance.<br />
<br />
If these parallax errors are still large, you need to decide which<br />
parts of the scene that you want to line-up and which parts don't<br />
matter. Select [[control points]] only on objects that you do want to<br />
line-up and which are all about the same distance from the camera.<br />
<br />
The remaining broken lines can then be retouched in a photo editor like the [[gimp]].<br />
The ''shear'' tool is ideal for bending the lines and<br />
[[Mending parallax errors with the shear tool|getting them to line up]].<br />
<br />
=== I have extracted and edited cubefaces and want to merge them together again. How do I do that ? ===<br />
<br />
Manually enter the values for [[yaw]] and [[pitch]] for each of the photos. When you stitch set the '''enblend options''' in the [[Hugin Stitcher tab]] to -l1 --fine-mask --no-optimize<br />
<br />
=== Can I stitch my HDR images ? ===<br />
<br />
Yes. If you already have merged your HDR stacks, follow the '''Normal''' Output on the '''Stitcher''' tab ('''HDR merging''' is for stacks that will be merged by Hugin). In the '''Processing''' step the output will be an HDR in TIFF format.<br />
<br />
=== Why is my panorama upside down ? ===<br />
<br />
Hugin stitches the panorama on a sphere and can't determine what is up or what is down. Even if vertical control points are assigned, there is still no notion of up and down, so the panorama can flip upside down. The solution for that is to open the Preview window, click on the Num. Trans. button in the toolbar, enter 180 in the roll field and apply. This will flip the panorama back to the right orientation.<br />
<br />
=== Why do multi-lens projects end up distorted/broken? ===<br />
<br />
You have probably optimized 'Everything'. This will cause the optimizer to try to optimize lens parameters for each of the different lenses, and there may not be a big enough spread of control points for the optimization to work well.<br />
When stitching photos from different lenses, or when you don't have a good spread of control points, optimize 'Position, view & Barrel (y,p,r,v,b).<br />
<br />
=== Why does my output covers only 180°? ===<br />
<br />
Did you observe that the output is cropped at the +-90° borders? (e.g. saw teeth like borders in the fast preview window)<br />
<br />
Then you have probably used the translation parameters X/Y/Z. This behaviour is a fundamental limitation of the used approach of the translation parameters. It is (internal) working in the rectilinear space, which is limited to maximal FOV of 180°, and therefore also the output is limited to FOV<180° (for more information see [[Stitching a photo-mosaic]]).<br />
<br />
The solution/workaround is to set all X/Y/Z values to zero or to limit the horizontal field of view (HFOV) to a value smaller than 180°.<br />
<br />
== GPU-stitching (nona) ==<br />
<br />
Starting with Hugin-2009.2 nona has a new, experimental feature: it can use the video card (GPU) to accelerate the stitching. How much acceleration you will get, if any, depends on the combination of video card and driver.<br />
<br />
=== I get a nona: GL error. Does this mean that I found a bug? ===<br />
<br />
Not necessarily. This functionality is highly experimental. It may be that you have an outdated driver, or that the functionality is not supported on your video card. Note down the version of the driver you are using and the specs of your video card (GPU and RAM). Then update to the latest driver from [http://www.nvidia.com/page/drivers.html nVidia] or [http://support.amd.com/us/gpudownload/Pages/index.aspx AMD] (ATI has been bought by AMD). Currently only these two families of GPUs support the functionality.<br />
<br />
=== How can I know if nona-GPU works on my system? ===<br />
<br />
At the moment we have too little information to predict this. We know that only nVidia and AMD(ATI) powered video cards work, and not all of them. The more recent the video card, the higher the likelihood that it works. Improve your chances by updating to the latest driver for your GPU. Look at experience reports from other users and report your experience [[Nona GPU stitching reports|here]].<br />
<br />
=== What speed improvement can I expect? ===<br />
<br />
It depends on the video card. Bandwidth is mostly the bottleneck, specifically getting the transformed data from the GPU back to the main system memory.<br />
<br />
=== Bug Reporting ===<br />
<br />
When reporting success or failure using the GPU for stitching, always report also the driver version, video card GPU and RAM. Tell us what you were doing, the size and number of input images (note that if you stitch from within Hugin or PTBatcher, it is only one input image at a time).<br />
<br />
== Postprocessing ==<br />
<br />
=== Why is the ICC profile of my input images not preserved? ===<br />
<br />
Since hugin 0.5 and enblend 2.4 [[colour profile|ICC profiles]] in the input files are transfered to the output panorama. Please update to a current version.<br />
<br />
=== How can I postprocess the image using multiple layers in The Gimp? ===<br />
<br />
* Use the [[nona]] stitcher on the command-line, to output to a multilayer [[TIFF]] format:<br />
<br />
nona -m TIFF_multilayer -o multi_layer.tif project.pto<br />
<br />
This will will produce a multi_layer.tif file, that contains all remapped images, cropped to their bounding box.<br />
<br />
* Alternatively select the '''Remapped Images''' option in the [[Hugin Stitcher tab]], this will create each ''layer'' as a separate file. Then use the '''tiffcp''' command-line tool (part of libtiff) to join them together into a multi-page TIFF:<br />
<br />
tiffcp project0000.tif project0001.tif project0002.tif multi_layer.tif<br />
<br />
* You can also use [[tif2xcf]], to combine the '''Remapped Images''' TIFF output into a multilayer XCF.<br />
Unfortunately this requires a lot of memory because it stores each remapped image in a layer with the size of the final panorama.<br />
<br />
== Installation ==<br />
<br />
=== Where can I download hugin installers ===<br />
<br />
Official releases are available from [http://hugin.sourceforge.net/download/ hugin.sf.net].<br />
<br />
=== How can I compile Hugin.app on my OSX machine? ===<br />
<br />
See [[Hugin Compiling OSX]], [[Autopano-sift-C Compiling OSX]] and [[Enblend Compiling OSX]].<br />
<br />
=== How do I compile hugin on my linux machine? ===<br />
<br />
See [[Hugin Compiling Fedora]], [[Hugin Compiling Gentoo]], [[Hugin Compiling OpenSuse]] and [[Hugin Compiling Ubuntu]]<br />
<br />
=== make[2]: *** No rule to make target `/usr/lib/libGL.so', needed by `src/hugin_base/libhuginbase.so.0.0'. Stop. ===<br />
<br />
So you're trying to build from source. Most likely you have proprietary nVidia or ATI drivers. They are a moving target and so is X. On debian based systems including Ubuntu, diagnose with `dpkg -S /usr/lib/libGL.so` and check that the linked library exist (i.e. it is not listed in red when doing `ll /usr/lib/mesa/libGL.so`). If it is listed in red, check where the library is (`ll /usr/lib/libGL*` is a good start on Ubuntu) and link it properly.<br />
<br />
=== How do I compile hugin on my Windows machine? ===<br />
<br />
See [[Hugin Compiling Windows]]<br />
<br />
=== Enblend-Enfuse OpenMP SSE GPU: which one is the right one for me? ===<br />
<br />
Enblend and Enfuse can be optimized at build time for different hardware configurations. This yields four categories of Enblend-Enfuse builds, with a few variations. If you build Enblend-Enfuse from source, check the build options in the README file. If you download a binary, you can find out how it has been built with the following command:<br />
<br />
enblend -v -V<br />
<br />
look for the following in the output text:<br />
<br />
# '''Extra feature: OpenMP: yes''' this version has OpenMP.<br />
# '''Extra feature: image cache: yes''' this version has image cache<br />
# '''Extra feature: GPU acceleration: yes''' this version has GPU support<br />
# SSE-support is not mentioned, you'll find out if you have an unsupported CPU and the binary will refuse to run.<br />
<br />
These are approximate guidelines to help you choose what may work for you:<br />
<br />
* if you have a recent, multi-core / multi-thread CPU, you probably want the OpenMP-enabled version. Note however that speed improvement does not scale well, so don't expect a 6 cores CPU to be 3x faster than a 2 cores one.<br />
* if you have a recent, fast video card, you probably want the GPU-enabled version. This is not mutually exclusive with OpenMP and a good builder will add both features to his binaries. If speed is important to you, you want to test which of the two is faster on your system. If system responsiveness is important to you, the GPU-enabled version frees CPU resources for your other tasks. Note that even if your binary is GPU-enabled, the GPU will not be used unless you specify the option `--gpu`.<br />
* if you have an old CPU without SSE2 support, you want a NOSSE build. This is the least performing version.<br />
* Last but not least, if blending fails because of large images, try the image cache variation. The image cache allows for processing of large project when memory is scarce but images are large (and disk is large enough too). Image cache is incompatible with OpenMP, but a good bilder will make this version GPU-enabled too, so test it with `--gpu` if speed is important.<br />
<br />
=== Selecting right version of enblend-enfuse binary for Windows ===<br />
<br />
There are 3 variants of enblend-enfuse binaries officially released for Windows. Each one has a special feature set: <br />
<br />
1. enblend.exe/enfuse.exe<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_openmp.exe/enfuse_openmp.exe<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache. In this case, please switch to the standard version.<br />
For running the OpenMP variants you will need [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en "Microsoft Visual C++ 2008 Redistributable Package (x86)"].<br />
<br />
<br />
3. enblend_nosse.exe/enfuse_nosse.exe<br />
<br />
If you have an old CPU without [http://en.wikipedia.org/wiki/SSE2 SSE2] support, you want a NOSSE build. This is the least performing version.<br />
You will need to download a separate package to get this version from [http://sourceforge.net/projects/enblend/files/enblend-enfuse/enblend-enfuse-4.0/enblend-enfuse-4.0-win32-nosse.zip/download sourceforge.net]<br />
<br />
All three variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
<br />
=== Selecting right version of enblend-enfuse binary for Debian/Ubuntu ===<br />
<br />
At the time of writing the official Debian/Ubuntu package ships with one executable only, however in July 2010 a change has been committed to debian-unstable that delivers two binaries:<br />
<br />
1. enblend/enfuse<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_mp/enfuse_mp<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache.<br />
<br />
Both variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_FAQ&diff=13515Hugin FAQ2011-05-31T22:25:49Z<p>Bruno: fix links</p>
<hr />
<div>== Common error messages ==<br />
<br />
=== enblend: no input files specified ===<br />
<br />
There are no input images relevant to the output 'panorama' so hugin had nothing to do, probably because all the input images are outside the panorama 'frame' or disabled. Open the [[Hugin Preview window]] or [[Hugin Fast Preview window]] to adjust the view, enable some images inside the panorama frame and/or adjust the crop.<br />
<br />
Note also that hugin versions up to and including 2009.2.0 allow you to draw an inverted crop frame where the top is below the bottom, this is easy to see in the Preview window as the entire panorama is 'greyed'. A crop frame drawn like this will result in an empty panorama and the above error message.<br />
<br />
=== enblend: excessive overlap detected ===<br />
<br />
This is an error new to enblend-4.0. Photos that nearly entirely overlap won't blend very well, enblend now fails instead of attempting to blend them. There are various workarounds:<br />
<br />
* Follow the error message and remove the suggested image from the set, you probably don't need it to complete the panorama.<br />
* Switch back to enblend-3.2.<br />
* Hugin will merge stacked images before blending if you select 'Exposure fusion' in the [[Hugin Stitcher tab]]. This error will go away, but Hugin will take a very different approach to variable exposure between photos.<br />
* Mask out major parts of one image.<br />
<br />
=== enblend: error writing to image swap file ===<br />
<br />
[[enblend]] needs a lot of memory and uses its own swap routine to store picture data on the disk, this message indicates that you have run out of disk space. The data is stored in the system temp folder which is specified by TMP, TEMP or TMPDIR environment variables, note that this temp folder may be on a different physical disk to your photos and panorama output.<br />
<br />
=== execvp(make ...) failed with error 2 ===<br />
<br />
Hugin requires the 'make' utility to stitch, you need to install it and/or report the problem to whoever supplied Hugin to you.<br />
<br />
=== false --compression NONE ===<br />
<br />
This error is caused by a bug in the 0.7.0 release that is fixed in 0.8.0. The problem is that your preferences are messed-up, the workaround for 0.7.0 is to go to File -> Preferences -> Enblend and click Load Defaults -> Yes -> Ok<br />
<br />
=== Enblend error: Mask is entirely black, but white image was not identified as redundant ===<br />
<br />
This is a well known "error" for [[enblend]]. Try to use the additional enblend parameter "--fine-mask" to get rid of the error. The parameter will result in generation of masks in higher resolution that will fix the problem in most cases. Sometimes the "--fine-mask" parameter may result in memory errors (malloc: ...), which are the result of not enough memory available due to the (much) bigger masks that are used.<br />
<br />
An alternative workaround would be to set the enblend --no-optimize parameter, this will place the seam directly along the middle of the image overlaps regardless of image content. This option is also considerably faster and uses less memory.<br />
<br />
This error also occurs when one photo is completely covered by another, try removing redundant photos.<br />
<br />
Note also that for the same reasons this error often appears when rendering a scene with extreme distortion such as a stereographic 'little planet'. For this and other reasons, such as overall speed, it is always preferable to render a 'normal' 360° [[Equirectangular Projection]] panorama first, then load this as a single source image into a new project and render whatever views you need.<br />
<br />
Note (Jan 2010): This should be fixed in the latest [[enblend]] 4.0 release.<br />
<br />
=== enblend: illegal option -- compression ===<br />
<br />
hugin 0.7.0 and later versions require at least [[enblend]] version 3.2. This error indicates that you need to upgrade enblend.<br />
<br />
=== enblend: Error -1073741795 ===<br />
<br />
See [[#Enblend: The system cannot execute the specified command]], in particular if you are a Windows user try switching to the 'nosse' enblend-enfuse.<br />
<br />
=== Makefile: target pattern contains no % ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== gnumake: *** No rule to make target ===<br />
<br />
This is a message generated by [[w:Make_(software)]] (which [[Hugin]] uses to manage the stitching sequence). The error is caused by a ''':''' or '''#''' character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.<br />
<br />
=== nona: GL error: Framebuffer incomplete, incomplete attachment in: ===<br />
<br />
This is a message generated by nona when using the GPU for stitching (feature available starting with Hugin-2009.2.0). See section below about [[#GPU-stitching_.28nona.29|GPU-stitching]].<br />
<br />
=== make: enfuse: command not found ===<br />
<br />
This is a message generated by make when assembling your panorama. It most likely means that enfuse is not on your computer. Enfuse is part of the enblend package, but many Linux distributions, even recent ones, ship with an older version of enblend that does not contain enfuse. You need to install enblend-3.2 or later.<br />
<br />
=== Enblend: The system cannot execute the specified command ===<br />
<br />
This message could be generated by either<br />
* the lack of Microsoft Visual C++ 2008 Redistributable Package (x86) that is necessary to run an OpenMP enabled version of Enblend. Download [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here].<br />
* the lack of [http://en.wikipedia.org/wiki/SSE2 SSE2] support. Use a non-SSE build of Enblend. See also [[#Enblend-Enfuse_OpenMP_SSE_GPU:_which_one_is_the_right_one_for_me.3F | types of Enblend-Enfuse binaries]] or [[#Selecting_right_version_of_enblend-enfuse_binary_for_Windows | types of Enblend-Enfuse binaries for Windows ]]<br />
<br />
===Windows error message "application configuration is incorrect"===<br />
<br />
Double clicking the Hugin icon to run the program produces a message like this:<br />
<pre><br />
C:\Program Files\Hugin\bin\hugin.exe<br />
This application has failed to start because the application configuration is incorrect.<br />
Reinstalling the application may fix this problem.<br />
</pre><br />
Try installing the [http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Microsoft Visual C++ redistributable].<br />
<br />
=== Stitching fails on Windows (syntax error)===<br />
<br />
If the stitching step fails on windows with a error message like<br />
<br />
<pre><br />
/usr/bin/sh: -c: line 1: syntax error near unexpected token `(6'<br />
/usr/bin/sh: -c: line 1: `echo Operating System: Windows 7 (6.1 )'<br />
make: *** [info] Error 258<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
Syntax error: "(" unexpected<br />
make: *** [info] Error 2<br />
</pre><br />
<br />
then you have probably an other shell (e.g. sh.exe or bash.exe) somewhere in your path. In this case remove the path to this executable from the PATH variable.<br />
<br />
=== Hugin Quits (Seg Faults) at Launch (Linux) ===<br />
<br />
There may be many reasons why a program dies before it has even started.<br />
<br />
One possibility is bad configuration or installation of the video drivers. See this [https://bugs.launchpad.net/hugin/+bug/679427 ticket]. To diagnose, try running glxgears. On Ubuntu (the package is probably available on most Linux distributions):<br />
<br />
<pre><br />
sudo apt-get mesa-utils<br />
glxgears<br />
</pre><br />
<br />
If glxgears does not run on your system, Hugin will not run either. See your Linux distribution's instruction on how to fix the video drivers.<br />
<br />
== Known Limitations ==<br />
<br />
=== Linux: Compiz ===<br />
<br />
Linux: Compiz interferes with the [[hugin Fast Preview window]]. This is not a hugin specific issue. Research shows all direct rendered stuff will have various problems under Compiz: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/96991<br />
<br />
This problem is fixed with DRI2, e.g with fedora 11 and intel graphics hardware you can have a 'wobbly' Fast Preview window if you really want.<br />
<br />
It's not an issue with NVidia's proprietry driver.<br />
<br />
If you're affected, the workaround is to not use Compiz.<br />
<br />
=== Windows: International Characters in Path ===<br />
<br />
Hugin is fully internationalised and can cope with special characters in file paths. However, hugin apparently fails on some Windows systems with Polish, Japanese, Russian or Czech codepages, the workaround is to use shell-safe ascii characters in file and folder names: '''A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 - _ .''' This includes the path for the temporary folder which is named after your username on Windows systems.<br />
<br />
=== OSX: error when clicking on the help button ===<br />
<br />
In a language other than English, French or Italian you get an error message when clicking on the help button. This will be fixed in Hugin-2009.4.0. In the meantime, the work around is to change language to one of the above three; or to ask for help on the mailing list. <br />
<br />
=== Non-Unique Filenames ===<br />
<br />
Some components of Hugin have been reported not to deal well with image files<br />
that have the same name in different folders. The workaround is to rename <br />
your images files so that all image files in a project are unique.<br />
<br />
=== Temporary Files ===<br />
<br />
Hugin has a preference setting for the temporary files folder. Currently it<br />
is not implemented properly and files will be written in the same folder as<br />
the project file.<br />
<br />
A partial workaround on Linux is to start Hugin from a terminal with<br />
<pre><br />
TMPDIR=/media/disk-2/tmp hugin &<br />
</pre><br />
<br />
These temporary files have to be deleted manually after the stitch.<br />
<br />
=== Special Characters in Paths ===<br />
<br />
{| style="margin: 1em auto 1em 1em;background:#FFFF99;color:#FF0000;text-align:left;border: solid #FF3300;"<br />
|-valign="top"<br />
! =<br />
! ;<br />
! :<br />
! $<br />
! "<br />
! %<br />
! #<br />
! |<br />
! '<br />
! (<br />
! )<br />
! `<br />
! &<br />
! *<br />
! +<br />
! ^<br />
! ~<br />
! <<br />
! ?<br />
! ><br />
! and the space character.<br />
|}<br />
<br />
Hugin currently does not do plausibility checks on the paths and file names that are given to it. It relies on the operating system's conventions and limitations. However Hugin uses make to run the stitching process, and make has more restrictive limitation than the operating system.<br />
<br />
Please don't use the above characters in your files and folders when you want to make sure they work with Hugin. If you absolutely need files named this way, rename them after processing. Do not file bug reports based on filenames with the above characters. The [https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2883450&group_id=77506 issue] is known, analyzed, and may be fixed in the future.<br />
<br />
=== Hugin fails stitching some stereographics and other polar projections ===<br />
<br />
This is a known limitation caused by photos being distorted into extreme 'C' and 'O' shapes. The workaround: stitch all of your pictures into a single equirectangular, and then load the equirectangular into Hugin to generate the stereographic or other projections you wanted to do in the first place.<br />
<br />
<br />
=== OSX / iPhoto ===<br />
<br />
Dragging the photos from iPhoto to Hugin works perfectly as long as there is no forward slash in the Name of the events in iPhoto (which translates to folders inside the iPhoto Database).<br />
<br />
=== Fast Preview ===<br />
<br />
Why are there two preview windows, and which one should I use?<br />
<br />
For most purposes, the newer Fast Preview window is faster. However it is still under development and sometimes shows artefacts. The old preview still does a logarithmic tone mapping of stacked<br />
images and is the only way to preview hdr or fused output.<br />
<br />
=== Makefile based stitching process ===<br />
<br />
Can I restart a stitching process that was interrupted manually or by an error without starting everything from scratch?<br />
<br />
Unfortunately the Hugin Makefile system only supports restarting if you stitch on the command-line. The GUI tools always create new temporary .pto project and Makefile files every time they stitch, so this forces make to recreate everything for every stitch.<br />
<br />
=== Python Scripting ===<br />
<br />
Python scripting is a recent feature added to Hugin 2011.2. It must be explicitly activated at build time with the CMake boolean parameter -DBUILD_HSI:BOOL=ON.<br />
<br />
It is currently untested / unavailable on OSX.<br />
<br />
Some of the scripts delivered with Hugin may not work on your system because of missing run-time dependencies. The scripting functionality was developed in Ubuntu Linux and may or may not work in other Linux flavors and non-Linux system. As more experience and wisdom is collected, we will try to document it. In the meantime, if running a script does not work, you have two options: find out why and contribute a patch; or use Hugin on Ubuntu. You can achieve this second one with a virtual machine from the comfort of your favorite operating system.<br />
<br />
== Control Point creation ==<br />
<br />
=== How do I add control points ===<br />
The [[control points]] editor is quite powerful, but its usage is probably not obvious on the first try. Here are some ways the developers use the Control Point panel:<br />
<br />
1. Selecting control points in 100% zoom.<br />
<br />
This method needs some scrolling, if big images are used. You might want to try the fit to window zoom setting in that case. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: 100%<br />
[X] auto fine tune<br />
[X] auto add<br />
[X] auto estimate<br />
<br />
Click on a prominent feature in the left image. If the image pair already contains control points, [[hugin]] will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The second point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by dragging them to a better position. Press the "f" key to fine tune the point in a small area.<br />
<br />
<br />
2. Selecting control points in fit to window mode.<br />
<br />
I uses this mode if I need to set points on big images. Switch to the Control Points tab, and use the following settings:<br />
<br />
Zoom: fit to window<br />
[X] auto fine tune<br />
[ ] auto add<br />
[X] auto estimate<br />
<br />
Click on left image. The image will be shown in 100% view. Within the detailed view, click on a prominent feature. If the image pair already contains control points, hugin will try to select the point in the other image. If its the first point in this pair, click near the same feature on the right image. The point will be placed and fine tuned automatically. If you are not happy with the placement, both points can be moved by clicking at the desired position. Move the point close to the desired feature and press the "f" key to fine tune the point. When the points are on the same feature, press the right mouse button, or press the "a" key to add the control point pair. It will then be shown in the list below the image.<br />
<br />
=== How do I scroll both images at the same time? ===<br />
<br />
Try pressing the shift key while moving the mouse. The control key or the middle mouse button can be used to scroll only the image under the mouse cursor.<br />
<br />
=== How do I stop Hugin pausing for a moment after every click? ===<br />
<br />
The ''preview window'' updates continuously whenever anything changes, so disable the preview auto-update, close it or make it smaller if you don't need it.<br />
<br />
Otherwise, picking [[control points]] with ''auto fine tune'' selected can involve a lot<br />
of processing. You can reduce this by ''selecting File -> Preferences -> Finetune'' and<br />
lowering the values for ''Patch width'', ''Search area width'' and ''Local search area width''.<br />
This means you can't be so sloppy when clicking to create control points, but the results will<br />
be the same.<br />
<br />
=== Windows: when user is not admin, not all cp-creators are available to choose from ===<br />
<br />
Preferences are stored in the registry on Windows. Every users has their own. To have all the cp-creator pre-sets like the admin users, hit the "Load defaults" button on the Control Points tab in the Preferences dialog.<br />
<br />
=== cpfind: not enough control points generated ===<br />
<br />
Cpfind is a recent addition to the Hugin suite and its parameters still require some fine tuning. Unlike older CP generators used with Hugin, it depends on information passed in the PTO file. Make sure that your input project file contains reasonable information about the used lens. If you are using a fisheye or wide angle lens, try increasing the parameters --sieve1width --sieve1height --sieve1size. A combinations that may work is "--sieve1width 50 --sieve1height 50 --sieve1size 300". Sometimes also the option "--fullscale" might help. Read the [[Cpfind]] documentation.<br />
<br />
== Common problems when creating a panorama ==<br />
<br />
=== The Control Points tab shows my photos rotated ===<br />
<br />
The rotation of photos in the [[Hugin Control Points tab]] isn't necessarily<br />
related to the orientation of the files themselves.<br />
<br />
Hugin shows photos at the angle they best fit into the panorama, so if the<br />
panorama fit is bad, then you will see strange angles in the Control Points<br />
tab. Probably the problem is caused by bad alignment, you can<br />
identify 'bad' [[Control points]] in the [[Hugin Control Points table]], delete them and re-optimise.<br />
<br />
=== How can I reuse a project as a template? ===<br />
<br />
If you copy a .pto project to a different folder and open it with hugin, you will be prompted for the 'missing' images. You should delete any control points from this template project since they won't be relevant to the new photos.<br />
<br />
Alternatively you can load your images as normal, then ''Apply template''<br />
from the ''File'' menu, this will import image settings and parameters<br />
from a previous project.<br />
<br />
=== How do I straighten a curved horizon? ===<br />
If the panorama looks nice but the horizon is curved, there are various ways to improve the image and straighten the horizon.<br />
<br />
First, try clicking the '''Straighten''' button in the [[Hugin Fast Preview window]].<br />
<br />
If this doesn't work then you can use the Move/Drag tab of the [[Hugin Fast Preview window]] to visually straighten the panorama, drag the photos with the mouse, use the right mouse button to rotate. One useful tip is to drag the panorama so a vertical feature is in the middle, rotate it so the feature lines up with the 'cross hair', then drag the panorama up or down until all the vertical features in the scene are vertical on the screen (holding down the shift key while dragging limits the motion to just up/down or left/right).<br />
<br />
If it is still curved, you have to add vertical guide control points in the "Control Points" tab. Usually two [[vertical control points]] are enough to straighten the horizon nicely. Often edges of buildings, poles or other man made structures provide good vertical lines. To add a vertical control point, switch to the control point editor and select the same image on both sides. Place a control point on the left image on the upper area of the vertical feature. In the right image, select a control point on the lower area of the features, and press the Add button. Once the new point has been added, its type should automatically switch to "vertical line". You might want to switch off the auto-add and auto-estimate options while doing this to avoid naggy dialogs while adding these guide points. Two points that are roughly 90 degrees apart provide the best effect.<br />
<br />
See also the related perspective correction tutorials: [http://hugin.sourceforge.net/tutorials/architectural/en.shtml hugin tutorial on perspective correction], [[Perspective correction]], [[Leveling a Finished Panorama]]. While these are concerned with correction of the perspective in one image, the same technique can be used for<br />
leveling a panorama.<br />
<br />
=== Half the panorama is black, my pictures fill only the right half of the output ===<br />
<br />
Hugin uses the first photo as the ''anchor'' image and puts it in the middle by default. This means that if you shot a sequence from left to right, the images will fill the right hand side of the panorama. There are three ways to fix this:<br />
<br />
* Open the '''preview''' window and click the '''center''' button.<br />
* or select the middle photo, hit '''anchor this image for position''' and '''reset''' in the '''images''' tab, then reoptimise.<br />
* In the 'Fast Panorama Preview' window select 'Drag'. Left mouse drags the image, right mouse rotates the image.<br />
<br />
=== I get visible bands in the sky and other flat areas, what can I do? ===<br />
<br />
If the banding looks like [[w:Posterization|posterization]] then this is likely due to a error with estimation of the [[camera response curve]]. To get an accurate response curve, Hugin needs significant [[vignetting]] and/or [[bracketing|bracketed exposures]]. The workaround is to '''Reset...''' the '''Camera Response''' in the [[Hugin Camera and Lens tab]] and stitch again - [[Hugin]] usually produces acceptable results for a simple panorama when the camera response parameters are all zero.<br />
<br />
If there is a wave of light and dark patches in the sky this could be due to [[vignetting]] in the source photos, you can deal with this by optimising '''Vignetting (Vb, Vc, Vd)''' in the [[Hugin Exposure tab]]. Another workaround is to increase the number of [[enblend]] blending levels, try setting '-l 29' as the enblend '''Command line options''' in the [[Hugin Stitcher tab]].<br />
<br />
=== My photos never quite line up, what can I do? ===<br />
<br />
It is normal to get little stitching [[parallax]] errors if<br />
the camera moves between photos. The solution is to rotate the camera around<br />
the [[no-parallax point]] using a [[Heads|panoramic head]] or [[philopod]].<br />
<br />
Otherwise you can sometimes improve things by optimising the ''d & e'' parameters<br />
separately - When you optimise '''everything''', unselect '''Inherit''' in<br />
the '''camera and Lens''' panel for 'd & e'. Also you can open the control point window sort it by distance and check the ones large distance.<br />
<br />
If these parallax errors are still large, you need to decide which<br />
parts of the scene that you want to line-up and which parts don't<br />
matter. Select [[control points]] only on objects that you do want to<br />
line-up and which are all about the same distance from the camera.<br />
<br />
The remaining broken lines can then be retouched in a photo editor like the [[gimp]].<br />
The ''shear'' tool is ideal for bending the lines and<br />
[[Mending parallax errors with the shear tool|getting them to line up]].<br />
<br />
=== I have extracted and edited cubefaces and want to merge them together again. How do I do that ? ===<br />
<br />
Manually enter the values for [[yaw]] and [[pitch]] for each of the photos. When you stitch set the '''enblend options''' in the [[Hugin Stitcher tab]] to -l1 --fine-mask --no-optimize<br />
<br />
=== Can I stitch my HDR images ? ===<br />
<br />
Yes. If you already have merged your HDR stacks, follow the '''Normal''' Output on the '''Stitcher''' tab ('''HDR merging''' is for stacks that will be merged by Hugin). In the '''Processing''' step the output will be an HDR in TIFF format.<br />
<br />
=== Why is my panorama upside down ? ===<br />
<br />
Hugin stitches the panorama on a sphere and can't determine what is up or what is down. Even if vertical control points are assigned, there is still no notion of up and down, so the panorama can flip upside down. The solution for that is to open the Preview window, click on the Num. Trans. button in the toolbar, enter 180 in the roll field and apply. This will flip the panorama back to the right orientation.<br />
<br />
=== Why do multi-lens projects end up distorted/broken? ===<br />
<br />
You have probably optimized 'Everything'. This will cause the optimizer to try to optimize lens parameters for each of the different lenses, and there may not be a big enough spread of control points for the optimization to work well.<br />
When stitching photos from different lenses, or when you don't have a good spread of control points, optimize 'Position, view & Barrel (y,p,r,v,b).<br />
<br />
=== Why does my output covers only 180°? ===<br />
<br />
Did you observe that the output is cropped at the +-90° borders? (e.g. saw teeth like borders in the fast preview window)<br />
<br />
Then you have probably used the translation parameters X/Y/Z. This behaviour is a fundamental limitation of the used approach of the translation parameters. It is (internal) working in the rectilinear space, which is limited to maximal FOV of 180°, and therefore also the output is limited to FOV<180° (for more information see [[Stiching a photo-mosaic]]).<br />
<br />
The solution/workaround is to set all X/Y/Z values to zero or to limit the horizontal field of view (HFOV) to a value smaller than 180°.<br />
<br />
== GPU-stitching (nona) ==<br />
<br />
Starting with Hugin-2009.2 nona has a new, experimental feature: it can use the video card (GPU) to accelerate the stitching. How much acceleration you will get, if any, depends on the combination of video card and driver.<br />
<br />
=== I get a nona: GL error. Does this mean that I found a bug? ===<br />
<br />
Not necessarily. This functionality is highly experimental. It may be that you have an outdated driver, or that the functionality is not supported on your video card. Note down the version of the driver you are using and the specs of your video card (GPU and RAM). Then update to the latest driver from [http://www.nvidia.com/page/drivers.html nVidia] or [http://support.amd.com/us/gpudownload/Pages/index.aspx AMD] (ATI has been bought by AMD). Currently only these two families of GPUs support the functionality.<br />
<br />
=== How can I know if nona-GPU works on my system? ===<br />
<br />
At the moment we have too little information to predict this. We know that only nVidia and AMD(ATI) powered video cards work, and not all of them. The more recent the video card, the higher the likelihood that it works. Improve your chances by updating to the latest driver for your GPU. Look at experience reports from other users and report your experience [[Nona GPU stitching reports|here]].<br />
<br />
=== What speed improvement can I expect? ===<br />
<br />
It depends on the video card. Bandwidth is mostly the bottleneck, specifically getting the transformed data from the GPU back to the main system memory.<br />
<br />
=== Bug Reporting ===<br />
<br />
When reporting success or failure using the GPU for stitching, always report also the driver version, video card GPU and RAM. Tell us what you were doing, the size and number of input images (note that if you stitch from within Hugin or PTBatcher, it is only one input image at a time).<br />
<br />
== Postprocessing ==<br />
<br />
=== Why is the ICC profile of my input images not preserved? ===<br />
<br />
Since hugin 0.5 and enblend 2.4 [[colour profile|ICC profiles]] in the input files are transfered to the output panorama. Please update to a current version.<br />
<br />
=== How can I postprocess the image using multiple layers in The Gimp? ===<br />
<br />
* Use the [[nona]] stitcher on the command-line, to output to a multilayer [[TIFF]] format:<br />
<br />
nona -m TIFF_multilayer -o multi_layer.tif project.pto<br />
<br />
This will will produce a multi_layer.tif file, that contains all remapped images, cropped to their bounding box.<br />
<br />
* Alternatively select the '''Remapped Images''' option in the [[Hugin Stitcher tab]], this will create each ''layer'' as a separate file. Then use the '''tiffcp''' command-line tool (part of libtiff) to join them together into a multi-page TIFF:<br />
<br />
tiffcp project0000.tif project0001.tif project0002.tif multi_layer.tif<br />
<br />
* You can also use [[tif2xcf]], to combine the '''Remapped Images''' TIFF output into a multilayer XCF.<br />
Unfortunately this requires a lot of memory because it stores each remapped image in a layer with the size of the final panorama.<br />
<br />
== Installation ==<br />
<br />
=== Where can I download hugin installers ===<br />
<br />
Official releases are available from [http://hugin.sourceforge.net/download/ hugin.sf.net].<br />
<br />
=== How can I compile Hugin.app on my OSX machine? ===<br />
<br />
See [[Hugin Compiling OSX]], [[Autopano-sift-C Compiling OSX]] and [[Enblend Compiling OSX]].<br />
<br />
=== How do I compile hugin on my linux machine? ===<br />
<br />
See [[Hugin Compiling Fedora]], [[Hugin Compiling Gentoo]], [[Hugin Compiling OpenSuse]] and [[Hugin Compiling Ubuntu]]<br />
<br />
=== make[2]: *** No rule to make target `/usr/lib/libGL.so', needed by `src/hugin_base/libhuginbase.so.0.0'. Stop. ===<br />
<br />
So you're trying to build from source. Most likely you have proprietary nVidia or ATI drivers. They are a moving target and so is X. On debian based systems including Ubuntu, diagnose with `dpkg -S /usr/lib/libGL.so` and check that the linked library exist (i.e. it is not listed in red when doing `ll /usr/lib/mesa/libGL.so`). If it is listed in red, check where the library is (`ll /usr/lib/libGL*` is a good start on Ubuntu) and link it properly.<br />
<br />
=== How do I compile hugin on my Windows machine? ===<br />
<br />
See [[Hugin Compiling Windows]]<br />
<br />
=== Enblend-Enfuse OpenMP SSE GPU: which one is the right one for me? ===<br />
<br />
Enblend and Enfuse can be optimized at build time for different hardware configurations. This yields four categories of Enblend-Enfuse builds, with a few variations. If you build Enblend-Enfuse from source, check the build options in the README file. If you download a binary, you can find out how it has been built with the following command:<br />
<br />
enblend -v -V<br />
<br />
look for the following in the output text:<br />
<br />
# '''Extra feature: OpenMP: yes''' this version has OpenMP.<br />
# '''Extra feature: image cache: yes''' this version has image cache<br />
# '''Extra feature: GPU acceleration: yes''' this version has GPU support<br />
# SSE-support is not mentioned, you'll find out if you have an unsupported CPU and the binary will refuse to run.<br />
<br />
These are approximate guidelines to help you choose what may work for you:<br />
<br />
* if you have a recent, multi-core / multi-thread CPU, you probably want the OpenMP-enabled version. Note however that speed improvement does not scale well, so don't expect a 6 cores CPU to be 3x faster than a 2 cores one.<br />
* if you have a recent, fast video card, you probably want the GPU-enabled version. This is not mutually exclusive with OpenMP and a good builder will add both features to his binaries. If speed is important to you, you want to test which of the two is faster on your system. If system responsiveness is important to you, the GPU-enabled version frees CPU resources for your other tasks. Note that even if your binary is GPU-enabled, the GPU will not be used unless you specify the option `--gpu`.<br />
* if you have an old CPU without SSE2 support, you want a NOSSE build. This is the least performing version.<br />
* Last but not least, if blending fails because of large images, try the image cache variation. The image cache allows for processing of large project when memory is scarce but images are large (and disk is large enough too). Image cache is incompatible with OpenMP, but a good bilder will make this version GPU-enabled too, so test it with `--gpu` if speed is important.<br />
<br />
=== Selecting right version of enblend-enfuse binary for Windows ===<br />
<br />
There are 3 variants of enblend-enfuse binaries officially released for Windows. Each one has a special feature set: <br />
<br />
1. enblend.exe/enfuse.exe<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_openmp.exe/enfuse_openmp.exe<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache. In this case, please switch to the standard version.<br />
For running the OpenMP variants you will need [http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en "Microsoft Visual C++ 2008 Redistributable Package (x86)"].<br />
<br />
<br />
3. enblend_nosse.exe/enfuse_nosse.exe<br />
<br />
If you have an old CPU without [http://en.wikipedia.org/wiki/SSE2 SSE2] support, you want a NOSSE build. This is the least performing version.<br />
You will need to download a separate package to get this version from [http://sourceforge.net/projects/enblend/files/enblend-enfuse/enblend-enfuse-4.0/enblend-enfuse-4.0-win32-nosse.zip/download sourceforge.net]<br />
<br />
All three variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
<br />
=== Selecting right version of enblend-enfuse binary for Debian/Ubuntu ===<br />
<br />
At the time of writing the official Debian/Ubuntu package ships with one executable only, however in July 2010 a change has been committed to debian-unstable that delivers two binaries:<br />
<br />
1. enblend/enfuse<br />
<br />
These executables are the standard release. They are using one processor core and the image cache for processing very big images. <br />
<br />
2. enblend_mp/enfuse_mp<br />
<br />
These executables can utilize several cores of modern multi-core processors and are therefore significantly faster on modern processors. But they may fail on very big images because they are working without the image cache.<br />
<br />
Both variants can utilize a modern graphic card to accelerate the optimizing of the seam line between two images. To use this feature supply the parameter --gpu to enblend.<br />
<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13357Historical:GSOC 2011 Ideas2011-03-31T23:26:19Z<p>Bruno: </p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad] which should be read in conjunction with these unimplemented proposals for projects from previous years:<br />
<br />
* [https://blueprints.launchpad.net/hugin SoC 2011 blueprints at launchpad]<br />
* [[SoC 2010 ideas]]<br />
** [[SoC_2010_ideas#Zooming_for_fast_preview|Zooming for the fast preview]]<br />
** [[SoC_2010_ideas#Colour|Colour management]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
** [[SoC_2009_idea#enblend.2Fenfuse_gimp_plugin|enblend/enfuse GIMP plugin (GEGL?)]]<br />
** [[SoC_2009_idea#hugin_RAW_support|Hugin RAW support]]<br />
** [[SoC_2009_idea#zenith.2Fnadir_blending_for_enblend-enfuse|Zenith/Nadir blending for enblend/enfuse]]<br />
** [[SoC_2009_idea#seam_optimization_in_enblend-enfuse|Seam optimisation in enblend/enfuse]]<br />
* [[SoC 2008 ideas]]<br />
** [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI|Interactive OpenGL/python GUI]]<br />
** [[SoC_2008_ideas#Lens_Database|Integration of lensfun lens database]]<br />
** [[SoC_2008_ideas#tCA_Correction|tCA chromatic aberration correction]]<br />
** [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching|PSD/PSB output for Hugin/enblend/vigra]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]<br />
** [[SoC2007_projects#Processing_of_very_large_images|processing of very large images (GEGL/VIPS)]]<br />
** [[SoC2007_projects#Architectural_Overhaul_of_Panotools|Architectural overhaul of panotools]]<br />
<br />
The main page for Hugin/panotools [[GSOC 2011]] has more info.</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13356Historical:GSOC 2011 Ideas2011-03-31T23:24:22Z<p>Bruno: link to GSOC 2011</p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad] which should be read in conjunction with these unimplemented proposals for projects from previous years:<br />
<br />
* [[SoC 2010 ideas]]<br />
** [[SoC_2010_ideas#Zooming_for_fast_preview|Zooming for the fast preview]]<br />
** [[SoC_2010_ideas#Colour|Colour management]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
** [[SoC_2009_idea#enblend.2Fenfuse_gimp_plugin|enblend/enfuse GIMP plugin (GEGL?)]]<br />
** [[SoC_2009_idea#hugin_RAW_support|Hugin RAW support]]<br />
** [[SoC_2009_idea#zenith.2Fnadir_blending_for_enblend-enfuse|Zenith/Nadir blending for enblend/enfuse]]<br />
** [[SoC_2009_idea#seam_optimization_in_enblend-enfuse|Seam optimisation in enblend/enfuse]]<br />
* [[SoC 2008 ideas]]<br />
** [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI|Interactive OpenGL/python GUI]]<br />
** [[SoC_2008_ideas#Lens_Database|Integration of lensfun lens database]]<br />
** [[SoC_2008_ideas#tCA_Correction|tCA chromatic aberration correction]]<br />
** [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching|PSD/PSB output for Hugin/enblend/vigra]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]<br />
** [[SoC2007_projects#Processing_of_very_large_images|processing of very large images (GEGL/VIPS)]]<br />
** [[SoC2007_projects#Architectural_Overhaul_of_Panotools|Architectural overhaul of panotools]]<br />
<br />
The main page for Hugin/panotools [[GSOC 2011]] has more info.</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13353Historical:GSOC 2011 Ideas2011-03-31T00:11:33Z<p>Bruno: </p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad] which should be read in conjunction with these unimplemented proposals for projects from previous years:<br />
<br />
* [[SoC 2010 ideas]]<br />
** [[SoC_2010_ideas#Zooming_for_fast_preview|Zooming for the fast preview]]<br />
** [[SoC_2010_ideas#Colour|Colour management]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
** [[SoC_2009_idea#enblend.2Fenfuse_gimp_plugin|enblend/enfuse GIMP plugin (GEGL?)]]<br />
** [[SoC_2009_idea#hugin_RAW_support|Hugin RAW support]]<br />
** [[SoC_2009_idea#zenith.2Fnadir_blending_for_enblend-enfuse|Zenith/Nadir blending for enblend/enfuse]]<br />
** [[SoC_2009_idea#seam_optimization_in_enblend-enfuse|Seam optimisation in enblend/enfuse]]<br />
* [[SoC 2008 ideas]]<br />
** [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI|Interactive OpenGL/python GUI]]<br />
** [[SoC_2008_ideas#Lens_Database|Integration of lensfun lens database]]<br />
** [[SoC_2008_ideas#tCA_Correction|tCA chromatic aberration correction]]<br />
** [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching|PSD/PSB output for Hugin/enblend/vigra]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]<br />
** [[SoC2007_projects#Processing_of_very_large_images|processing of very large images (GEGL/VIPS)]]<br />
** [[SoC2007_projects#Architectural_Overhaul_of_Panotools|Architectural overhaul of panotools]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13352Historical:GSOC 2011 Ideas2011-03-31T00:10:38Z<p>Bruno: update</p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad]<br />
<br />
These blueprints should be read in conjunction with these unimplemented projects from previous years:<br />
<br />
* [[SoC 2010 ideas]]<br />
** [[SoC_2010_ideas#Zooming_for_fast_preview|Zooming for the fast preview]]<br />
** [[SoC_2010_ideas#Colour|Colour management]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
** [[SoC_2009_idea#enblend.2Fenfuse_gimp_plugin|enblend/enfuse GIMP plugin (GEGL?)]]<br />
** [[SoC_2009_idea#hugin_RAW_support|Hugin RAW support]]<br />
** [[SoC_2009_idea#zenith.2Fnadir_blending_for_enblend-enfuse|Zenith/Nadir blending for enblend/enfuse]]<br />
** [[SoC_2009_idea#seam_optimization_in_enblend-enfuse|Seam optimisation in enblend/enfuse]]<br />
* [[SoC 2008 ideas]]<br />
** [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI|Interactive OpenGL/python GUI]]<br />
** [[SoC_2008_ideas#Lens_Database|Integration of lensfun lens database]]<br />
** [[SoC_2008_ideas#tCA_Correction|tCA chromatic aberration correction]]<br />
** [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching|PSD/PSB output for Hugin/enblend/vigra]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]<br />
** [[SoC2007_projects#Processing_of_very_large_images|processing of very large images (GEGL/VIPS)]]<br />
** [[SoC2007_projects#Architectural_Overhaul_of_Panotools|Architectural overhaul of panotools]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011&diff=13351Historical:GSOC 20112011-03-31T00:02:46Z<p>Bruno: /* Ideas */</p>
<hr />
<div>== Google Summer of Code 2011 ==<br />
The ''[http://code.google.com/soc/ Google Summer of Code]'' (GSoC) is a global program that offers student developers stipends to write code for various open source software projects.<br />
<br />
The hugin-Team participated in quite some Google Summer of Code projects [[Summer of Code overview|in the recent years]]. This page aims to bundle the effort for the Summer of Code 2011.<br />
<br />
The official [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs FAQ] and [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline timeline] give a bit of an overview as a starter.<br />
<br />
== Mentors ==<br />
'''Jim Watters'''<br />
<br />
Jim is willing to be a mentor for projects that are more on the panotools side.<br />
<br />
He is a Software Engineer at JFL Peripheral Solution, in Ottawa, Ontario, Canada, where he designs software for scanners. An avid user of PanoTools since 2000. A growing contributer to the source code of PanoTools since Aug 2003 and a current maintainer of [http://panotools.sourceforge.net PanoTools]. Before receiving his degree in Computer Software in 1999, he received a diploma of Fine Art in Photography in 1990.<br />
<br />
Most recently his attention has been directed to creating Immersive Panoramic Video.<br />
<br />
'''Yuval Levy'''<br />
<br />
Available to be backup mentor. Don't think I have the time for full mentorship, unless the student is very self-sufficient.<br />
<br />
== Ideas ==<br />
Will probably be done/collected as [https://blueprints.launchpad.net/hugin Blueprints over at Launchpad], as per [http://groups.google.com/group/hugin-ptx/browse_frm/thread/2fe5639d41369506 this discussion]<br />
<br />
See also the list of unimplemented projects from previous years on [[GSOC 2011 Ideas]].<br />
<br />
== Application from us ==<br />
[[GSOC 2011 Application]]<br />
<br />
== Student Applications ==<br />
[[GSOC 2011 Student Application]]<br />
<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13350Historical:GSOC 2011 Ideas2011-03-31T00:00:19Z<p>Bruno: link to valid unimplemented projects from previous years</p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad]<br />
<br />
See also these ideas from previous years which haven't been implemented:<br />
<br />
* [[SoC 2010 ideas]]<br />
** [[SoC_2010_ideas#Zooming_for_fast_preview|Zooming for the fast preview]]<br />
** [[SoC_2010_ideas#Colour|Colour management]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
** [[SoC_2009_idea#enblend.2Fenfuse_gimp_plugin|enblend/enfuse GIMP plugin (GEGL?)]]<br />
** [[SoC_2009_idea#hugin_RAW_support|Hugin RAW support]]<br />
** [[SoC_2009_idea#zenith.2Fnadir_blending_for_enblend-enfuse|Zenith/Nadir blending for enblend/enfuse]]<br />
** [[SoC_2009_idea#seam_optimization_in_enblend-enfuse|Seam optimisation in enblend/enfuse]]<br />
* [[SoC 2008 ideas]]<br />
** [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI|Interactive OpenGL/python GUI]]<br />
** [[SoC_2008_ideas#Lens_Database|Integration of lensfun lens database]]<br />
** [[SoC_2008_ideas#tCA_Correction|tCA chromatic aberration correction]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]<br />
** [[SoC2007_projects#Processing_of_very_large_images|processing of very large images (GEGL/VIPS)]]<br />
** [[SoC2007_projects#Architectural_Overhaul_of_Panotools|Architectural overhaul of panotools]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2009_idea&diff=13349Historical:SoC 2009 idea2011-03-30T23:49:52Z<p>Bruno: /* Python Bindings */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2009, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2009_student_proposals | student proposal page]] - see examples from [[SoC_2008_student_proposals | last year]]<br />
<br />
'''IMPORTANT:''' at the time of writing it is not known yet if we will be admitted to Google Summer of Code 2009. We can not guarantee you a place in the program, but we recommend you start preparing your application early as the application process is very competitive.<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Mentors =<br />
<br />
The following people have volunteered to be primary mentors:<br />
* Andrew Mihal<br />
* Bruno Postle<br />
* Daniel M. German<br />
* Tom K. Sharpless<br />
* Tim Nugent<br />
* John Cupitt<br />
* Sébastien Roy<br />
<br />
The following people have volunteered to be secondary mentors:<br />
* Pablo d'Angelo<br />
* Jim Watters<br />
<br />
= Application Template =<br />
<br />
[[SoC2009 Application Template]]<br />
<br />
= Possible Projects =<br />
<br />
We welcome you to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects]] and [[SoC_2008_ideas | SoC2008 projects]] proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (chosen and completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* <del>[[SoC_2008_ideas#Ghost_removal_for_enfuse]]</del> (done in 2009 GSoC)<br />
* [[SoC_2008_ideas#Lens_Database]] (the library part is done, see [[lensfun]], but there is still no system for updating the database)<br />
* <del>[[SoC_2008_ideas#tCA_Correction]]</del> (this is done, the [[tca_correct]] tool now exists in the hugin-0.7.0 release)<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* [[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]<br />
<br />
== Python Bindings ==<br />
<br />
''note: there is an experimental but functional set of python bindings ready to be integrated in Hugin 2011.2.0''<br />
<br />
expose all functions / libraries as Python bindings<br />
<br />
== 3D extension of panotools library ==<br />
<br />
''Update Feb 2010: this is largely already completed with the 'mosaic' mode in Hugin 2010.1''<br />
<br />
the current assumption of panotools is that all images are shot from the same point of view in a different direction. develop and implement the mathematics to adjust for a shift in the point form which the pictures where taken.<br />
<br />
== enblend/enfuse gimp plugin ==<br />
<br />
Various GUIs for [[enblend]] and [[enfuse]] already exist (e.g. [http://www.harryvanderwolf.dyndns.org/index.php?lang=en&subject=ImageFuser&texttag=Imagefuser ImageFuser]), however nothing that would as useful as a gimp plugin. e.g. gimp opens multilayer TIFF files created by hugin and other tools, an option to 'blend visible layers with enblend' would allow manual adjustment of masks during blending.<br />
<br />
Note that there are standalone ImageFuser and ExpoBlending tools that provide GUIs for enfuse, these should give some idea of the options that need to be made available in a GIMP plugin. ExpoBlending is also a [http://www.digikam.org/drupal/node/494 Digikam plugin]. There are currently no enblend GUIs.<br />
<br />
== bracketing pano model ==<br />
<br />
''Update Feb 2010: this is already completed with the layout mode completed as part of GSoC 2009''<br />
<br />
Currently the Hugin pano model has no provision for brackets / stacked images. This project would modify the pano model to make provision for image stacks to be considered as a single image or to be optimized locally as a stack before being optimized globally as a panorama.<br />
<br />
== hugin RAW support ==<br />
<br />
(note this proposal needs to be checked for sanity by someone who understands RAW formats)<br />
<br />
[[hugin]] is never going to be a [[RAW]] converter with all the options of a tool such as [[ufraw]], so I would be wary of adding half-baked RAW support to hugin that produced second-rate results.<br />
<br />
Something that ought to work very well would be if hugin/[[enblend]] could support [[RAW]] output, specifically 'linear [[DNG]]'. In this workflow, hugin would import RAW via [[dcraw]] as [[16bit]] linear data with no correction. It would then output linear DNG files which could be opened in any RAW converter for further tweaking.<br />
<br />
This would be a good summer of code project: modify [[hugin]] to use [[dcraw]] as an input plugin, integrate [[TCA]] correction, modify [[enblend]] to write linear [[DNG]] (or create a standalone tiff2dng tool), modify hugin GUI to enable it, fix any [[ufraw]] bugs reading linear DNG.<br />
<br />
== hugin colour balancing ==<br />
<br />
''note: a grey picker has been implemented in Hugin 2011.0.0''<br />
<br />
Internally [[hugin]] uses the EMoR photometric model. This means that adjusting the colour balance in hugin by altering the red/blue channel multipliers will give better results than doing the same in an image editor such as the [[Gimp]]/[[Photoshop]] - Provided the photometric parameters for the camera are calibrated properly. There is potentially unexplored interesting stuff that can be done with this capability: grey pickers, temperature sliders, curve adjustment etc...<br />
<br />
<del>A related problem is that hugin has an internal 'lens' representation that it used to link lens parameters for different photos together, this capability really should be split into three models: '''lens''' grouping photos with the same lens but potentially different CCDs, '''sensor''' grouping photos with the same CCD but potentially different lenses, '''position''' stacked images that can be rotated together (see [[#bracketing pano model]] above) - This is tinkering with hugin fundamentals and needs to be overseen by Pablo.</del> ''Update: these backend changes were implemented as part of the GSoC2009 layout project''<br />
<br />
== Straight-line detection for automated lens calibration ==<br />
<br />
''Update: Note this was added as the calibrate_lens tool as part of GSoC 2009, already available in Hugin 2009.2.0, however picking this up and integrating it would be part of any 'lens database' project.''<br />
<br />
One of the techniques for lens calibration is to [http://hugin.sourceforge.net/tutorials/calibration/ optimise straight lines]. Tom Sharpless suggests: "Hugin needs an easy and reliable way to do straight line lens calibration. After many years using various calibration systems, photogrammetrists seem to have decided the straight line method is best. It is robust, accurate, and can often use naturally occurring straight lines rather than special calibration rigs. And it works well with fisheye lenses, which many other methods do not.<br />
<br />
The key is software that can automatically follow strong "line-like" curves and estimate their positions to subpixel accuracy. Then, using a reasonable model of the lens, an optimizer like the one in Hugin can fit parameters that straighten the lines. Since the raw images of calibration lines are generally curved, a human may have to designate which lines are straight in reality. However, fully automatic straight line calibration is theoretically possible, based on jointly optimizing lens parameters and estimated line shapes.<br />
<br />
A tool of this kind would be especially valuable for calibrating fisheye lenses, something the PanoTools family of s/w has always done poorly. Part of the problem is that the original PT library used the equal-angle model for fisheye lenses, instead of the equal-area model most modern fisheyes are actually designed to. Apparently libpano13 now has the equal-area model, too, but Hugin continues to use the equal-angle one. So an important part of this project could be to revise Hugin to handle fisheye lenses more correctly.<br />
<br />
== Simple mask editing ==<br />
<br />
''Update: Note this is complete and implemented separately from GSoC, it is available since Hugin 2010.2.0 and so can't be a SoC project''<br />
<br />
(note there was an automated masking project in 2008)<br />
<br />
Firstly there are two mask-editing scenarios and they are almost unrelated:<br />
<br />
# masking out objects that you don't want to appear in the scene.<br />
# masking to put one object in-front of another.<br />
<br />
Number 2 is never going to be done in hugin, this is a job for an image<br />
editor, feathered eraser brushes and clone tools. For this we really need<br />
some kind of multilayer output, and I would say that an enblend/enfuse Gimp<br />
plugin to merge these layers two at a time should be enough to make this work well (see above).<br />
<br />
(Note there is a 'layered' target in the Makefile.equirect.mk 'plugin'<br />
which does this multilayered TIFF output)<br />
<br />
The simplest way to provide number 1 is to change the crop tool into a<br />
polygon editor for masking the original images, and store the polygon<br />
coordinates in the 'i' lines of the .pto file - Masking would be performed<br />
at the remapping stage as it currently is for circular crops.<br />
<br />
This is conceptually very simple. At a later date the coordinates can be<br />
translated back and forth between the photo and panorama spaces, then<br />
automation of the mask can build on this.<br />
<br />
== Implementing a new projection model for the creation of mosaics in panotools ==<br />
<br />
''Update: this was a GSoC that failed in 2009, it has however been implemented outside of SoC and has been available in Hugin since 2010.2.0.''<br />
<br />
Currently panotools implements a 3d spherical model for panorama projection. This means that it assumes that the camera rotates around its no-parallax-point from one frame to another. This model is perfectly good for making spherical panoramas.<br />
<br />
There is, however, another use of registration and stitching of photographs: mosaics. In this scenario the object to be captured is a flat plane (such as<br />
a wall, a aerial photograph, or partial scans of a larger work.<br />
<br />
This project will require to reverse engineer and document the current projection model, and propose<br />
and implement a new one. The panotools remapping infrastructure is very flexible and should be<br />
relatively straightforward to accomplish this.<br />
<br />
== zenith/nadir blending for enblend-enfuse ==<br />
<br />
Currently enblend-enfuse is not aware of the zenith/nadir seam in full spherical images. This sometimes results in star-like artifacts. Strategies have been devised to come around that limitation, such as re-projecting the concerned areas, blending them and merging them back. It would be nice if the code could do this automatically.<br />
<br />
== seam optimization in enblend-enfuse ==<br />
<br />
The seam optimization algorithm of enblend-enfuse can be improved. Andrew would be interested to mentor such a project.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2010_ideas&diff=13348Historical:SoC 2010 ideas2011-03-30T23:46:00Z<p>Bruno: /* Regression tests for pano13 */</p>
<hr />
<div>If you are a student willing to participate in The Google Summer of Code 2010:<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* decide if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes; and<br />
* add your proposal to the [[SoC_2010_student_proposals | student proposal page]] - see examples from [[SoC_2009_student_proposals | last year]]<br />
<br />
'''Important:''' we are admitted to Google Summer of Code 2010 but can not guarantee you a place in the program. We recommend you start preparing your application early as the application process is very competitive.<br />
<br />
== Development style ==<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
== Application Template ==<br />
<br />
[http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/hugin SoC2010 Application Template]<br />
<br />
== Possible Projects ==<br />
<br />
You are welcome to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects | SoC2007]], [[SoC_2008_ideas | SoC2008]] and [[SoC_2009_idea | SoC2009]] project proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (VLC integration was completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* [[SoC_2008_ideas#Lens_Database]] The library part, [[lensfun]], is done, but there is still no system for updating the database. ''Important:'' [http://photoropter.berlios.de Photoropter] is being actively developed and any project should be complementary to that.<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* <del>[[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]</del> Note this isn't enough of a project and probably is better done in mathmap<br />
* [[SoC_2009_idea#Python_Bindings]]<br />
* [[SoC_2009_idea#enblend/enfuse_gimp_plugin]]<br />
* <del>[[SoC_2009_idea#hugin_colour_balancing]]</del> see [[#Colour]] below<br />
<br />
=== Zooming for fast preview ===<br />
It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.<br />
<br />
==== Vetting exercise ====<br />
Get the fast preview to scale using openGL transformations. The scale should be changeable, either by keypresses or a gui. Don't worry about scrolling when the panorama is bigger than the window, just show the centre of the panorama.<br />
<br />
===Threading for Hugin===<br />
<br />
''note: this has now been implemented in Hugin so this is not available as a SoC project''<br />
<br />
Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like [http://sourceforge.net/tracker/?func=detail&aid=2872111&group_id=77506&atid=550443 this patch], which loads images when Hugin is otherwise idle, would be better in a background thread.<br />
<br />
The user interface could display temporary placeholders while images are being loaded, and remain interactive.<br />
<br />
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.<br />
<br />
==== Vetting exercise ====<br />
When Hugin starts, start another thread that pops up a window every ten seconds showing a <br />
message. Extra bonus: the message should show relevant information <br />
(e.g. the number of processor cores, a thread id).<br />
<br />
=== Patent free control point generator ===<br />
<br />
''note: the patent free control point generator is complete and is now part of Hugin as [[cpfind]]''<br />
<br />
We now have a patent free control point generator with libpanomatic, but this needs some integration:<br />
<br />
* Ability to read and write .pto projects<br />
* To classify features in a conformal space based on info in the .pto file<br />
* Internal tonemapping of [[HDR]] images to log() space for feature classification<br />
* To not classify features in masked areas<br />
* Test suite<br />
* integration of celeste at feature identification stage<br />
* matching pairs of photos using heuristics (see gigastart)<br />
<br />
A possible different project to the above would be to use GPU for feature classification as suggested on ptx, note however that patented techniques such as SIFT and SURF are not suitable for use in Hugin: SIFT GPU http://www.cs.unc.edu/~ccwu/siftgpu/ uses CUDA parallel processing to search for SIFT features in images. I'm not sure if it does the search to find nearest neighbor points. But there is also a GPU accelerated version of that algorithm too. It is a brute force version of the nearest-k points. Since it is done in parallel it is order of magnitudes faster than the ANN algorithm using by autopano-sift-c. http://www-sop.inria.fr/members/Vincent.Garcia/research_knn.php<br />
<br />
=== UI testing ===<br />
<br />
Update: Summer of Code is strictly coding, so this project isn't possible.<br />
<br />
<del>Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.<br />
<br />
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design</del><br />
<br />
=== Colour ===<br />
<br />
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:<br />
<br />
* Display of images in tabs and preview is not colour managed, integrate [http://www.littlecms.com/ lcms] and access system monitor colour profiles<br />
* <del>Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos to be able to do stuff like this: http://www.flickr.com/photos/sbprzd/4196026736/</del> ''already added to recent hugin''<br />
* [[EXIF]] metadata contains information on colour balance (WBRedLevel, WBGreenLevel & WBBlueLevel) which should be used to initialise the red/blue colour balance parameters in Hugin - Currently Hugin does something very similar for EV.<br />
* [[Chromatic aberration|tca]] correction in [[nona]] with support in GUI and .pto format, possible simple GUI to run [[tca_correct]]<br />
* [[Vignetting]] of colour balance. For example Tokina 12-24 f4 exhibits this phenomenon (see right side of this [http://farm5.static.flickr.com/4043/4385932566_4e3204a12d_o.jpg image]) in amounts that are easily seen, and according to Ken Rockwell (yeah) the effect plagues most ultra wide rectilinears. Could work similarily to current vignetting correction model, but working on red/blue colour channels? (do we really need this? Is the additional complication in the GUI worth it?)<br />
<br />
==== Vetting exercise ====<br />
<br />
Add support for reading [[EXIF]] colour-balance metadata, see [https://sourceforge.net/tracker/?func=detail&aid=2974841&group_id=77506&atid=550444 feature request #2974841 on the Hugin tracker]. Note that implementing the entire request in the tracker is probably too big a task, alternatively you can do something simpler with colour balance such as add a button to the [[Hugin Camera and Lens tab]] that increases the red levels in all selected images by 10% and decreases blue by 10%.<br />
<br />
=== Makefile system and Detection of panoramas ===<br />
<br />
''note: this was implemented in GSoC 2010 and is available in the current Hugin release''<br />
<br />
Hugin uses gnu ''make'' to drive stitching, this involves writing makefiles and executing ''make'' as a sub-process. We have two issues with this;<br />
<br />
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend<br />
* <del>'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters</del><br />
<br />
Write a C/C++ equivalent of [http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm Panotools::Makefile], write lots of tests, identify problem characters on each platform, port Hugin stitching to use this makefile library <del>add filters to filename selection parts of Hugin GUI to prevent use of problem characters</del>.<br />
<br />
Further: Hugin already has 'Align' in the [[Hugin Assistant tab]] for creating panorama projects, but for bigger projects it takes some time. Otherwise there is [[Hugin Batch Processor|PTBatcherGUI]] in the hugin package, which can run several 'stitching' tasks in a queue - i.e. we have a system for queueing 'stitching' but not 'aligning'.<br />
<br />
* Extend [[Hugin Batch Processor|PTBatcherGUI]] so that also the 'Align' functionality from the assistant (with control point detection, cpclean, celeste, optimisation for position and photometric optimisation) can be added to the queue using Makefiles. Note this has been prototyped with [[ptoanchor]], but a C++ version of this code would need to be written.<br />
* In the next step, allow the user to give a directory or list of photos, and search for all possible panoramas and pass these to PTBatcherGUI for 'Aligning' (maybe with a heuristic approach, based on the EXIF data like [[ panostart]] in combination with [[match-n-shift]]).<br />
<br />
==== Vetting exercise ====<br />
<br />
Modify Hugin to <del>read and use</del> ignore [[EXIF]] Rotation tags in photos that have a pixel width smaller than the height (i.e. images that have been rotated in an image editor). <del>[http://sourceforge.net/tracker/?func=detail&aid=2974831&group_id=77506&atid=550444 feature request #2974831 on the Hugin tracker]</del><br />
<br />
=== Regression tests for pano13 ===<br />
<br />
''note: this was completed in GSoC 2010''<br />
<br />
libpano13 is the panotools library containing panoramic math, if it was easier to test it might make life easier for those who want to hack it. A regression testing framework that can be configured for different related command-line tools would be even better.<br />
<br />
Libpano is responsible for doing the image transformations required to project photos to any given output panorama. It is also responsible for the optimization step of Hugin (and PToptimizer).<br />
<br />
libpano is a relatively mature and stable library, but its development has been slowed by the lack of regression testing. Currently there are only two sets of tests (tests directory of the libpano module of panotools). <br />
<br />
This project consists in the creation of:<br />
<br />
1. Infrastructure to test the main functionality of libpano as used by hugin (perhaps at the function level).<br />
<br />
2. Infrastructure to test the command line applications in libpano (PTmender, PTroller, PTtiff2psd, etc).<br />
<br />
3. Create sets of tests.<br />
<br />
The main priority is to implement regression testing of PToptimizer and of the projections (input and output).<br />
<br />
This project requires scripting skills (we are open to either using Python or Perl), knowledge of C <br />
and motivation to create tests sets. <br />
<br />
Images will be provided by the maintainers of libpano, and some might be created by the student.<br />
<br />
=== Your own project ===<br />
We welcome students to choose their own project, instead of using the above ideas. Discus your project ideas on the [http://groups.google.com/group/hugin-ptx/ hugin-ptx mailing list]. Students that design their own projects tend to do well.<br />
<br />
As a vetting exercise, we require you make a patch. Your patch should be relevant to your project. We don't require anything major. The patch should show us some relevant coding skills, and prove you can work with the version control system. Submit your patch to hugin-ptx for peer review.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2010_ideas&diff=13347Historical:SoC 2010 ideas2011-03-30T23:45:29Z<p>Bruno: /* Makefile system and Detection of panoramas */</p>
<hr />
<div>If you are a student willing to participate in The Google Summer of Code 2010:<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* decide if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes; and<br />
* add your proposal to the [[SoC_2010_student_proposals | student proposal page]] - see examples from [[SoC_2009_student_proposals | last year]]<br />
<br />
'''Important:''' we are admitted to Google Summer of Code 2010 but can not guarantee you a place in the program. We recommend you start preparing your application early as the application process is very competitive.<br />
<br />
== Development style ==<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
== Application Template ==<br />
<br />
[http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/hugin SoC2010 Application Template]<br />
<br />
== Possible Projects ==<br />
<br />
You are welcome to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects | SoC2007]], [[SoC_2008_ideas | SoC2008]] and [[SoC_2009_idea | SoC2009]] project proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (VLC integration was completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* [[SoC_2008_ideas#Lens_Database]] The library part, [[lensfun]], is done, but there is still no system for updating the database. ''Important:'' [http://photoropter.berlios.de Photoropter] is being actively developed and any project should be complementary to that.<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* <del>[[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]</del> Note this isn't enough of a project and probably is better done in mathmap<br />
* [[SoC_2009_idea#Python_Bindings]]<br />
* [[SoC_2009_idea#enblend/enfuse_gimp_plugin]]<br />
* <del>[[SoC_2009_idea#hugin_colour_balancing]]</del> see [[#Colour]] below<br />
<br />
=== Zooming for fast preview ===<br />
It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.<br />
<br />
==== Vetting exercise ====<br />
Get the fast preview to scale using openGL transformations. The scale should be changeable, either by keypresses or a gui. Don't worry about scrolling when the panorama is bigger than the window, just show the centre of the panorama.<br />
<br />
===Threading for Hugin===<br />
<br />
''note: this has now been implemented in Hugin so this is not available as a SoC project''<br />
<br />
Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like [http://sourceforge.net/tracker/?func=detail&aid=2872111&group_id=77506&atid=550443 this patch], which loads images when Hugin is otherwise idle, would be better in a background thread.<br />
<br />
The user interface could display temporary placeholders while images are being loaded, and remain interactive.<br />
<br />
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.<br />
<br />
==== Vetting exercise ====<br />
When Hugin starts, start another thread that pops up a window every ten seconds showing a <br />
message. Extra bonus: the message should show relevant information <br />
(e.g. the number of processor cores, a thread id).<br />
<br />
=== Patent free control point generator ===<br />
<br />
''note: the patent free control point generator is complete and is now part of Hugin as [[cpfind]]''<br />
<br />
We now have a patent free control point generator with libpanomatic, but this needs some integration:<br />
<br />
* Ability to read and write .pto projects<br />
* To classify features in a conformal space based on info in the .pto file<br />
* Internal tonemapping of [[HDR]] images to log() space for feature classification<br />
* To not classify features in masked areas<br />
* Test suite<br />
* integration of celeste at feature identification stage<br />
* matching pairs of photos using heuristics (see gigastart)<br />
<br />
A possible different project to the above would be to use GPU for feature classification as suggested on ptx, note however that patented techniques such as SIFT and SURF are not suitable for use in Hugin: SIFT GPU http://www.cs.unc.edu/~ccwu/siftgpu/ uses CUDA parallel processing to search for SIFT features in images. I'm not sure if it does the search to find nearest neighbor points. But there is also a GPU accelerated version of that algorithm too. It is a brute force version of the nearest-k points. Since it is done in parallel it is order of magnitudes faster than the ANN algorithm using by autopano-sift-c. http://www-sop.inria.fr/members/Vincent.Garcia/research_knn.php<br />
<br />
=== UI testing ===<br />
<br />
Update: Summer of Code is strictly coding, so this project isn't possible.<br />
<br />
<del>Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.<br />
<br />
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design</del><br />
<br />
=== Colour ===<br />
<br />
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:<br />
<br />
* Display of images in tabs and preview is not colour managed, integrate [http://www.littlecms.com/ lcms] and access system monitor colour profiles<br />
* <del>Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos to be able to do stuff like this: http://www.flickr.com/photos/sbprzd/4196026736/</del> ''already added to recent hugin''<br />
* [[EXIF]] metadata contains information on colour balance (WBRedLevel, WBGreenLevel & WBBlueLevel) which should be used to initialise the red/blue colour balance parameters in Hugin - Currently Hugin does something very similar for EV.<br />
* [[Chromatic aberration|tca]] correction in [[nona]] with support in GUI and .pto format, possible simple GUI to run [[tca_correct]]<br />
* [[Vignetting]] of colour balance. For example Tokina 12-24 f4 exhibits this phenomenon (see right side of this [http://farm5.static.flickr.com/4043/4385932566_4e3204a12d_o.jpg image]) in amounts that are easily seen, and according to Ken Rockwell (yeah) the effect plagues most ultra wide rectilinears. Could work similarily to current vignetting correction model, but working on red/blue colour channels? (do we really need this? Is the additional complication in the GUI worth it?)<br />
<br />
==== Vetting exercise ====<br />
<br />
Add support for reading [[EXIF]] colour-balance metadata, see [https://sourceforge.net/tracker/?func=detail&aid=2974841&group_id=77506&atid=550444 feature request #2974841 on the Hugin tracker]. Note that implementing the entire request in the tracker is probably too big a task, alternatively you can do something simpler with colour balance such as add a button to the [[Hugin Camera and Lens tab]] that increases the red levels in all selected images by 10% and decreases blue by 10%.<br />
<br />
=== Makefile system and Detection of panoramas ===<br />
<br />
''note: this was implemented in GSoC 2010 and is available in the current Hugin release''<br />
<br />
Hugin uses gnu ''make'' to drive stitching, this involves writing makefiles and executing ''make'' as a sub-process. We have two issues with this;<br />
<br />
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend<br />
* <del>'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters</del><br />
<br />
Write a C/C++ equivalent of [http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm Panotools::Makefile], write lots of tests, identify problem characters on each platform, port Hugin stitching to use this makefile library <del>add filters to filename selection parts of Hugin GUI to prevent use of problem characters</del>.<br />
<br />
Further: Hugin already has 'Align' in the [[Hugin Assistant tab]] for creating panorama projects, but for bigger projects it takes some time. Otherwise there is [[Hugin Batch Processor|PTBatcherGUI]] in the hugin package, which can run several 'stitching' tasks in a queue - i.e. we have a system for queueing 'stitching' but not 'aligning'.<br />
<br />
* Extend [[Hugin Batch Processor|PTBatcherGUI]] so that also the 'Align' functionality from the assistant (with control point detection, cpclean, celeste, optimisation for position and photometric optimisation) can be added to the queue using Makefiles. Note this has been prototyped with [[ptoanchor]], but a C++ version of this code would need to be written.<br />
* In the next step, allow the user to give a directory or list of photos, and search for all possible panoramas and pass these to PTBatcherGUI for 'Aligning' (maybe with a heuristic approach, based on the EXIF data like [[ panostart]] in combination with [[match-n-shift]]).<br />
<br />
==== Vetting exercise ====<br />
<br />
Modify Hugin to <del>read and use</del> ignore [[EXIF]] Rotation tags in photos that have a pixel width smaller than the height (i.e. images that have been rotated in an image editor). <del>[http://sourceforge.net/tracker/?func=detail&aid=2974831&group_id=77506&atid=550444 feature request #2974831 on the Hugin tracker]</del><br />
<br />
=== Regression tests for pano13 ===<br />
<br />
libpano13 is the panotools library containing panoramic math, if it was easier to test it might make life easier for those who want to hack it. A regression testing framework that can be configured for different related command-line tools would be even better.<br />
<br />
Libpano is responsible for doing the image transformations required to project photos to any given output panorama. It is also responsible for the optimization step of Hugin (and PToptimizer).<br />
<br />
libpano is a relatively mature and stable library, but its development has been slowed by the lack of regression testing. Currently there are only two sets of tests (tests directory of the libpano module of panotools). <br />
<br />
This project consists in the creation of:<br />
<br />
1. Infrastructure to test the main functionality of libpano as used by hugin (perhaps at the function level).<br />
<br />
2. Infrastructure to test the command line applications in libpano (PTmender, PTroller, PTtiff2psd, etc).<br />
<br />
3. Create sets of tests.<br />
<br />
The main priority is to implement regression testing of PToptimizer and of the projections (input and output).<br />
<br />
This project requires scripting skills (we are open to either using Python or Perl), knowledge of C <br />
and motivation to create tests sets. <br />
<br />
Images will be provided by the maintainers of libpano, and some might be created by the student.<br />
<br />
=== Your own project ===<br />
We welcome students to choose their own project, instead of using the above ideas. Discus your project ideas on the [http://groups.google.com/group/hugin-ptx/ hugin-ptx mailing list]. Students that design their own projects tend to do well.<br />
<br />
As a vetting exercise, we require you make a patch. Your patch should be relevant to your project. We don't require anything major. The patch should show us some relevant coding skills, and prove you can work with the version control system. Submit your patch to hugin-ptx for peer review.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2010_ideas&diff=13346Historical:SoC 2010 ideas2011-03-30T23:44:27Z<p>Bruno: /* Colour */</p>
<hr />
<div>If you are a student willing to participate in The Google Summer of Code 2010:<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* decide if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes; and<br />
* add your proposal to the [[SoC_2010_student_proposals | student proposal page]] - see examples from [[SoC_2009_student_proposals | last year]]<br />
<br />
'''Important:''' we are admitted to Google Summer of Code 2010 but can not guarantee you a place in the program. We recommend you start preparing your application early as the application process is very competitive.<br />
<br />
== Development style ==<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
== Application Template ==<br />
<br />
[http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/hugin SoC2010 Application Template]<br />
<br />
== Possible Projects ==<br />
<br />
You are welcome to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects | SoC2007]], [[SoC_2008_ideas | SoC2008]] and [[SoC_2009_idea | SoC2009]] project proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (VLC integration was completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* [[SoC_2008_ideas#Lens_Database]] The library part, [[lensfun]], is done, but there is still no system for updating the database. ''Important:'' [http://photoropter.berlios.de Photoropter] is being actively developed and any project should be complementary to that.<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* <del>[[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]</del> Note this isn't enough of a project and probably is better done in mathmap<br />
* [[SoC_2009_idea#Python_Bindings]]<br />
* [[SoC_2009_idea#enblend/enfuse_gimp_plugin]]<br />
* <del>[[SoC_2009_idea#hugin_colour_balancing]]</del> see [[#Colour]] below<br />
<br />
=== Zooming for fast preview ===<br />
It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.<br />
<br />
==== Vetting exercise ====<br />
Get the fast preview to scale using openGL transformations. The scale should be changeable, either by keypresses or a gui. Don't worry about scrolling when the panorama is bigger than the window, just show the centre of the panorama.<br />
<br />
===Threading for Hugin===<br />
<br />
''note: this has now been implemented in Hugin so this is not available as a SoC project''<br />
<br />
Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like [http://sourceforge.net/tracker/?func=detail&aid=2872111&group_id=77506&atid=550443 this patch], which loads images when Hugin is otherwise idle, would be better in a background thread.<br />
<br />
The user interface could display temporary placeholders while images are being loaded, and remain interactive.<br />
<br />
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.<br />
<br />
==== Vetting exercise ====<br />
When Hugin starts, start another thread that pops up a window every ten seconds showing a <br />
message. Extra bonus: the message should show relevant information <br />
(e.g. the number of processor cores, a thread id).<br />
<br />
=== Patent free control point generator ===<br />
<br />
''note: the patent free control point generator is complete and is now part of Hugin as [[cpfind]]''<br />
<br />
We now have a patent free control point generator with libpanomatic, but this needs some integration:<br />
<br />
* Ability to read and write .pto projects<br />
* To classify features in a conformal space based on info in the .pto file<br />
* Internal tonemapping of [[HDR]] images to log() space for feature classification<br />
* To not classify features in masked areas<br />
* Test suite<br />
* integration of celeste at feature identification stage<br />
* matching pairs of photos using heuristics (see gigastart)<br />
<br />
A possible different project to the above would be to use GPU for feature classification as suggested on ptx, note however that patented techniques such as SIFT and SURF are not suitable for use in Hugin: SIFT GPU http://www.cs.unc.edu/~ccwu/siftgpu/ uses CUDA parallel processing to search for SIFT features in images. I'm not sure if it does the search to find nearest neighbor points. But there is also a GPU accelerated version of that algorithm too. It is a brute force version of the nearest-k points. Since it is done in parallel it is order of magnitudes faster than the ANN algorithm using by autopano-sift-c. http://www-sop.inria.fr/members/Vincent.Garcia/research_knn.php<br />
<br />
=== UI testing ===<br />
<br />
Update: Summer of Code is strictly coding, so this project isn't possible.<br />
<br />
<del>Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.<br />
<br />
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design</del><br />
<br />
=== Colour ===<br />
<br />
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:<br />
<br />
* Display of images in tabs and preview is not colour managed, integrate [http://www.littlecms.com/ lcms] and access system monitor colour profiles<br />
* <del>Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos to be able to do stuff like this: http://www.flickr.com/photos/sbprzd/4196026736/</del> ''already added to recent hugin''<br />
* [[EXIF]] metadata contains information on colour balance (WBRedLevel, WBGreenLevel & WBBlueLevel) which should be used to initialise the red/blue colour balance parameters in Hugin - Currently Hugin does something very similar for EV.<br />
* [[Chromatic aberration|tca]] correction in [[nona]] with support in GUI and .pto format, possible simple GUI to run [[tca_correct]]<br />
* [[Vignetting]] of colour balance. For example Tokina 12-24 f4 exhibits this phenomenon (see right side of this [http://farm5.static.flickr.com/4043/4385932566_4e3204a12d_o.jpg image]) in amounts that are easily seen, and according to Ken Rockwell (yeah) the effect plagues most ultra wide rectilinears. Could work similarily to current vignetting correction model, but working on red/blue colour channels? (do we really need this? Is the additional complication in the GUI worth it?)<br />
<br />
==== Vetting exercise ====<br />
<br />
Add support for reading [[EXIF]] colour-balance metadata, see [https://sourceforge.net/tracker/?func=detail&aid=2974841&group_id=77506&atid=550444 feature request #2974841 on the Hugin tracker]. Note that implementing the entire request in the tracker is probably too big a task, alternatively you can do something simpler with colour balance such as add a button to the [[Hugin Camera and Lens tab]] that increases the red levels in all selected images by 10% and decreases blue by 10%.<br />
<br />
=== Makefile system and Detection of panoramas ===<br />
<br />
Hugin uses gnu ''make'' to drive stitching, this involves writing makefiles and executing ''make'' as a sub-process. We have two issues with this;<br />
<br />
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend<br />
* <del>'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters</del><br />
<br />
Write a C/C++ equivalent of [http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm Panotools::Makefile], write lots of tests, identify problem characters on each platform, port Hugin stitching to use this makefile library <del>add filters to filename selection parts of Hugin GUI to prevent use of problem characters</del>.<br />
<br />
Further: Hugin already has 'Align' in the [[Hugin Assistant tab]] for creating panorama projects, but for bigger projects it takes some time. Otherwise there is [[Hugin Batch Processor|PTBatcherGUI]] in the hugin package, which can run several 'stitching' tasks in a queue - i.e. we have a system for queueing 'stitching' but not 'aligning'.<br />
<br />
* Extend [[Hugin Batch Processor|PTBatcherGUI]] so that also the 'Align' functionality from the assistant (with control point detection, cpclean, celeste, optimisation for position and photometric optimisation) can be added to the queue using Makefiles. Note this has been prototyped with [[ptoanchor]], but a C++ version of this code would need to be written.<br />
* In the next step, allow the user to give a directory or list of photos, and search for all possible panoramas and pass these to PTBatcherGUI for 'Aligning' (maybe with a heuristic approach, based on the EXIF data like [[ panostart]] in combination with [[match-n-shift]]).<br />
<br />
==== Vetting exercise ====<br />
<br />
Modify Hugin to <del>read and use</del> ignore [[EXIF]] Rotation tags in photos that have a pixel width smaller than the height (i.e. images that have been rotated in an image editor). <del>[http://sourceforge.net/tracker/?func=detail&aid=2974831&group_id=77506&atid=550444 feature request #2974831 on the Hugin tracker]</del><br />
<br />
=== Regression tests for pano13 ===<br />
<br />
libpano13 is the panotools library containing panoramic math, if it was easier to test it might make life easier for those who want to hack it. A regression testing framework that can be configured for different related command-line tools would be even better.<br />
<br />
Libpano is responsible for doing the image transformations required to project photos to any given output panorama. It is also responsible for the optimization step of Hugin (and PToptimizer).<br />
<br />
libpano is a relatively mature and stable library, but its development has been slowed by the lack of regression testing. Currently there are only two sets of tests (tests directory of the libpano module of panotools). <br />
<br />
This project consists in the creation of:<br />
<br />
1. Infrastructure to test the main functionality of libpano as used by hugin (perhaps at the function level).<br />
<br />
2. Infrastructure to test the command line applications in libpano (PTmender, PTroller, PTtiff2psd, etc).<br />
<br />
3. Create sets of tests.<br />
<br />
The main priority is to implement regression testing of PToptimizer and of the projections (input and output).<br />
<br />
This project requires scripting skills (we are open to either using Python or Perl), knowledge of C <br />
and motivation to create tests sets. <br />
<br />
Images will be provided by the maintainers of libpano, and some might be created by the student.<br />
<br />
=== Your own project ===<br />
We welcome students to choose their own project, instead of using the above ideas. Discus your project ideas on the [http://groups.google.com/group/hugin-ptx/ hugin-ptx mailing list]. Students that design their own projects tend to do well.<br />
<br />
As a vetting exercise, we require you make a patch. Your patch should be relevant to your project. We don't require anything major. The patch should show us some relevant coding skills, and prove you can work with the version control system. Submit your patch to hugin-ptx for peer review.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2010_ideas&diff=13345Historical:SoC 2010 ideas2011-03-30T23:43:06Z<p>Bruno: /* Patent free control point generator */</p>
<hr />
<div>If you are a student willing to participate in The Google Summer of Code 2010:<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* decide if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes; and<br />
* add your proposal to the [[SoC_2010_student_proposals | student proposal page]] - see examples from [[SoC_2009_student_proposals | last year]]<br />
<br />
'''Important:''' we are admitted to Google Summer of Code 2010 but can not guarantee you a place in the program. We recommend you start preparing your application early as the application process is very competitive.<br />
<br />
== Development style ==<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
== Application Template ==<br />
<br />
[http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/hugin SoC2010 Application Template]<br />
<br />
== Possible Projects ==<br />
<br />
You are welcome to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects | SoC2007]], [[SoC_2008_ideas | SoC2008]] and [[SoC_2009_idea | SoC2009]] project proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (VLC integration was completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* [[SoC_2008_ideas#Lens_Database]] The library part, [[lensfun]], is done, but there is still no system for updating the database. ''Important:'' [http://photoropter.berlios.de Photoropter] is being actively developed and any project should be complementary to that.<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* <del>[[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]</del> Note this isn't enough of a project and probably is better done in mathmap<br />
* [[SoC_2009_idea#Python_Bindings]]<br />
* [[SoC_2009_idea#enblend/enfuse_gimp_plugin]]<br />
* <del>[[SoC_2009_idea#hugin_colour_balancing]]</del> see [[#Colour]] below<br />
<br />
=== Zooming for fast preview ===<br />
It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.<br />
<br />
==== Vetting exercise ====<br />
Get the fast preview to scale using openGL transformations. The scale should be changeable, either by keypresses or a gui. Don't worry about scrolling when the panorama is bigger than the window, just show the centre of the panorama.<br />
<br />
===Threading for Hugin===<br />
<br />
''note: this has now been implemented in Hugin so this is not available as a SoC project''<br />
<br />
Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like [http://sourceforge.net/tracker/?func=detail&aid=2872111&group_id=77506&atid=550443 this patch], which loads images when Hugin is otherwise idle, would be better in a background thread.<br />
<br />
The user interface could display temporary placeholders while images are being loaded, and remain interactive.<br />
<br />
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.<br />
<br />
==== Vetting exercise ====<br />
When Hugin starts, start another thread that pops up a window every ten seconds showing a <br />
message. Extra bonus: the message should show relevant information <br />
(e.g. the number of processor cores, a thread id).<br />
<br />
=== Patent free control point generator ===<br />
<br />
''note: the patent free control point generator is complete and is now part of Hugin as [[cpfind]]''<br />
<br />
We now have a patent free control point generator with libpanomatic, but this needs some integration:<br />
<br />
* Ability to read and write .pto projects<br />
* To classify features in a conformal space based on info in the .pto file<br />
* Internal tonemapping of [[HDR]] images to log() space for feature classification<br />
* To not classify features in masked areas<br />
* Test suite<br />
* integration of celeste at feature identification stage<br />
* matching pairs of photos using heuristics (see gigastart)<br />
<br />
A possible different project to the above would be to use GPU for feature classification as suggested on ptx, note however that patented techniques such as SIFT and SURF are not suitable for use in Hugin: SIFT GPU http://www.cs.unc.edu/~ccwu/siftgpu/ uses CUDA parallel processing to search for SIFT features in images. I'm not sure if it does the search to find nearest neighbor points. But there is also a GPU accelerated version of that algorithm too. It is a brute force version of the nearest-k points. Since it is done in parallel it is order of magnitudes faster than the ANN algorithm using by autopano-sift-c. http://www-sop.inria.fr/members/Vincent.Garcia/research_knn.php<br />
<br />
=== UI testing ===<br />
<br />
Update: Summer of Code is strictly coding, so this project isn't possible.<br />
<br />
<del>Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.<br />
<br />
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design</del><br />
<br />
=== Colour ===<br />
<br />
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:<br />
<br />
* Display of images in tabs and preview is not colour managed, integrate [http://www.littlecms.com/ lcms] and access system monitor colour profiles<br />
* Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos to be able to do stuff like this: http://www.flickr.com/photos/sbprzd/4196026736/<br />
* [[EXIF]] metadata contains information on colour balance (WBRedLevel, WBGreenLevel & WBBlueLevel) which should be used to initialise the red/blue colour balance parameters in Hugin - Currently Hugin does something very similar for EV.<br />
* [[Chromatic aberration|tca]] correction in [[nona]] with support in GUI and .pto format, possible simple GUI to run [[tca_correct]]<br />
* [[Vignetting]] of colour balance. For example Tokina 12-24 f4 exhibits this phenomenon (see right side of this [http://farm5.static.flickr.com/4043/4385932566_4e3204a12d_o.jpg image]) in amounts that are easily seen, and according to Ken Rockwell (yeah) the effect plagues most ultra wide rectilinears. Could work similarily to current vignetting correction model, but working on red/blue colour channels? (do we really need this? Is the additional complication in the GUI worth it?)<br />
<br />
==== Vetting exercise ====<br />
<br />
Add support for reading [[EXIF]] colour-balance metadata, see [https://sourceforge.net/tracker/?func=detail&aid=2974841&group_id=77506&atid=550444 feature request #2974841 on the Hugin tracker]. Note that implementing the entire request in the tracker is probably too big a task, alternatively you can do something simpler with colour balance such as add a button to the [[Hugin Camera and Lens tab]] that increases the red levels in all selected images by 10% and decreases blue by 10%.<br />
<br />
=== Makefile system and Detection of panoramas ===<br />
<br />
Hugin uses gnu ''make'' to drive stitching, this involves writing makefiles and executing ''make'' as a sub-process. We have two issues with this;<br />
<br />
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend<br />
* <del>'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters</del><br />
<br />
Write a C/C++ equivalent of [http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm Panotools::Makefile], write lots of tests, identify problem characters on each platform, port Hugin stitching to use this makefile library <del>add filters to filename selection parts of Hugin GUI to prevent use of problem characters</del>.<br />
<br />
Further: Hugin already has 'Align' in the [[Hugin Assistant tab]] for creating panorama projects, but for bigger projects it takes some time. Otherwise there is [[Hugin Batch Processor|PTBatcherGUI]] in the hugin package, which can run several 'stitching' tasks in a queue - i.e. we have a system for queueing 'stitching' but not 'aligning'.<br />
<br />
* Extend [[Hugin Batch Processor|PTBatcherGUI]] so that also the 'Align' functionality from the assistant (with control point detection, cpclean, celeste, optimisation for position and photometric optimisation) can be added to the queue using Makefiles. Note this has been prototyped with [[ptoanchor]], but a C++ version of this code would need to be written.<br />
* In the next step, allow the user to give a directory or list of photos, and search for all possible panoramas and pass these to PTBatcherGUI for 'Aligning' (maybe with a heuristic approach, based on the EXIF data like [[ panostart]] in combination with [[match-n-shift]]).<br />
<br />
==== Vetting exercise ====<br />
<br />
Modify Hugin to <del>read and use</del> ignore [[EXIF]] Rotation tags in photos that have a pixel width smaller than the height (i.e. images that have been rotated in an image editor). <del>[http://sourceforge.net/tracker/?func=detail&aid=2974831&group_id=77506&atid=550444 feature request #2974831 on the Hugin tracker]</del><br />
<br />
=== Regression tests for pano13 ===<br />
<br />
libpano13 is the panotools library containing panoramic math, if it was easier to test it might make life easier for those who want to hack it. A regression testing framework that can be configured for different related command-line tools would be even better.<br />
<br />
Libpano is responsible for doing the image transformations required to project photos to any given output panorama. It is also responsible for the optimization step of Hugin (and PToptimizer).<br />
<br />
libpano is a relatively mature and stable library, but its development has been slowed by the lack of regression testing. Currently there are only two sets of tests (tests directory of the libpano module of panotools). <br />
<br />
This project consists in the creation of:<br />
<br />
1. Infrastructure to test the main functionality of libpano as used by hugin (perhaps at the function level).<br />
<br />
2. Infrastructure to test the command line applications in libpano (PTmender, PTroller, PTtiff2psd, etc).<br />
<br />
3. Create sets of tests.<br />
<br />
The main priority is to implement regression testing of PToptimizer and of the projections (input and output).<br />
<br />
This project requires scripting skills (we are open to either using Python or Perl), knowledge of C <br />
and motivation to create tests sets. <br />
<br />
Images will be provided by the maintainers of libpano, and some might be created by the student.<br />
<br />
=== Your own project ===<br />
We welcome students to choose their own project, instead of using the above ideas. Discus your project ideas on the [http://groups.google.com/group/hugin-ptx/ hugin-ptx mailing list]. Students that design their own projects tend to do well.<br />
<br />
As a vetting exercise, we require you make a patch. Your patch should be relevant to your project. We don't require anything major. The patch should show us some relevant coding skills, and prove you can work with the version control system. Submit your patch to hugin-ptx for peer review.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2010_ideas&diff=13344Historical:SoC 2010 ideas2011-03-30T23:42:15Z<p>Bruno: /* Threading for Hugin */</p>
<hr />
<div>If you are a student willing to participate in The Google Summer of Code 2010:<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* decide if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes; and<br />
* add your proposal to the [[SoC_2010_student_proposals | student proposal page]] - see examples from [[SoC_2009_student_proposals | last year]]<br />
<br />
'''Important:''' we are admitted to Google Summer of Code 2010 but can not guarantee you a place in the program. We recommend you start preparing your application early as the application process is very competitive.<br />
<br />
== Development style ==<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
== Application Template ==<br />
<br />
[http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/hugin SoC2010 Application Template]<br />
<br />
== Possible Projects ==<br />
<br />
You are welcome to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects | SoC2007]], [[SoC_2008_ideas | SoC2008]] and [[SoC_2009_idea | SoC2009]] project proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (VLC integration was completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* [[SoC_2008_ideas#Lens_Database]] The library part, [[lensfun]], is done, but there is still no system for updating the database. ''Important:'' [http://photoropter.berlios.de Photoropter] is being actively developed and any project should be complementary to that.<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* <del>[[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]</del> Note this isn't enough of a project and probably is better done in mathmap<br />
* [[SoC_2009_idea#Python_Bindings]]<br />
* [[SoC_2009_idea#enblend/enfuse_gimp_plugin]]<br />
* <del>[[SoC_2009_idea#hugin_colour_balancing]]</del> see [[#Colour]] below<br />
<br />
=== Zooming for fast preview ===<br />
It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.<br />
<br />
==== Vetting exercise ====<br />
Get the fast preview to scale using openGL transformations. The scale should be changeable, either by keypresses or a gui. Don't worry about scrolling when the panorama is bigger than the window, just show the centre of the panorama.<br />
<br />
===Threading for Hugin===<br />
<br />
''note: this has now been implemented in Hugin so this is not available as a SoC project''<br />
<br />
Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like [http://sourceforge.net/tracker/?func=detail&aid=2872111&group_id=77506&atid=550443 this patch], which loads images when Hugin is otherwise idle, would be better in a background thread.<br />
<br />
The user interface could display temporary placeholders while images are being loaded, and remain interactive.<br />
<br />
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.<br />
<br />
==== Vetting exercise ====<br />
When Hugin starts, start another thread that pops up a window every ten seconds showing a <br />
message. Extra bonus: the message should show relevant information <br />
(e.g. the number of processor cores, a thread id).<br />
<br />
=== Patent free control point generator ===<br />
<br />
We now have a patent free control point generator with libpanomatic, but this needs some integration:<br />
<br />
* Ability to read and write .pto projects<br />
* To classify features in a conformal space based on info in the .pto file<br />
* Internal tonemapping of [[HDR]] images to log() space for feature classification<br />
* To not classify features in masked areas<br />
* Test suite<br />
* integration of celeste at feature identification stage<br />
* matching pairs of photos using heuristics (see gigastart)<br />
<br />
A possible different project to the above would be to use GPU for feature classification as suggested on ptx, note however that patented techniques such as SIFT and SURF are not suitable for use in Hugin: SIFT GPU http://www.cs.unc.edu/~ccwu/siftgpu/ uses CUDA parallel processing to search for SIFT features in images. I'm not sure if it does the search to find nearest neighbor points. But there is also a GPU accelerated version of that algorithm too. It is a brute force version of the nearest-k points. Since it is done in parallel it is order of magnitudes faster than the ANN algorithm using by autopano-sift-c. http://www-sop.inria.fr/members/Vincent.Garcia/research_knn.php<br />
<br />
=== UI testing ===<br />
<br />
Update: Summer of Code is strictly coding, so this project isn't possible.<br />
<br />
<del>Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.<br />
<br />
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design</del><br />
<br />
=== Colour ===<br />
<br />
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:<br />
<br />
* Display of images in tabs and preview is not colour managed, integrate [http://www.littlecms.com/ lcms] and access system monitor colour profiles<br />
* Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos to be able to do stuff like this: http://www.flickr.com/photos/sbprzd/4196026736/<br />
* [[EXIF]] metadata contains information on colour balance (WBRedLevel, WBGreenLevel & WBBlueLevel) which should be used to initialise the red/blue colour balance parameters in Hugin - Currently Hugin does something very similar for EV.<br />
* [[Chromatic aberration|tca]] correction in [[nona]] with support in GUI and .pto format, possible simple GUI to run [[tca_correct]]<br />
* [[Vignetting]] of colour balance. For example Tokina 12-24 f4 exhibits this phenomenon (see right side of this [http://farm5.static.flickr.com/4043/4385932566_4e3204a12d_o.jpg image]) in amounts that are easily seen, and according to Ken Rockwell (yeah) the effect plagues most ultra wide rectilinears. Could work similarily to current vignetting correction model, but working on red/blue colour channels? (do we really need this? Is the additional complication in the GUI worth it?)<br />
<br />
==== Vetting exercise ====<br />
<br />
Add support for reading [[EXIF]] colour-balance metadata, see [https://sourceforge.net/tracker/?func=detail&aid=2974841&group_id=77506&atid=550444 feature request #2974841 on the Hugin tracker]. Note that implementing the entire request in the tracker is probably too big a task, alternatively you can do something simpler with colour balance such as add a button to the [[Hugin Camera and Lens tab]] that increases the red levels in all selected images by 10% and decreases blue by 10%.<br />
<br />
=== Makefile system and Detection of panoramas ===<br />
<br />
Hugin uses gnu ''make'' to drive stitching, this involves writing makefiles and executing ''make'' as a sub-process. We have two issues with this;<br />
<br />
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend<br />
* <del>'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters</del><br />
<br />
Write a C/C++ equivalent of [http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Makefile.pm Panotools::Makefile], write lots of tests, identify problem characters on each platform, port Hugin stitching to use this makefile library <del>add filters to filename selection parts of Hugin GUI to prevent use of problem characters</del>.<br />
<br />
Further: Hugin already has 'Align' in the [[Hugin Assistant tab]] for creating panorama projects, but for bigger projects it takes some time. Otherwise there is [[Hugin Batch Processor|PTBatcherGUI]] in the hugin package, which can run several 'stitching' tasks in a queue - i.e. we have a system for queueing 'stitching' but not 'aligning'.<br />
<br />
* Extend [[Hugin Batch Processor|PTBatcherGUI]] so that also the 'Align' functionality from the assistant (with control point detection, cpclean, celeste, optimisation for position and photometric optimisation) can be added to the queue using Makefiles. Note this has been prototyped with [[ptoanchor]], but a C++ version of this code would need to be written.<br />
* In the next step, allow the user to give a directory or list of photos, and search for all possible panoramas and pass these to PTBatcherGUI for 'Aligning' (maybe with a heuristic approach, based on the EXIF data like [[ panostart]] in combination with [[match-n-shift]]).<br />
<br />
==== Vetting exercise ====<br />
<br />
Modify Hugin to <del>read and use</del> ignore [[EXIF]] Rotation tags in photos that have a pixel width smaller than the height (i.e. images that have been rotated in an image editor). <del>[http://sourceforge.net/tracker/?func=detail&aid=2974831&group_id=77506&atid=550444 feature request #2974831 on the Hugin tracker]</del><br />
<br />
=== Regression tests for pano13 ===<br />
<br />
libpano13 is the panotools library containing panoramic math, if it was easier to test it might make life easier for those who want to hack it. A regression testing framework that can be configured for different related command-line tools would be even better.<br />
<br />
Libpano is responsible for doing the image transformations required to project photos to any given output panorama. It is also responsible for the optimization step of Hugin (and PToptimizer).<br />
<br />
libpano is a relatively mature and stable library, but its development has been slowed by the lack of regression testing. Currently there are only two sets of tests (tests directory of the libpano module of panotools). <br />
<br />
This project consists in the creation of:<br />
<br />
1. Infrastructure to test the main functionality of libpano as used by hugin (perhaps at the function level).<br />
<br />
2. Infrastructure to test the command line applications in libpano (PTmender, PTroller, PTtiff2psd, etc).<br />
<br />
3. Create sets of tests.<br />
<br />
The main priority is to implement regression testing of PToptimizer and of the projections (input and output).<br />
<br />
This project requires scripting skills (we are open to either using Python or Perl), knowledge of C <br />
and motivation to create tests sets. <br />
<br />
Images will be provided by the maintainers of libpano, and some might be created by the student.<br />
<br />
=== Your own project ===<br />
We welcome students to choose their own project, instead of using the above ideas. Discus your project ideas on the [http://groups.google.com/group/hugin-ptx/ hugin-ptx mailing list]. Students that design their own projects tend to do well.<br />
<br />
As a vetting exercise, we require you make a patch. Your patch should be relevant to your project. We don't require anything major. The patch should show us some relevant coding skills, and prove you can work with the version control system. Submit your patch to hugin-ptx for peer review.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2009_idea&diff=13343Historical:SoC 2009 idea2011-03-30T23:41:10Z<p>Bruno: /* Implementing a new projection model for the creation of mosaics in panotools */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2009, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2009_student_proposals | student proposal page]] - see examples from [[SoC_2008_student_proposals | last year]]<br />
<br />
'''IMPORTANT:''' at the time of writing it is not known yet if we will be admitted to Google Summer of Code 2009. We can not guarantee you a place in the program, but we recommend you start preparing your application early as the application process is very competitive.<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Mentors =<br />
<br />
The following people have volunteered to be primary mentors:<br />
* Andrew Mihal<br />
* Bruno Postle<br />
* Daniel M. German<br />
* Tom K. Sharpless<br />
* Tim Nugent<br />
* John Cupitt<br />
* Sébastien Roy<br />
<br />
The following people have volunteered to be secondary mentors:<br />
* Pablo d'Angelo<br />
* Jim Watters<br />
<br />
= Application Template =<br />
<br />
[[SoC2009 Application Template]]<br />
<br />
= Possible Projects =<br />
<br />
We welcome you to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects]] and [[SoC_2008_ideas | SoC2008 projects]] proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (chosen and completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* <del>[[SoC_2008_ideas#Ghost_removal_for_enfuse]]</del> (done in 2009 GSoC)<br />
* [[SoC_2008_ideas#Lens_Database]] (the library part is done, see [[lensfun]], but there is still no system for updating the database)<br />
* <del>[[SoC_2008_ideas#tCA_Correction]]</del> (this is done, the [[tca_correct]] tool now exists in the hugin-0.7.0 release)<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* [[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]<br />
<br />
== Python Bindings ==<br />
<br />
expose all functions / libraries as Python bindings<br />
<br />
== 3D extension of panotools library ==<br />
<br />
''Update Feb 2010: this is largely already completed with the 'mosaic' mode in Hugin 2010.1''<br />
<br />
the current assumption of panotools is that all images are shot from the same point of view in a different direction. develop and implement the mathematics to adjust for a shift in the point form which the pictures where taken.<br />
<br />
== enblend/enfuse gimp plugin ==<br />
<br />
Various GUIs for [[enblend]] and [[enfuse]] already exist (e.g. [http://www.harryvanderwolf.dyndns.org/index.php?lang=en&subject=ImageFuser&texttag=Imagefuser ImageFuser]), however nothing that would as useful as a gimp plugin. e.g. gimp opens multilayer TIFF files created by hugin and other tools, an option to 'blend visible layers with enblend' would allow manual adjustment of masks during blending.<br />
<br />
Note that there are standalone ImageFuser and ExpoBlending tools that provide GUIs for enfuse, these should give some idea of the options that need to be made available in a GIMP plugin. ExpoBlending is also a [http://www.digikam.org/drupal/node/494 Digikam plugin]. There are currently no enblend GUIs.<br />
<br />
== bracketing pano model ==<br />
<br />
''Update Feb 2010: this is already completed with the layout mode completed as part of GSoC 2009''<br />
<br />
Currently the Hugin pano model has no provision for brackets / stacked images. This project would modify the pano model to make provision for image stacks to be considered as a single image or to be optimized locally as a stack before being optimized globally as a panorama.<br />
<br />
== hugin RAW support ==<br />
<br />
(note this proposal needs to be checked for sanity by someone who understands RAW formats)<br />
<br />
[[hugin]] is never going to be a [[RAW]] converter with all the options of a tool such as [[ufraw]], so I would be wary of adding half-baked RAW support to hugin that produced second-rate results.<br />
<br />
Something that ought to work very well would be if hugin/[[enblend]] could support [[RAW]] output, specifically 'linear [[DNG]]'. In this workflow, hugin would import RAW via [[dcraw]] as [[16bit]] linear data with no correction. It would then output linear DNG files which could be opened in any RAW converter for further tweaking.<br />
<br />
This would be a good summer of code project: modify [[hugin]] to use [[dcraw]] as an input plugin, integrate [[TCA]] correction, modify [[enblend]] to write linear [[DNG]] (or create a standalone tiff2dng tool), modify hugin GUI to enable it, fix any [[ufraw]] bugs reading linear DNG.<br />
<br />
== hugin colour balancing ==<br />
<br />
''note: a grey picker has been implemented in Hugin 2011.0.0''<br />
<br />
Internally [[hugin]] uses the EMoR photometric model. This means that adjusting the colour balance in hugin by altering the red/blue channel multipliers will give better results than doing the same in an image editor such as the [[Gimp]]/[[Photoshop]] - Provided the photometric parameters for the camera are calibrated properly. There is potentially unexplored interesting stuff that can be done with this capability: grey pickers, temperature sliders, curve adjustment etc...<br />
<br />
<del>A related problem is that hugin has an internal 'lens' representation that it used to link lens parameters for different photos together, this capability really should be split into three models: '''lens''' grouping photos with the same lens but potentially different CCDs, '''sensor''' grouping photos with the same CCD but potentially different lenses, '''position''' stacked images that can be rotated together (see [[#bracketing pano model]] above) - This is tinkering with hugin fundamentals and needs to be overseen by Pablo.</del> ''Update: these backend changes were implemented as part of the GSoC2009 layout project''<br />
<br />
== Straight-line detection for automated lens calibration ==<br />
<br />
''Update: Note this was added as the calibrate_lens tool as part of GSoC 2009, already available in Hugin 2009.2.0, however picking this up and integrating it would be part of any 'lens database' project.''<br />
<br />
One of the techniques for lens calibration is to [http://hugin.sourceforge.net/tutorials/calibration/ optimise straight lines]. Tom Sharpless suggests: "Hugin needs an easy and reliable way to do straight line lens calibration. After many years using various calibration systems, photogrammetrists seem to have decided the straight line method is best. It is robust, accurate, and can often use naturally occurring straight lines rather than special calibration rigs. And it works well with fisheye lenses, which many other methods do not.<br />
<br />
The key is software that can automatically follow strong "line-like" curves and estimate their positions to subpixel accuracy. Then, using a reasonable model of the lens, an optimizer like the one in Hugin can fit parameters that straighten the lines. Since the raw images of calibration lines are generally curved, a human may have to designate which lines are straight in reality. However, fully automatic straight line calibration is theoretically possible, based on jointly optimizing lens parameters and estimated line shapes.<br />
<br />
A tool of this kind would be especially valuable for calibrating fisheye lenses, something the PanoTools family of s/w has always done poorly. Part of the problem is that the original PT library used the equal-angle model for fisheye lenses, instead of the equal-area model most modern fisheyes are actually designed to. Apparently libpano13 now has the equal-area model, too, but Hugin continues to use the equal-angle one. So an important part of this project could be to revise Hugin to handle fisheye lenses more correctly.<br />
<br />
== Simple mask editing ==<br />
<br />
''Update: Note this is complete and implemented separately from GSoC, it is available since Hugin 2010.2.0 and so can't be a SoC project''<br />
<br />
(note there was an automated masking project in 2008)<br />
<br />
Firstly there are two mask-editing scenarios and they are almost unrelated:<br />
<br />
# masking out objects that you don't want to appear in the scene.<br />
# masking to put one object in-front of another.<br />
<br />
Number 2 is never going to be done in hugin, this is a job for an image<br />
editor, feathered eraser brushes and clone tools. For this we really need<br />
some kind of multilayer output, and I would say that an enblend/enfuse Gimp<br />
plugin to merge these layers two at a time should be enough to make this work well (see above).<br />
<br />
(Note there is a 'layered' target in the Makefile.equirect.mk 'plugin'<br />
which does this multilayered TIFF output)<br />
<br />
The simplest way to provide number 1 is to change the crop tool into a<br />
polygon editor for masking the original images, and store the polygon<br />
coordinates in the 'i' lines of the .pto file - Masking would be performed<br />
at the remapping stage as it currently is for circular crops.<br />
<br />
This is conceptually very simple. At a later date the coordinates can be<br />
translated back and forth between the photo and panorama spaces, then<br />
automation of the mask can build on this.<br />
<br />
== Implementing a new projection model for the creation of mosaics in panotools ==<br />
<br />
''Update: this was a GSoC that failed in 2009, it has however been implemented outside of SoC and has been available in Hugin since 2010.2.0.''<br />
<br />
Currently panotools implements a 3d spherical model for panorama projection. This means that it assumes that the camera rotates around its no-parallax-point from one frame to another. This model is perfectly good for making spherical panoramas.<br />
<br />
There is, however, another use of registration and stitching of photographs: mosaics. In this scenario the object to be captured is a flat plane (such as<br />
a wall, a aerial photograph, or partial scans of a larger work.<br />
<br />
This project will require to reverse engineer and document the current projection model, and propose<br />
and implement a new one. The panotools remapping infrastructure is very flexible and should be<br />
relatively straightforward to accomplish this.<br />
<br />
== zenith/nadir blending for enblend-enfuse ==<br />
<br />
Currently enblend-enfuse is not aware of the zenith/nadir seam in full spherical images. This sometimes results in star-like artifacts. Strategies have been devised to come around that limitation, such as re-projecting the concerned areas, blending them and merging them back. It would be nice if the code could do this automatically.<br />
<br />
== seam optimization in enblend-enfuse ==<br />
<br />
The seam optimization algorithm of enblend-enfuse can be improved. Andrew would be interested to mentor such a project.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2009_idea&diff=13342Historical:SoC 2009 idea2011-03-30T23:40:34Z<p>Bruno: /* Simple mask editing */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2009, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2009_student_proposals | student proposal page]] - see examples from [[SoC_2008_student_proposals | last year]]<br />
<br />
'''IMPORTANT:''' at the time of writing it is not known yet if we will be admitted to Google Summer of Code 2009. We can not guarantee you a place in the program, but we recommend you start preparing your application early as the application process is very competitive.<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Mentors =<br />
<br />
The following people have volunteered to be primary mentors:<br />
* Andrew Mihal<br />
* Bruno Postle<br />
* Daniel M. German<br />
* Tom K. Sharpless<br />
* Tim Nugent<br />
* John Cupitt<br />
* Sébastien Roy<br />
<br />
The following people have volunteered to be secondary mentors:<br />
* Pablo d'Angelo<br />
* Jim Watters<br />
<br />
= Application Template =<br />
<br />
[[SoC2009 Application Template]]<br />
<br />
= Possible Projects =<br />
<br />
We welcome you to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects]] and [[SoC_2008_ideas | SoC2008 projects]] proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (chosen and completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* <del>[[SoC_2008_ideas#Ghost_removal_for_enfuse]]</del> (done in 2009 GSoC)<br />
* [[SoC_2008_ideas#Lens_Database]] (the library part is done, see [[lensfun]], but there is still no system for updating the database)<br />
* <del>[[SoC_2008_ideas#tCA_Correction]]</del> (this is done, the [[tca_correct]] tool now exists in the hugin-0.7.0 release)<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* [[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]<br />
<br />
== Python Bindings ==<br />
<br />
expose all functions / libraries as Python bindings<br />
<br />
== 3D extension of panotools library ==<br />
<br />
''Update Feb 2010: this is largely already completed with the 'mosaic' mode in Hugin 2010.1''<br />
<br />
the current assumption of panotools is that all images are shot from the same point of view in a different direction. develop and implement the mathematics to adjust for a shift in the point form which the pictures where taken.<br />
<br />
== enblend/enfuse gimp plugin ==<br />
<br />
Various GUIs for [[enblend]] and [[enfuse]] already exist (e.g. [http://www.harryvanderwolf.dyndns.org/index.php?lang=en&subject=ImageFuser&texttag=Imagefuser ImageFuser]), however nothing that would as useful as a gimp plugin. e.g. gimp opens multilayer TIFF files created by hugin and other tools, an option to 'blend visible layers with enblend' would allow manual adjustment of masks during blending.<br />
<br />
Note that there are standalone ImageFuser and ExpoBlending tools that provide GUIs for enfuse, these should give some idea of the options that need to be made available in a GIMP plugin. ExpoBlending is also a [http://www.digikam.org/drupal/node/494 Digikam plugin]. There are currently no enblend GUIs.<br />
<br />
== bracketing pano model ==<br />
<br />
''Update Feb 2010: this is already completed with the layout mode completed as part of GSoC 2009''<br />
<br />
Currently the Hugin pano model has no provision for brackets / stacked images. This project would modify the pano model to make provision for image stacks to be considered as a single image or to be optimized locally as a stack before being optimized globally as a panorama.<br />
<br />
== hugin RAW support ==<br />
<br />
(note this proposal needs to be checked for sanity by someone who understands RAW formats)<br />
<br />
[[hugin]] is never going to be a [[RAW]] converter with all the options of a tool such as [[ufraw]], so I would be wary of adding half-baked RAW support to hugin that produced second-rate results.<br />
<br />
Something that ought to work very well would be if hugin/[[enblend]] could support [[RAW]] output, specifically 'linear [[DNG]]'. In this workflow, hugin would import RAW via [[dcraw]] as [[16bit]] linear data with no correction. It would then output linear DNG files which could be opened in any RAW converter for further tweaking.<br />
<br />
This would be a good summer of code project: modify [[hugin]] to use [[dcraw]] as an input plugin, integrate [[TCA]] correction, modify [[enblend]] to write linear [[DNG]] (or create a standalone tiff2dng tool), modify hugin GUI to enable it, fix any [[ufraw]] bugs reading linear DNG.<br />
<br />
== hugin colour balancing ==<br />
<br />
''note: a grey picker has been implemented in Hugin 2011.0.0''<br />
<br />
Internally [[hugin]] uses the EMoR photometric model. This means that adjusting the colour balance in hugin by altering the red/blue channel multipliers will give better results than doing the same in an image editor such as the [[Gimp]]/[[Photoshop]] - Provided the photometric parameters for the camera are calibrated properly. There is potentially unexplored interesting stuff that can be done with this capability: grey pickers, temperature sliders, curve adjustment etc...<br />
<br />
<del>A related problem is that hugin has an internal 'lens' representation that it used to link lens parameters for different photos together, this capability really should be split into three models: '''lens''' grouping photos with the same lens but potentially different CCDs, '''sensor''' grouping photos with the same CCD but potentially different lenses, '''position''' stacked images that can be rotated together (see [[#bracketing pano model]] above) - This is tinkering with hugin fundamentals and needs to be overseen by Pablo.</del> ''Update: these backend changes were implemented as part of the GSoC2009 layout project''<br />
<br />
== Straight-line detection for automated lens calibration ==<br />
<br />
''Update: Note this was added as the calibrate_lens tool as part of GSoC 2009, already available in Hugin 2009.2.0, however picking this up and integrating it would be part of any 'lens database' project.''<br />
<br />
One of the techniques for lens calibration is to [http://hugin.sourceforge.net/tutorials/calibration/ optimise straight lines]. Tom Sharpless suggests: "Hugin needs an easy and reliable way to do straight line lens calibration. After many years using various calibration systems, photogrammetrists seem to have decided the straight line method is best. It is robust, accurate, and can often use naturally occurring straight lines rather than special calibration rigs. And it works well with fisheye lenses, which many other methods do not.<br />
<br />
The key is software that can automatically follow strong "line-like" curves and estimate their positions to subpixel accuracy. Then, using a reasonable model of the lens, an optimizer like the one in Hugin can fit parameters that straighten the lines. Since the raw images of calibration lines are generally curved, a human may have to designate which lines are straight in reality. However, fully automatic straight line calibration is theoretically possible, based on jointly optimizing lens parameters and estimated line shapes.<br />
<br />
A tool of this kind would be especially valuable for calibrating fisheye lenses, something the PanoTools family of s/w has always done poorly. Part of the problem is that the original PT library used the equal-angle model for fisheye lenses, instead of the equal-area model most modern fisheyes are actually designed to. Apparently libpano13 now has the equal-area model, too, but Hugin continues to use the equal-angle one. So an important part of this project could be to revise Hugin to handle fisheye lenses more correctly.<br />
<br />
== Simple mask editing ==<br />
<br />
''Update: Note this is complete and implemented separately from GSoC, it is available since Hugin 2010.2.0 and so can't be a SoC project''<br />
<br />
(note there was an automated masking project in 2008)<br />
<br />
Firstly there are two mask-editing scenarios and they are almost unrelated:<br />
<br />
# masking out objects that you don't want to appear in the scene.<br />
# masking to put one object in-front of another.<br />
<br />
Number 2 is never going to be done in hugin, this is a job for an image<br />
editor, feathered eraser brushes and clone tools. For this we really need<br />
some kind of multilayer output, and I would say that an enblend/enfuse Gimp<br />
plugin to merge these layers two at a time should be enough to make this work well (see above).<br />
<br />
(Note there is a 'layered' target in the Makefile.equirect.mk 'plugin'<br />
which does this multilayered TIFF output)<br />
<br />
The simplest way to provide number 1 is to change the crop tool into a<br />
polygon editor for masking the original images, and store the polygon<br />
coordinates in the 'i' lines of the .pto file - Masking would be performed<br />
at the remapping stage as it currently is for circular crops.<br />
<br />
This is conceptually very simple. At a later date the coordinates can be<br />
translated back and forth between the photo and panorama spaces, then<br />
automation of the mask can build on this.<br />
<br />
== Implementing a new projection model for the creation of mosaics in panotools ==<br />
<br />
''Update: this was a GSoC that failed in 2009, it has however been implemented outside of SoC and will be available in Hugin 2010.2.0.''<br />
<br />
Currently panotools implements a 3d spherical model for panorama projection. This means that it assumes that the camera rotates around its no-parallax-point from one frame to another. This model is perfectly good for making spherical panoramas.<br />
<br />
There is, however, another use of registration and stitching of photographs: mosaics. In this scenario the object to be captured is a flat plane (such as<br />
a wall, a aerial photograph, or partial scans of a larger work.<br />
<br />
This project will require to reverse engineer and document the current projection model, and propose<br />
and implement a new one. The panotools remapping infrastructure is very flexible and should be<br />
relatively straightforward to accomplish this.<br />
<br />
== zenith/nadir blending for enblend-enfuse ==<br />
<br />
Currently enblend-enfuse is not aware of the zenith/nadir seam in full spherical images. This sometimes results in star-like artifacts. Strategies have been devised to come around that limitation, such as re-projecting the concerned areas, blending them and merging them back. It would be nice if the code could do this automatically.<br />
<br />
== seam optimization in enblend-enfuse ==<br />
<br />
The seam optimization algorithm of enblend-enfuse can be improved. Andrew would be interested to mentor such a project.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2009_idea&diff=13341Historical:SoC 2009 idea2011-03-30T23:39:43Z<p>Bruno: /* hugin colour balancing */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2009, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2009_student_proposals | student proposal page]] - see examples from [[SoC_2008_student_proposals | last year]]<br />
<br />
'''IMPORTANT:''' at the time of writing it is not known yet if we will be admitted to Google Summer of Code 2009. We can not guarantee you a place in the program, but we recommend you start preparing your application early as the application process is very competitive.<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Mentors =<br />
<br />
The following people have volunteered to be primary mentors:<br />
* Andrew Mihal<br />
* Bruno Postle<br />
* Daniel M. German<br />
* Tom K. Sharpless<br />
* Tim Nugent<br />
* John Cupitt<br />
* Sébastien Roy<br />
<br />
The following people have volunteered to be secondary mentors:<br />
* Pablo d'Angelo<br />
* Jim Watters<br />
<br />
= Application Template =<br />
<br />
[[SoC2009 Application Template]]<br />
<br />
= Possible Projects =<br />
<br />
We welcome you to propose your own ideas.<br />
<br />
Some of the [[SoC2007 projects]] and [[SoC_2008_ideas | SoC2008 projects]] proposals were not done in the past years and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)</del> (chosen and completed in 2009 GSoC)<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
* [[SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI]]<br />
* [[SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more]]<br />
* <del>[[SoC_2008_ideas#Ghost_removal_for_enfuse]]</del> (done in 2009 GSoC)<br />
* [[SoC_2008_ideas#Lens_Database]] (the library part is done, see [[lensfun]], but there is still no system for updating the database)<br />
* <del>[[SoC_2008_ideas#tCA_Correction]]</del> (this is done, the [[tca_correct]] tool now exists in the hugin-0.7.0 release)<br />
* [[SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching]]<br />
* [[SoC_2008_ideas#Utility_for_creating_a_Philosphere]]<br />
<br />
== Python Bindings ==<br />
<br />
expose all functions / libraries as Python bindings<br />
<br />
== 3D extension of panotools library ==<br />
<br />
''Update Feb 2010: this is largely already completed with the 'mosaic' mode in Hugin 2010.1''<br />
<br />
the current assumption of panotools is that all images are shot from the same point of view in a different direction. develop and implement the mathematics to adjust for a shift in the point form which the pictures where taken.<br />
<br />
== enblend/enfuse gimp plugin ==<br />
<br />
Various GUIs for [[enblend]] and [[enfuse]] already exist (e.g. [http://www.harryvanderwolf.dyndns.org/index.php?lang=en&subject=ImageFuser&texttag=Imagefuser ImageFuser]), however nothing that would as useful as a gimp plugin. e.g. gimp opens multilayer TIFF files created by hugin and other tools, an option to 'blend visible layers with enblend' would allow manual adjustment of masks during blending.<br />
<br />
Note that there are standalone ImageFuser and ExpoBlending tools that provide GUIs for enfuse, these should give some idea of the options that need to be made available in a GIMP plugin. ExpoBlending is also a [http://www.digikam.org/drupal/node/494 Digikam plugin]. There are currently no enblend GUIs.<br />
<br />
== bracketing pano model ==<br />
<br />
''Update Feb 2010: this is already completed with the layout mode completed as part of GSoC 2009''<br />
<br />
Currently the Hugin pano model has no provision for brackets / stacked images. This project would modify the pano model to make provision for image stacks to be considered as a single image or to be optimized locally as a stack before being optimized globally as a panorama.<br />
<br />
== hugin RAW support ==<br />
<br />
(note this proposal needs to be checked for sanity by someone who understands RAW formats)<br />
<br />
[[hugin]] is never going to be a [[RAW]] converter with all the options of a tool such as [[ufraw]], so I would be wary of adding half-baked RAW support to hugin that produced second-rate results.<br />
<br />
Something that ought to work very well would be if hugin/[[enblend]] could support [[RAW]] output, specifically 'linear [[DNG]]'. In this workflow, hugin would import RAW via [[dcraw]] as [[16bit]] linear data with no correction. It would then output linear DNG files which could be opened in any RAW converter for further tweaking.<br />
<br />
This would be a good summer of code project: modify [[hugin]] to use [[dcraw]] as an input plugin, integrate [[TCA]] correction, modify [[enblend]] to write linear [[DNG]] (or create a standalone tiff2dng tool), modify hugin GUI to enable it, fix any [[ufraw]] bugs reading linear DNG.<br />
<br />
== hugin colour balancing ==<br />
<br />
''note: a grey picker has been implemented in Hugin 2011.0.0''<br />
<br />
Internally [[hugin]] uses the EMoR photometric model. This means that adjusting the colour balance in hugin by altering the red/blue channel multipliers will give better results than doing the same in an image editor such as the [[Gimp]]/[[Photoshop]] - Provided the photometric parameters for the camera are calibrated properly. There is potentially unexplored interesting stuff that can be done with this capability: grey pickers, temperature sliders, curve adjustment etc...<br />
<br />
<del>A related problem is that hugin has an internal 'lens' representation that it used to link lens parameters for different photos together, this capability really should be split into three models: '''lens''' grouping photos with the same lens but potentially different CCDs, '''sensor''' grouping photos with the same CCD but potentially different lenses, '''position''' stacked images that can be rotated together (see [[#bracketing pano model]] above) - This is tinkering with hugin fundamentals and needs to be overseen by Pablo.</del> ''Update: these backend changes were implemented as part of the GSoC2009 layout project''<br />
<br />
== Straight-line detection for automated lens calibration ==<br />
<br />
''Update: Note this was added as the calibrate_lens tool as part of GSoC 2009, already available in Hugin 2009.2.0, however picking this up and integrating it would be part of any 'lens database' project.''<br />
<br />
One of the techniques for lens calibration is to [http://hugin.sourceforge.net/tutorials/calibration/ optimise straight lines]. Tom Sharpless suggests: "Hugin needs an easy and reliable way to do straight line lens calibration. After many years using various calibration systems, photogrammetrists seem to have decided the straight line method is best. It is robust, accurate, and can often use naturally occurring straight lines rather than special calibration rigs. And it works well with fisheye lenses, which many other methods do not.<br />
<br />
The key is software that can automatically follow strong "line-like" curves and estimate their positions to subpixel accuracy. Then, using a reasonable model of the lens, an optimizer like the one in Hugin can fit parameters that straighten the lines. Since the raw images of calibration lines are generally curved, a human may have to designate which lines are straight in reality. However, fully automatic straight line calibration is theoretically possible, based on jointly optimizing lens parameters and estimated line shapes.<br />
<br />
A tool of this kind would be especially valuable for calibrating fisheye lenses, something the PanoTools family of s/w has always done poorly. Part of the problem is that the original PT library used the equal-angle model for fisheye lenses, instead of the equal-area model most modern fisheyes are actually designed to. Apparently libpano13 now has the equal-area model, too, but Hugin continues to use the equal-angle one. So an important part of this project could be to revise Hugin to handle fisheye lenses more correctly.<br />
<br />
== Simple mask editing ==<br />
<br />
''Update: Note this is complete in SVN and was implemented separately from GSoC, it will be available in Hugin 2010.2.0 and so can't be a SoC project''<br />
<br />
(note there was an automated masking project in 2008)<br />
<br />
Firstly there are two mask-editing scenarios and they are almost unrelated:<br />
<br />
# masking out objects that you don't want to appear in the scene.<br />
# masking to put one object in-front of another.<br />
<br />
Number 2 is never going to be done in hugin, this is a job for an image<br />
editor, feathered eraser brushes and clone tools. For this we really need<br />
some kind of multilayer output, and I would say that an enblend/enfuse Gimp<br />
plugin to merge these layers two at a time should be enough to make this work well (see above).<br />
<br />
(Note there is a 'layered' target in the Makefile.equirect.mk 'plugin'<br />
which does this multilayered TIFF output)<br />
<br />
The simplest way to provide number 1 is to change the crop tool into a<br />
polygon editor for masking the original images, and store the polygon<br />
coordinates in the 'i' lines of the .pto file - Masking would be performed<br />
at the remapping stage as it currently is for circular crops.<br />
<br />
This is conceptually very simple. At a later date the coordinates can be<br />
translated back and forth between the photo and panorama spaces, then<br />
automation of the mask can build on this.<br />
<br />
<br />
== Implementing a new projection model for the creation of mosaics in panotools ==<br />
<br />
''Update: this was a GSoC that failed in 2009, it has however been implemented outside of SoC and will be available in Hugin 2010.2.0.''<br />
<br />
Currently panotools implements a 3d spherical model for panorama projection. This means that it assumes that the camera rotates around its no-parallax-point from one frame to another. This model is perfectly good for making spherical panoramas.<br />
<br />
There is, however, another use of registration and stitching of photographs: mosaics. In this scenario the object to be captured is a flat plane (such as<br />
a wall, a aerial photograph, or partial scans of a larger work.<br />
<br />
This project will require to reverse engineer and document the current projection model, and propose<br />
and implement a new one. The panotools remapping infrastructure is very flexible and should be<br />
relatively straightforward to accomplish this.<br />
<br />
== zenith/nadir blending for enblend-enfuse ==<br />
<br />
Currently enblend-enfuse is not aware of the zenith/nadir seam in full spherical images. This sometimes results in star-like artifacts. Strategies have been devised to come around that limitation, such as re-projecting the concerned areas, blending them and merging them back. It would be nice if the code could do this automatically.<br />
<br />
== seam optimization in enblend-enfuse ==<br />
<br />
The seam optimization algorithm of enblend-enfuse can be improved. Andrew would be interested to mentor such a project.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_ideas&diff=13340Historical:SoC 2008 ideas2011-03-30T23:37:58Z<p>Bruno: /* Extend hugin's output options for stitching */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2008, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2008_student_proposals | student proposal page]]<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
Some of the [[SoC2007 projects]] proposals were not done last year and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Automatic feature matching for panoramic images]]</del> Completed<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done)</del> Completed in GSoC 2009<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
<br />
== munin — interactive openGL based GUI ==<br />
<br />
''note 2011: the opengl preview has since been implemented in Hugin. Hugin now has an experimental python interface, so this project is relevant again''<br />
<br />
(Note that [http://munin.projects.linpro.no/ munin] is a popular open source graphing tool for network administrators, so this name isn't really usable)<br />
<br />
'''Possible Mentors''':<br />
<br />
* Pablo<br />
<br />
'''Description''':<br />
<br />
Intuitive and interactive GUI, with priority in usability over available features and flexibility, based on what users should see — not on what software does internally. To there are two roads for this:<br />
<br />
1. Create bindings to the core hugin library to a high level scripting language such as python, ruby or maybe lua. Use these to write the GUI.<br />
2. Use the core libary directly and write the GUI in C++. While this might be easier from the start, a GUI written in a scripting<br />
language has major benefits for the long term (rapid development, extensibility etc.).<br />
<br />
It would be nice to have a preview/renderer in OpenGL, but I fear that a new GUI and OpenGL acceleration is too big for a single GSOC project. If you are an experienced developer (know and have used all the required technology on non-trivial projects) it might be possible though.<br />
<br />
'''Skills''':<br />
<br />
* C++<br />
* Scripting language (python, ruby, lua?)<br />
* Qt4<br />
* OpenGL<br />
<br />
'''Discussion''':<br />
<br />
how about relaxing the skills, and instead of fixing on Qt4 work on a combination of high level scripting language and widgets? Phythons + wxWidgets or Lua + wxWidgets come to my mind. Right now we have the option as both wxWidgets and Qt are in trunk, and if the student codes those widgets that require speed in OpenGL so that they integrate into such an API, any scripter can then leverage them for the fast and efficient design of GUI. [[User:Yuval|Yuval]] 12:50, 4 March 2008 (CET)<br />
<br />
I think the GUI + OpenGL is a bit too much for a single project. A separate project for OpenGL acceleration would make more sense, I fear. I'd really like to see a scripting language interface to the hugin core library.<br />
<small>--[[User:Pablo|pablo]] 08:47, 19 March 2008 (CET)</small><br />
<br />
== enblend-enfuse zenith/nadir and more ==<br />
<br />
'''Primary Mentor'''<br />
<br />
Andrew Mihal<br />
<br />
'''Description'''<br />
<br />
* implementing blending of the zenith and nadir in Enblend and Enfuse<br />
*:The best way I can think of to do this is to use a cubic projection and provide all cube faces to the tool simultaneously. All of the boundaries will be horizontal or vertical lines, which will fit in well with the SKIPSM-based pyramid algorithms currently in use. Enblend and Enfuse can share the same pyramid code.<br />
* Enblend would additionally need a nearest feature transform algorithm that works on the cube surface for mask generation. I am not aware of a published algorithm to solve this.<br />
* Improve the seam optimization algorithm in Enblend.<br />
* GUI hooks: an API to a higher anstraction level language such as Python+wxWidgets or Lua+wxWidgets, with a real time interface into the enfuse functionality so that when changing weights with a sliders a preview can be generated in near real time. <br />
* multi-step fusing and alternative, user controlled, weighting (sigma).<br />
<br />
'''Skills'''<br />
<br />
'''Admission Test'''<br />
<br />
A potential applicant for this project should first try to add boundary conditions to the localVarianceIf function in enfuse.h.<br />
<br />
== OpenGL accelerated hugin preview ==<br />
<br />
''Update: This was completed as part of GSoC 2008 'fast preview' and has been available since Hugin 0.8.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
There is a nice proof of concept for this idea created as a [http://vision.eng.shu.ac.uk/mmvlwiki/index.php/Panorama_Viewer student project at Hallam University].<br />
<br />
'''Skills'''<br />
<br />
== Ghost removal for enfuse ==<br />
<br />
''Update: This was completed as part of GSoC 2009 and will be available in Hugin 2010.0'' <br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Thanks to [[SoC2007 project Anti Ghosting]], hugin has ghost removal when merging [[Bracketing|bracketed]] series to [[HDR]], but this isn't currently available for [[enfuse]].<br />
<br />
'''Skills'''<br />
<br />
== Masking in GUI ==<br />
<br />
''Update: This has been completed independently of GSoC and will be available with Hugin 2010.2.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Currently masking to remove unwanted objects from panoramas has to be added to alpha channels which is laborious, this could be integrated into the hugin GUI via a simple vector/polygon editor. It would need to be simpler to use than the [http://hugin.sourceforge.net/tutorials/enblend-svg/ equivalent process with Inkscape]<br />
<br />
'''Skills'''<br />
<br />
== Batch processing ==<br />
<br />
''Update: This was completed in GSoC 2008 and has been available since Hugin 0.8.0. However there is still no GUI system for batch processing the creation of Hugin projects''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
[[SoC2007 project Batch Processing]] was an unadopted project last year.<br />
<br />
Now that hugin has a Makefile based stitching process, it is much clearer what a batch stitcher would look like. This would need to support 'plug-in' Makefile add-ons for additional views, QTVR generation, uploading, sharpening etc... as well as a queue/spool manager.<br />
<br />
Some explanation of this existing 'Makefile process': Currently hugin stitches projects by writing out the instructions (remapping and blending with nona, enblend, enfuse, exiftool etc...) into a standard Makefile and then running 'make -f project.pto.mk all clean' - This happens all in one go when a user clicks 'save and stitch', but alternatively the user has a choice to run 'make' manually.<br />
<br />
So batch processing already exists for users familiar with the command-line, ie. we can run 'make -j 16' to run processes in parallel or use a tool such as [http://distmake.sourceforge.net/pmwiki/pmwiki.php distmake] to queue jobs over the network on multiple machines.<br />
<br />
A plugin system also already exists to a certain extent in that these Makefiles can be extended with other makefiles that add additional targets, one for creating QTVR output is described [http://thread.gmane.org/gmane.comp.misc.ptx/8754 here].<br />
<br />
A batch stitcher would need to enable some or all of this functionality for normal users who have an interest in photography rather than tinkering with script files.<br />
<br />
'''Skills'''<br />
<br />
== Lens Database ==<br />
<br />
''note 2011: the lens database now exists as [[lensfun]] which is mature and in use by ufraw and rawstudio, Hugin still hasn't implemented lensfun support and could potentially be used to collect and submit 'good' lens parameters. note also calibrate_lens was created in GSoC 2009 which can also be used in this project''<br />
<br />
'''Primary mentor'''<br />
<br />
Alexandre Jenny<br />
<br />
'''Discussion'''<br />
<br />
Lens database of accumulated knowledge on distortion, CA, response curve.<br />
The lens database aim : using stitching to feed an huge camera / lens database for distortion correction, vignetting correction, ca, etc. Then, it will be possible to reuse this database to correct single pictures too.<br />
<br />
There are two ways to generate such a database:<br />
<br />
# Collect high quality photographs centrally, manually calibrate them and assemble a database that matches parameters with image EXIF data - This is how the [[PTLens]] database was collected.<br />
# Use the fact that stitching software (eg hugin, but there are other tools using the same lens correction model) effectively calibrates lenses every time a project is stitched - This information could be collected, validated and averaged centrally to automate the creation of a lens database.<br />
<br />
This project would investigate the second technique. It can be divided into several subparts which are independent. <br />
First part theory :<br />
* Distortion parameters accumulation : what measure is important, what can be such a measure reproduced, what criterion should be use in a stitch to be sure that the optimized parameters are good for the database.<br />
* CA : find a reproducible way to measure it. Study the variation of the CA with zoom parameters ( varying with aperture ? with focal ? )<br />
* response curve : this parameter is less dependent on the lens, it's more sensor / maker related.<br />
<br />
Second part : statistic accumulation<br />
* design a standard format to store every parameter,<br />
* create and manage a central repository of lens database.<br />
<br />
'''Skills'''<br />
<br />
General : in computer vision field<br />
Coding : C / C++ / stl<br />
Math : optimizing technics<br />
<br />
== tCA Correction ==<br />
<br />
''Update: tca_correct has been implemented independently of GSoC and has been available since Hugin 0.7.0, however there is no GUI. note that tca_correct is slow and speeding it up and integrating it with the GUI and stitching with nona would be very useful''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
An utility to determining the Transverse Chromatic Aberration (tCA) of an image so it can be corrected.<br />
<br />
CA is when the color channels in an image do not appear to line up well with each other. tCA is when colors are in focus but placed adjacent to each other. tCA can be corrected with Panorama Tool's Radial Shift. More info on [[Chromatic aberration]]<br />
<br />
Correcting tCA using PanoTools' Radial Shift, requires knowing the radial correction coefficients a, b and c for your lens. PTOptimizer can be used to calculate the coefficients if known amounts of shift for each channel is known from the center to the corners of the image.<br />
<br />
This utility will produce these coefficients to be used in the lens database.<br />
<br />
Assume image is 180 deg diagonal filed of view. Regardless if it is rectangular or fisheye of any field of view. Map image to the nadir of a sphere, taking into account any offset from center of image.<br />
<br />
The bottom of the remapped image is the center of the original. Moving up the remapped image is the same as moving away from the center of the original image.<br />
<br />
Now we no longer have to deal with radial shift but vertical shift. The image can be divided into a number of strips going across the entire width of the image. Each strip represents a circle a different distance from the center. The strips are shifted up and down the same amount over the entire image width. Each strip can have the channel data adjusted up and down to find the best match to eliminate CAt at that position. One channel does not move while the other two are adjusted. The best result of the two channels are recored for every strip. Sub pixel accuracy can be achieved by increasing the height of the result when creating the remapped image.<br />
<br />
This can be done manually in real-time giving visual feedback of the channels alignment. Or it can be done programmability doing a difference between the two channels and looking at the histogram. The blackest result has the best alignment. If accurate automated results are possible then there is no need for the manual method.<br />
<br />
Current methods of correcting [http://hugin.sourceforge.net/tutorials/tca/en.shtml tCA] are fairly complicated. Though it can be [http://thread.gmane.org/gmane.comp.misc.ptx/8183/focus=8236 completely automated] using a patched version of [[align_image_stack]] from the [[hugin]] project, this technique works very well but could use some optimisation work to make it faster (and the align_image_stack patch needs integrating).<br />
<br />
Also according to [http://lists.freedesktop.org/archives/create/2008-February/001093.html this post] by the author of ufraw, the tCA correction in the latest [[dcraw]] is done before bayer interpolation (note that my interpretation of this code was the opposite , so what do I know - [[User:Bruno|Bruno]]). This tool should also create parameters for use by dcraw.<br />
<br />
== Extend hugin's output options for stitching ==<br />
<br />
''update: tiffcp can be used for assembling multi-layer TIFF files, however there would be some value to adding native PSD/PSB support to vigra which is the library used by both Hugin and enblend for image file IO''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Currently hugin offers jpg, png, tiff and layered tiff output. Suggested are other formats like layered psd; swf , java and html generation for web publishing. Despite of all software projects efforts, stitched panoramas have some errors (like ghost objects) that can be easily removed in Photoshop or Gimp with layered output. A lot of open source graphical software already offers proposed file formats, but despite it is not an easy task that can be implemented in a week and therefore it is suitable to be a standalone SoC project<br />
<br />
Note that this is potentially complimentary and orthogonal to the ''batch stitching'' project described above, Makefiles are a good way to provide additional output types and quite suitable for HTML generation or even uploading.<br />
<br />
hugin and other tools generate [[Cropped TIFF]] files, with each 'layer' as a separate file. The workflow described above for using this data in image editors really requires file formats that contain all layers in a single file such as ''multilayer TIFF'' or [[PSD]]. Command-line tools for assembling these files are currently either too buggy to use or non-existent and fixing this situation would be a good project in itself.<br />
<br />
'''Skills'''<br />
<br />
== Utility for creating a Philosphere ==<br />
<br />
''update: note that during the proposal stage this project was discarded as being too small, also mathmap is a better tool for implementing this kind of thing''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Goal: A utility integrated into hugin for creating images from panoramas, suitable for printing.<br />
<br />
Tasks:<br />
* Implementation of described process using modified PT scripts and them combining partial results to final image<br />
* Integration into hugin<br />
<br />
Discussion:<br />
There are several possible outputs that can be used to print a panorama. Examples: polyhedron, "orange slices", rhombicuboctahedron...<br />
<br />
Resources:<br />
* http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm<br />
* [[PTStitcher]]<br />
* [http://www.flickr.com/photos/sbprzd/tags/foldable/ experiments with mathmap] by [[User:Seb Przd]] - Particularly note the 'conformal cube'.<br />
<br />
'''Skills'''<br />
<br />
Required knowledge or interest in:<br />
* panoramic imaging<br />
* C++ and scripting languages development skills.<br />
<br />
== Sky identification ==<br />
<br />
''Update: this was completed as part of GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
Feature matching tools have a tendency to identify potentially useful features in clouds, this is not surprising given the amount of useful contrast and detail in a typical cloud.<br />
<br />
This tendency is problematic when matching images for panorama stitching, as clouds can move significant distances even between photos taken seconds apart.<br />
<br />
This project would find a suitable method of identifying areas of sky based on a search of existing literature, and implement it as a standalone tool capable of pruning [[Control points]] from existing panotools/hugin format script files.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_ideas&diff=13339Historical:SoC 2008 ideas2011-03-30T23:35:40Z<p>Bruno: /* tCA Correction */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2008, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2008_student_proposals | student proposal page]]<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
Some of the [[SoC2007 projects]] proposals were not done last year and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Automatic feature matching for panoramic images]]</del> Completed<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done)</del> Completed in GSoC 2009<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
<br />
== munin — interactive openGL based GUI ==<br />
<br />
''note 2011: the opengl preview has since been implemented in Hugin. Hugin now has an experimental python interface, so this project is relevant again''<br />
<br />
(Note that [http://munin.projects.linpro.no/ munin] is a popular open source graphing tool for network administrators, so this name isn't really usable)<br />
<br />
'''Possible Mentors''':<br />
<br />
* Pablo<br />
<br />
'''Description''':<br />
<br />
Intuitive and interactive GUI, with priority in usability over available features and flexibility, based on what users should see — not on what software does internally. To there are two roads for this:<br />
<br />
1. Create bindings to the core hugin library to a high level scripting language such as python, ruby or maybe lua. Use these to write the GUI.<br />
2. Use the core libary directly and write the GUI in C++. While this might be easier from the start, a GUI written in a scripting<br />
language has major benefits for the long term (rapid development, extensibility etc.).<br />
<br />
It would be nice to have a preview/renderer in OpenGL, but I fear that a new GUI and OpenGL acceleration is too big for a single GSOC project. If you are an experienced developer (know and have used all the required technology on non-trivial projects) it might be possible though.<br />
<br />
'''Skills''':<br />
<br />
* C++<br />
* Scripting language (python, ruby, lua?)<br />
* Qt4<br />
* OpenGL<br />
<br />
'''Discussion''':<br />
<br />
how about relaxing the skills, and instead of fixing on Qt4 work on a combination of high level scripting language and widgets? Phythons + wxWidgets or Lua + wxWidgets come to my mind. Right now we have the option as both wxWidgets and Qt are in trunk, and if the student codes those widgets that require speed in OpenGL so that they integrate into such an API, any scripter can then leverage them for the fast and efficient design of GUI. [[User:Yuval|Yuval]] 12:50, 4 March 2008 (CET)<br />
<br />
I think the GUI + OpenGL is a bit too much for a single project. A separate project for OpenGL acceleration would make more sense, I fear. I'd really like to see a scripting language interface to the hugin core library.<br />
<small>--[[User:Pablo|pablo]] 08:47, 19 March 2008 (CET)</small><br />
<br />
== enblend-enfuse zenith/nadir and more ==<br />
<br />
'''Primary Mentor'''<br />
<br />
Andrew Mihal<br />
<br />
'''Description'''<br />
<br />
* implementing blending of the zenith and nadir in Enblend and Enfuse<br />
*:The best way I can think of to do this is to use a cubic projection and provide all cube faces to the tool simultaneously. All of the boundaries will be horizontal or vertical lines, which will fit in well with the SKIPSM-based pyramid algorithms currently in use. Enblend and Enfuse can share the same pyramid code.<br />
* Enblend would additionally need a nearest feature transform algorithm that works on the cube surface for mask generation. I am not aware of a published algorithm to solve this.<br />
* Improve the seam optimization algorithm in Enblend.<br />
* GUI hooks: an API to a higher anstraction level language such as Python+wxWidgets or Lua+wxWidgets, with a real time interface into the enfuse functionality so that when changing weights with a sliders a preview can be generated in near real time. <br />
* multi-step fusing and alternative, user controlled, weighting (sigma).<br />
<br />
'''Skills'''<br />
<br />
'''Admission Test'''<br />
<br />
A potential applicant for this project should first try to add boundary conditions to the localVarianceIf function in enfuse.h.<br />
<br />
== OpenGL accelerated hugin preview ==<br />
<br />
''Update: This was completed as part of GSoC 2008 'fast preview' and has been available since Hugin 0.8.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
There is a nice proof of concept for this idea created as a [http://vision.eng.shu.ac.uk/mmvlwiki/index.php/Panorama_Viewer student project at Hallam University].<br />
<br />
'''Skills'''<br />
<br />
== Ghost removal for enfuse ==<br />
<br />
''Update: This was completed as part of GSoC 2009 and will be available in Hugin 2010.0'' <br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Thanks to [[SoC2007 project Anti Ghosting]], hugin has ghost removal when merging [[Bracketing|bracketed]] series to [[HDR]], but this isn't currently available for [[enfuse]].<br />
<br />
'''Skills'''<br />
<br />
== Masking in GUI ==<br />
<br />
''Update: This has been completed independently of GSoC and will be available with Hugin 2010.2.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Currently masking to remove unwanted objects from panoramas has to be added to alpha channels which is laborious, this could be integrated into the hugin GUI via a simple vector/polygon editor. It would need to be simpler to use than the [http://hugin.sourceforge.net/tutorials/enblend-svg/ equivalent process with Inkscape]<br />
<br />
'''Skills'''<br />
<br />
== Batch processing ==<br />
<br />
''Update: This was completed in GSoC 2008 and has been available since Hugin 0.8.0. However there is still no GUI system for batch processing the creation of Hugin projects''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
[[SoC2007 project Batch Processing]] was an unadopted project last year.<br />
<br />
Now that hugin has a Makefile based stitching process, it is much clearer what a batch stitcher would look like. This would need to support 'plug-in' Makefile add-ons for additional views, QTVR generation, uploading, sharpening etc... as well as a queue/spool manager.<br />
<br />
Some explanation of this existing 'Makefile process': Currently hugin stitches projects by writing out the instructions (remapping and blending with nona, enblend, enfuse, exiftool etc...) into a standard Makefile and then running 'make -f project.pto.mk all clean' - This happens all in one go when a user clicks 'save and stitch', but alternatively the user has a choice to run 'make' manually.<br />
<br />
So batch processing already exists for users familiar with the command-line, ie. we can run 'make -j 16' to run processes in parallel or use a tool such as [http://distmake.sourceforge.net/pmwiki/pmwiki.php distmake] to queue jobs over the network on multiple machines.<br />
<br />
A plugin system also already exists to a certain extent in that these Makefiles can be extended with other makefiles that add additional targets, one for creating QTVR output is described [http://thread.gmane.org/gmane.comp.misc.ptx/8754 here].<br />
<br />
A batch stitcher would need to enable some or all of this functionality for normal users who have an interest in photography rather than tinkering with script files.<br />
<br />
'''Skills'''<br />
<br />
== Lens Database ==<br />
<br />
''note 2011: the lens database now exists as [[lensfun]] which is mature and in use by ufraw and rawstudio, Hugin still hasn't implemented lensfun support and could potentially be used to collect and submit 'good' lens parameters. note also calibrate_lens was created in GSoC 2009 which can also be used in this project''<br />
<br />
'''Primary mentor'''<br />
<br />
Alexandre Jenny<br />
<br />
'''Discussion'''<br />
<br />
Lens database of accumulated knowledge on distortion, CA, response curve.<br />
The lens database aim : using stitching to feed an huge camera / lens database for distortion correction, vignetting correction, ca, etc. Then, it will be possible to reuse this database to correct single pictures too.<br />
<br />
There are two ways to generate such a database:<br />
<br />
# Collect high quality photographs centrally, manually calibrate them and assemble a database that matches parameters with image EXIF data - This is how the [[PTLens]] database was collected.<br />
# Use the fact that stitching software (eg hugin, but there are other tools using the same lens correction model) effectively calibrates lenses every time a project is stitched - This information could be collected, validated and averaged centrally to automate the creation of a lens database.<br />
<br />
This project would investigate the second technique. It can be divided into several subparts which are independent. <br />
First part theory :<br />
* Distortion parameters accumulation : what measure is important, what can be such a measure reproduced, what criterion should be use in a stitch to be sure that the optimized parameters are good for the database.<br />
* CA : find a reproducible way to measure it. Study the variation of the CA with zoom parameters ( varying with aperture ? with focal ? )<br />
* response curve : this parameter is less dependent on the lens, it's more sensor / maker related.<br />
<br />
Second part : statistic accumulation<br />
* design a standard format to store every parameter,<br />
* create and manage a central repository of lens database.<br />
<br />
'''Skills'''<br />
<br />
General : in computer vision field<br />
Coding : C / C++ / stl<br />
Math : optimizing technics<br />
<br />
== tCA Correction ==<br />
<br />
''Update: tca_correct has been implemented independently of GSoC and has been available since Hugin 0.7.0, however there is no GUI. note that tca_correct is slow and speeding it up and integrating it with the GUI and stitching with nona would be very useful''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
An utility to determining the Transverse Chromatic Aberration (tCA) of an image so it can be corrected.<br />
<br />
CA is when the color channels in an image do not appear to line up well with each other. tCA is when colors are in focus but placed adjacent to each other. tCA can be corrected with Panorama Tool's Radial Shift. More info on [[Chromatic aberration]]<br />
<br />
Correcting tCA using PanoTools' Radial Shift, requires knowing the radial correction coefficients a, b and c for your lens. PTOptimizer can be used to calculate the coefficients if known amounts of shift for each channel is known from the center to the corners of the image.<br />
<br />
This utility will produce these coefficients to be used in the lens database.<br />
<br />
Assume image is 180 deg diagonal filed of view. Regardless if it is rectangular or fisheye of any field of view. Map image to the nadir of a sphere, taking into account any offset from center of image.<br />
<br />
The bottom of the remapped image is the center of the original. Moving up the remapped image is the same as moving away from the center of the original image.<br />
<br />
Now we no longer have to deal with radial shift but vertical shift. The image can be divided into a number of strips going across the entire width of the image. Each strip represents a circle a different distance from the center. The strips are shifted up and down the same amount over the entire image width. Each strip can have the channel data adjusted up and down to find the best match to eliminate CAt at that position. One channel does not move while the other two are adjusted. The best result of the two channels are recored for every strip. Sub pixel accuracy can be achieved by increasing the height of the result when creating the remapped image.<br />
<br />
This can be done manually in real-time giving visual feedback of the channels alignment. Or it can be done programmability doing a difference between the two channels and looking at the histogram. The blackest result has the best alignment. If accurate automated results are possible then there is no need for the manual method.<br />
<br />
Current methods of correcting [http://hugin.sourceforge.net/tutorials/tca/en.shtml tCA] are fairly complicated. Though it can be [http://thread.gmane.org/gmane.comp.misc.ptx/8183/focus=8236 completely automated] using a patched version of [[align_image_stack]] from the [[hugin]] project, this technique works very well but could use some optimisation work to make it faster (and the align_image_stack patch needs integrating).<br />
<br />
Also according to [http://lists.freedesktop.org/archives/create/2008-February/001093.html this post] by the author of ufraw, the tCA correction in the latest [[dcraw]] is done before bayer interpolation (note that my interpretation of this code was the opposite , so what do I know - [[User:Bruno|Bruno]]). This tool should also create parameters for use by dcraw.<br />
<br />
== Extend hugin's output options for stitching ==<br />
<br />
''Note this project would need to be complementary to any work done on [[SoC_2010_ideas#Makefile_system_and_Detection_of_panoramas]]. i.e. the framework for creating it doesn't yet exist.''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Currently hugin offers jpg, png, tiff and layered tiff output. Suggested are other formats like layered psd; swf , java and html generation for web publishing. Despite of all software projects efforts, stitched panoramas have some errors (like ghost objects) that can be easily removed in Photoshop or Gimp with layered output. A lot of open source graphical software already offers proposed file formats, but despite it is not an easy task that can be implemented in a week and therefore it is suitable to be a standalone SoC project<br />
<br />
Note that this is potentially complimentary and orthogonal to the ''batch stitching'' project described above, Makefiles are a good way to provide additional output types and quite suitable for HTML generation or even uploading.<br />
<br />
hugin and other tools generate [[Cropped TIFF]] files, with each 'layer' as a separate file. The workflow described above for using this data in image editors really requires file formats that contain all layers in a single file such as ''multilayer TIFF'' or [[PSD]]. Command-line tools for assembling these files are currently either too buggy to use or non-existent and fixing this situation would be a good project in itself.<br />
<br />
'''Skills'''<br />
<br />
== Utility for creating a Philosphere ==<br />
<br />
''update: note that during the proposal stage this project was discarded as being too small, also mathmap is a better tool for implementing this kind of thing''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Goal: A utility integrated into hugin for creating images from panoramas, suitable for printing.<br />
<br />
Tasks:<br />
* Implementation of described process using modified PT scripts and them combining partial results to final image<br />
* Integration into hugin<br />
<br />
Discussion:<br />
There are several possible outputs that can be used to print a panorama. Examples: polyhedron, "orange slices", rhombicuboctahedron...<br />
<br />
Resources:<br />
* http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm<br />
* [[PTStitcher]]<br />
* [http://www.flickr.com/photos/sbprzd/tags/foldable/ experiments with mathmap] by [[User:Seb Przd]] - Particularly note the 'conformal cube'.<br />
<br />
'''Skills'''<br />
<br />
Required knowledge or interest in:<br />
* panoramic imaging<br />
* C++ and scripting languages development skills.<br />
<br />
== Sky identification ==<br />
<br />
''Update: this was completed as part of GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
Feature matching tools have a tendency to identify potentially useful features in clouds, this is not surprising given the amount of useful contrast and detail in a typical cloud.<br />
<br />
This tendency is problematic when matching images for panorama stitching, as clouds can move significant distances even between photos taken seconds apart.<br />
<br />
This project would find a suitable method of identifying areas of sky based on a search of existing literature, and implement it as a standalone tool capable of pruning [[Control points]] from existing panotools/hugin format script files.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_ideas&diff=13338Historical:SoC 2008 ideas2011-03-30T23:33:57Z<p>Bruno: /* Lens Database */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2008, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2008_student_proposals | student proposal page]]<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
Some of the [[SoC2007 projects]] proposals were not done last year and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Automatic feature matching for panoramic images]]</del> Completed<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done)</del> Completed in GSoC 2009<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
<br />
== munin — interactive openGL based GUI ==<br />
<br />
''note 2011: the opengl preview has since been implemented in Hugin. Hugin now has an experimental python interface, so this project is relevant again''<br />
<br />
(Note that [http://munin.projects.linpro.no/ munin] is a popular open source graphing tool for network administrators, so this name isn't really usable)<br />
<br />
'''Possible Mentors''':<br />
<br />
* Pablo<br />
<br />
'''Description''':<br />
<br />
Intuitive and interactive GUI, with priority in usability over available features and flexibility, based on what users should see — not on what software does internally. To there are two roads for this:<br />
<br />
1. Create bindings to the core hugin library to a high level scripting language such as python, ruby or maybe lua. Use these to write the GUI.<br />
2. Use the core libary directly and write the GUI in C++. While this might be easier from the start, a GUI written in a scripting<br />
language has major benefits for the long term (rapid development, extensibility etc.).<br />
<br />
It would be nice to have a preview/renderer in OpenGL, but I fear that a new GUI and OpenGL acceleration is too big for a single GSOC project. If you are an experienced developer (know and have used all the required technology on non-trivial projects) it might be possible though.<br />
<br />
'''Skills''':<br />
<br />
* C++<br />
* Scripting language (python, ruby, lua?)<br />
* Qt4<br />
* OpenGL<br />
<br />
'''Discussion''':<br />
<br />
how about relaxing the skills, and instead of fixing on Qt4 work on a combination of high level scripting language and widgets? Phythons + wxWidgets or Lua + wxWidgets come to my mind. Right now we have the option as both wxWidgets and Qt are in trunk, and if the student codes those widgets that require speed in OpenGL so that they integrate into such an API, any scripter can then leverage them for the fast and efficient design of GUI. [[User:Yuval|Yuval]] 12:50, 4 March 2008 (CET)<br />
<br />
I think the GUI + OpenGL is a bit too much for a single project. A separate project for OpenGL acceleration would make more sense, I fear. I'd really like to see a scripting language interface to the hugin core library.<br />
<small>--[[User:Pablo|pablo]] 08:47, 19 March 2008 (CET)</small><br />
<br />
== enblend-enfuse zenith/nadir and more ==<br />
<br />
'''Primary Mentor'''<br />
<br />
Andrew Mihal<br />
<br />
'''Description'''<br />
<br />
* implementing blending of the zenith and nadir in Enblend and Enfuse<br />
*:The best way I can think of to do this is to use a cubic projection and provide all cube faces to the tool simultaneously. All of the boundaries will be horizontal or vertical lines, which will fit in well with the SKIPSM-based pyramid algorithms currently in use. Enblend and Enfuse can share the same pyramid code.<br />
* Enblend would additionally need a nearest feature transform algorithm that works on the cube surface for mask generation. I am not aware of a published algorithm to solve this.<br />
* Improve the seam optimization algorithm in Enblend.<br />
* GUI hooks: an API to a higher anstraction level language such as Python+wxWidgets or Lua+wxWidgets, with a real time interface into the enfuse functionality so that when changing weights with a sliders a preview can be generated in near real time. <br />
* multi-step fusing and alternative, user controlled, weighting (sigma).<br />
<br />
'''Skills'''<br />
<br />
'''Admission Test'''<br />
<br />
A potential applicant for this project should first try to add boundary conditions to the localVarianceIf function in enfuse.h.<br />
<br />
== OpenGL accelerated hugin preview ==<br />
<br />
''Update: This was completed as part of GSoC 2008 'fast preview' and has been available since Hugin 0.8.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
There is a nice proof of concept for this idea created as a [http://vision.eng.shu.ac.uk/mmvlwiki/index.php/Panorama_Viewer student project at Hallam University].<br />
<br />
'''Skills'''<br />
<br />
== Ghost removal for enfuse ==<br />
<br />
''Update: This was completed as part of GSoC 2009 and will be available in Hugin 2010.0'' <br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Thanks to [[SoC2007 project Anti Ghosting]], hugin has ghost removal when merging [[Bracketing|bracketed]] series to [[HDR]], but this isn't currently available for [[enfuse]].<br />
<br />
'''Skills'''<br />
<br />
== Masking in GUI ==<br />
<br />
''Update: This has been completed independently of GSoC and will be available with Hugin 2010.2.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Currently masking to remove unwanted objects from panoramas has to be added to alpha channels which is laborious, this could be integrated into the hugin GUI via a simple vector/polygon editor. It would need to be simpler to use than the [http://hugin.sourceforge.net/tutorials/enblend-svg/ equivalent process with Inkscape]<br />
<br />
'''Skills'''<br />
<br />
== Batch processing ==<br />
<br />
''Update: This was completed in GSoC 2008 and has been available since Hugin 0.8.0. However there is still no GUI system for batch processing the creation of Hugin projects''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
[[SoC2007 project Batch Processing]] was an unadopted project last year.<br />
<br />
Now that hugin has a Makefile based stitching process, it is much clearer what a batch stitcher would look like. This would need to support 'plug-in' Makefile add-ons for additional views, QTVR generation, uploading, sharpening etc... as well as a queue/spool manager.<br />
<br />
Some explanation of this existing 'Makefile process': Currently hugin stitches projects by writing out the instructions (remapping and blending with nona, enblend, enfuse, exiftool etc...) into a standard Makefile and then running 'make -f project.pto.mk all clean' - This happens all in one go when a user clicks 'save and stitch', but alternatively the user has a choice to run 'make' manually.<br />
<br />
So batch processing already exists for users familiar with the command-line, ie. we can run 'make -j 16' to run processes in parallel or use a tool such as [http://distmake.sourceforge.net/pmwiki/pmwiki.php distmake] to queue jobs over the network on multiple machines.<br />
<br />
A plugin system also already exists to a certain extent in that these Makefiles can be extended with other makefiles that add additional targets, one for creating QTVR output is described [http://thread.gmane.org/gmane.comp.misc.ptx/8754 here].<br />
<br />
A batch stitcher would need to enable some or all of this functionality for normal users who have an interest in photography rather than tinkering with script files.<br />
<br />
'''Skills'''<br />
<br />
== Lens Database ==<br />
<br />
''note 2011: the lens database now exists as [[lensfun]] which is mature and in use by ufraw and rawstudio, Hugin still hasn't implemented lensfun support and could potentially be used to collect and submit 'good' lens parameters. note also calibrate_lens was created in GSoC 2009 which can also be used in this project''<br />
<br />
'''Primary mentor'''<br />
<br />
Alexandre Jenny<br />
<br />
'''Discussion'''<br />
<br />
Lens database of accumulated knowledge on distortion, CA, response curve.<br />
The lens database aim : using stitching to feed an huge camera / lens database for distortion correction, vignetting correction, ca, etc. Then, it will be possible to reuse this database to correct single pictures too.<br />
<br />
There are two ways to generate such a database:<br />
<br />
# Collect high quality photographs centrally, manually calibrate them and assemble a database that matches parameters with image EXIF data - This is how the [[PTLens]] database was collected.<br />
# Use the fact that stitching software (eg hugin, but there are other tools using the same lens correction model) effectively calibrates lenses every time a project is stitched - This information could be collected, validated and averaged centrally to automate the creation of a lens database.<br />
<br />
This project would investigate the second technique. It can be divided into several subparts which are independent. <br />
First part theory :<br />
* Distortion parameters accumulation : what measure is important, what can be such a measure reproduced, what criterion should be use in a stitch to be sure that the optimized parameters are good for the database.<br />
* CA : find a reproducible way to measure it. Study the variation of the CA with zoom parameters ( varying with aperture ? with focal ? )<br />
* response curve : this parameter is less dependent on the lens, it's more sensor / maker related.<br />
<br />
Second part : statistic accumulation<br />
* design a standard format to store every parameter,<br />
* create and manage a central repository of lens database.<br />
<br />
'''Skills'''<br />
<br />
General : in computer vision field<br />
Coding : C / C++ / stl<br />
Math : optimizing technics<br />
<br />
== tCA Correction ==<br />
<br />
''Update: tca_correct has been implemented independently of GSoC and has been available since Hugin 0.7.0, however there is no GUI''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
An utility to determining the Transverse Chromatic Aberration (tCA) of an image so it can be corrected.<br />
<br />
CA is when the color channels in an image do not appear to line up well with each other. tCA is when colors are in focus but placed adjacent to each other. tCA can be corrected with Panorama Tool's Radial Shift. More info on [[Chromatic aberration]]<br />
<br />
Correcting tCA using PanoTools' Radial Shift, requires knowing the radial correction coefficients a, b and c for your lens. PTOptimizer can be used to calculate the coefficients if known amounts of shift for each channel is known from the center to the corners of the image.<br />
<br />
This utility will produce these coefficients to be used in the lens database.<br />
<br />
Assume image is 180 deg diagonal filed of view. Regardless if it is rectangular or fisheye of any field of view. Map image to the nadir of a sphere, taking into account any offset from center of image.<br />
<br />
The bottom of the remapped image is the center of the original. Moving up the remapped image is the same as moving away from the center of the original image.<br />
<br />
Now we no longer have to deal with radial shift but vertical shift. The image can be divided into a number of strips going across the entire width of the image. Each strip represents a circle a different distance from the center. The strips are shifted up and down the same amount over the entire image width. Each strip can have the channel data adjusted up and down to find the best match to eliminate CAt at that position. One channel does not move while the other two are adjusted. The best result of the two channels are recored for every strip. Sub pixel accuracy can be achieved by increasing the height of the result when creating the remapped image.<br />
<br />
This can be done manually in real-time giving visual feedback of the channels alignment. Or it can be done programmability doing a difference between the two channels and looking at the histogram. The blackest result has the best alignment. If accurate automated results are possible then there is no need for the manual method.<br />
<br />
Current methods of correcting [http://hugin.sourceforge.net/tutorials/tca/en.shtml tCA] are fairly complicated. Though it can be [http://thread.gmane.org/gmane.comp.misc.ptx/8183/focus=8236 completely automated] using a patched version of [[align_image_stack]] from the [[hugin]] project, this technique works very well but could use some optimisation work to make it faster (and the align_image_stack patch needs integrating).<br />
<br />
Also according to [http://lists.freedesktop.org/archives/create/2008-February/001093.html this post] by the author of ufraw, the tCA correction in the latest [[dcraw]] is done before bayer interpolation (note that my interpretation of this code was the opposite , so what do I know - [[User:Bruno|Bruno]]). This tool should also create parameters for use by dcraw.<br />
<br />
== Extend hugin's output options for stitching ==<br />
<br />
''Note this project would need to be complementary to any work done on [[SoC_2010_ideas#Makefile_system_and_Detection_of_panoramas]]. i.e. the framework for creating it doesn't yet exist.''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Currently hugin offers jpg, png, tiff and layered tiff output. Suggested are other formats like layered psd; swf , java and html generation for web publishing. Despite of all software projects efforts, stitched panoramas have some errors (like ghost objects) that can be easily removed in Photoshop or Gimp with layered output. A lot of open source graphical software already offers proposed file formats, but despite it is not an easy task that can be implemented in a week and therefore it is suitable to be a standalone SoC project<br />
<br />
Note that this is potentially complimentary and orthogonal to the ''batch stitching'' project described above, Makefiles are a good way to provide additional output types and quite suitable for HTML generation or even uploading.<br />
<br />
hugin and other tools generate [[Cropped TIFF]] files, with each 'layer' as a separate file. The workflow described above for using this data in image editors really requires file formats that contain all layers in a single file such as ''multilayer TIFF'' or [[PSD]]. Command-line tools for assembling these files are currently either too buggy to use or non-existent and fixing this situation would be a good project in itself.<br />
<br />
'''Skills'''<br />
<br />
== Utility for creating a Philosphere ==<br />
<br />
''update: note that during the proposal stage this project was discarded as being too small, also mathmap is a better tool for implementing this kind of thing''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Goal: A utility integrated into hugin for creating images from panoramas, suitable for printing.<br />
<br />
Tasks:<br />
* Implementation of described process using modified PT scripts and them combining partial results to final image<br />
* Integration into hugin<br />
<br />
Discussion:<br />
There are several possible outputs that can be used to print a panorama. Examples: polyhedron, "orange slices", rhombicuboctahedron...<br />
<br />
Resources:<br />
* http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm<br />
* [[PTStitcher]]<br />
* [http://www.flickr.com/photos/sbprzd/tags/foldable/ experiments with mathmap] by [[User:Seb Przd]] - Particularly note the 'conformal cube'.<br />
<br />
'''Skills'''<br />
<br />
Required knowledge or interest in:<br />
* panoramic imaging<br />
* C++ and scripting languages development skills.<br />
<br />
== Sky identification ==<br />
<br />
''Update: this was completed as part of GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
Feature matching tools have a tendency to identify potentially useful features in clouds, this is not surprising given the amount of useful contrast and detail in a typical cloud.<br />
<br />
This tendency is problematic when matching images for panorama stitching, as clouds can move significant distances even between photos taken seconds apart.<br />
<br />
This project would find a suitable method of identifying areas of sky based on a search of existing literature, and implement it as a standalone tool capable of pruning [[Control points]] from existing panotools/hugin format script files.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_ideas&diff=13337Historical:SoC 2008 ideas2011-03-30T23:30:41Z<p>Bruno: /* munin — interactive openGL based GUI */</p>
<hr />
<div>= Introduction =<br />
<br />
If you are a student willing to participate in The Google Summer of Code 2008, do as suggested below:<br />
<br />
* find out what ideas we have for SoC projects this year (read below);<br />
* make up your mind, if you want to pick one of those tasks or if you have your own idea;<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx];<br />
* introduce yourself and tell us about your plans and wishes.<br />
* add your proposal to the [[SoC_2008_student_proposals | student proposal page]]<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]). We also very much welcome contributions to [[Enblend]]/[[Enfuse]].<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
Some of the [[SoC2007 projects]] proposals were not done last year and are potential projects for this year:<br />
<br />
* <del>[[SoC2007_projects#Automatic feature matching for panoramic images]]</del> Completed<br />
* <del>[[SoC2007_projects#Interactive panoramic viewer]] (This was completed but there is further possible work to be done)</del> Completed in GSoC 2009<br />
* [[SoC2007_projects#Processing of very large images]] (using the VIPS framework, or even GEGL if ready)<br />
* [[SoC2007_projects#Architectural Overhaul of Panotools]]<br />
<br />
== munin — interactive openGL based GUI ==<br />
<br />
''note 2011: the opengl preview has since been implemented in Hugin. Hugin now has an experimental python interface, so this project is relevant again''<br />
<br />
(Note that [http://munin.projects.linpro.no/ munin] is a popular open source graphing tool for network administrators, so this name isn't really usable)<br />
<br />
'''Possible Mentors''':<br />
<br />
* Pablo<br />
<br />
'''Description''':<br />
<br />
Intuitive and interactive GUI, with priority in usability over available features and flexibility, based on what users should see — not on what software does internally. To there are two roads for this:<br />
<br />
1. Create bindings to the core hugin library to a high level scripting language such as python, ruby or maybe lua. Use these to write the GUI.<br />
2. Use the core libary directly and write the GUI in C++. While this might be easier from the start, a GUI written in a scripting<br />
language has major benefits for the long term (rapid development, extensibility etc.).<br />
<br />
It would be nice to have a preview/renderer in OpenGL, but I fear that a new GUI and OpenGL acceleration is too big for a single GSOC project. If you are an experienced developer (know and have used all the required technology on non-trivial projects) it might be possible though.<br />
<br />
'''Skills''':<br />
<br />
* C++<br />
* Scripting language (python, ruby, lua?)<br />
* Qt4<br />
* OpenGL<br />
<br />
'''Discussion''':<br />
<br />
how about relaxing the skills, and instead of fixing on Qt4 work on a combination of high level scripting language and widgets? Phythons + wxWidgets or Lua + wxWidgets come to my mind. Right now we have the option as both wxWidgets and Qt are in trunk, and if the student codes those widgets that require speed in OpenGL so that they integrate into such an API, any scripter can then leverage them for the fast and efficient design of GUI. [[User:Yuval|Yuval]] 12:50, 4 March 2008 (CET)<br />
<br />
I think the GUI + OpenGL is a bit too much for a single project. A separate project for OpenGL acceleration would make more sense, I fear. I'd really like to see a scripting language interface to the hugin core library.<br />
<small>--[[User:Pablo|pablo]] 08:47, 19 March 2008 (CET)</small><br />
<br />
== enblend-enfuse zenith/nadir and more ==<br />
<br />
'''Primary Mentor'''<br />
<br />
Andrew Mihal<br />
<br />
'''Description'''<br />
<br />
* implementing blending of the zenith and nadir in Enblend and Enfuse<br />
*:The best way I can think of to do this is to use a cubic projection and provide all cube faces to the tool simultaneously. All of the boundaries will be horizontal or vertical lines, which will fit in well with the SKIPSM-based pyramid algorithms currently in use. Enblend and Enfuse can share the same pyramid code.<br />
* Enblend would additionally need a nearest feature transform algorithm that works on the cube surface for mask generation. I am not aware of a published algorithm to solve this.<br />
* Improve the seam optimization algorithm in Enblend.<br />
* GUI hooks: an API to a higher anstraction level language such as Python+wxWidgets or Lua+wxWidgets, with a real time interface into the enfuse functionality so that when changing weights with a sliders a preview can be generated in near real time. <br />
* multi-step fusing and alternative, user controlled, weighting (sigma).<br />
<br />
'''Skills'''<br />
<br />
'''Admission Test'''<br />
<br />
A potential applicant for this project should first try to add boundary conditions to the localVarianceIf function in enfuse.h.<br />
<br />
== OpenGL accelerated hugin preview ==<br />
<br />
''Update: This was completed as part of GSoC 2008 'fast preview' and has been available since Hugin 0.8.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
There is a nice proof of concept for this idea created as a [http://vision.eng.shu.ac.uk/mmvlwiki/index.php/Panorama_Viewer student project at Hallam University].<br />
<br />
'''Skills'''<br />
<br />
== Ghost removal for enfuse ==<br />
<br />
''Update: This was completed as part of GSoC 2009 and will be available in Hugin 2010.0'' <br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Thanks to [[SoC2007 project Anti Ghosting]], hugin has ghost removal when merging [[Bracketing|bracketed]] series to [[HDR]], but this isn't currently available for [[enfuse]].<br />
<br />
'''Skills'''<br />
<br />
== Masking in GUI ==<br />
<br />
''Update: This has been completed independently of GSoC and will be available with Hugin 2010.2.0''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
Currently masking to remove unwanted objects from panoramas has to be added to alpha channels which is laborious, this could be integrated into the hugin GUI via a simple vector/polygon editor. It would need to be simpler to use than the [http://hugin.sourceforge.net/tutorials/enblend-svg/ equivalent process with Inkscape]<br />
<br />
'''Skills'''<br />
<br />
== Batch processing ==<br />
<br />
''Update: This was completed in GSoC 2008 and has been available since Hugin 0.8.0. However there is still no GUI system for batch processing the creation of Hugin projects''<br />
<br />
'''Primary mentor'''<br />
<br />
'''Discussion'''<br />
<br />
[[SoC2007 project Batch Processing]] was an unadopted project last year.<br />
<br />
Now that hugin has a Makefile based stitching process, it is much clearer what a batch stitcher would look like. This would need to support 'plug-in' Makefile add-ons for additional views, QTVR generation, uploading, sharpening etc... as well as a queue/spool manager.<br />
<br />
Some explanation of this existing 'Makefile process': Currently hugin stitches projects by writing out the instructions (remapping and blending with nona, enblend, enfuse, exiftool etc...) into a standard Makefile and then running 'make -f project.pto.mk all clean' - This happens all in one go when a user clicks 'save and stitch', but alternatively the user has a choice to run 'make' manually.<br />
<br />
So batch processing already exists for users familiar with the command-line, ie. we can run 'make -j 16' to run processes in parallel or use a tool such as [http://distmake.sourceforge.net/pmwiki/pmwiki.php distmake] to queue jobs over the network on multiple machines.<br />
<br />
A plugin system also already exists to a certain extent in that these Makefiles can be extended with other makefiles that add additional targets, one for creating QTVR output is described [http://thread.gmane.org/gmane.comp.misc.ptx/8754 here].<br />
<br />
A batch stitcher would need to enable some or all of this functionality for normal users who have an interest in photography rather than tinkering with script files.<br />
<br />
'''Skills'''<br />
<br />
== Lens Database ==<br />
<br />
'''Primary mentor'''<br />
<br />
Alexandre Jenny<br />
<br />
'''Discussion'''<br />
<br />
Lens database of accumulated knowledge on distortion, CA, response curve.<br />
The lens database aim : using stitching to feed an huge camera / lens database for distortion correction, vignetting correction, ca, etc. Then, it will be possible to reuse this database to correct single pictures too.<br />
<br />
There are two ways to generate such a database:<br />
<br />
# Collect high quality photographs centrally, manually calibrate them and assemble a database that matches parameters with image EXIF data - This is how the [[PTLens]] database was collected.<br />
# Use the fact that stitching software (eg hugin, but there are other tools using the same lens correction model) effectively calibrates lenses every time a project is stitched - This information could be collected, validated and averaged centrally to automate the creation of a lens database.<br />
<br />
This project would investigate the second technique. It can be divided into several subparts which are independent. <br />
First part theory :<br />
* Distortion parameters accumulation : what measure is important, what can be such a measure reproduced, what criterion should be use in a stitch to be sure that the optimized parameters are good for the database.<br />
* CA : find a reproducible way to measure it. Study the variation of the CA with zoom parameters ( varying with aperture ? with focal ? )<br />
* response curve : this parameter is less dependent on the lens, it's more sensor / maker related.<br />
<br />
Second part : statistic accumulation<br />
* design a standard format to store every parameter,<br />
* create and manage a central repository of lens database.<br />
<br />
'''Skills'''<br />
<br />
General : in computer vision field<br />
Coding : C / C++ / stl<br />
Math : optimizing technics<br />
<br />
== tCA Correction ==<br />
<br />
''Update: tca_correct has been implemented independently of GSoC and has been available since Hugin 0.7.0, however there is no GUI''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
An utility to determining the Transverse Chromatic Aberration (tCA) of an image so it can be corrected.<br />
<br />
CA is when the color channels in an image do not appear to line up well with each other. tCA is when colors are in focus but placed adjacent to each other. tCA can be corrected with Panorama Tool's Radial Shift. More info on [[Chromatic aberration]]<br />
<br />
Correcting tCA using PanoTools' Radial Shift, requires knowing the radial correction coefficients a, b and c for your lens. PTOptimizer can be used to calculate the coefficients if known amounts of shift for each channel is known from the center to the corners of the image.<br />
<br />
This utility will produce these coefficients to be used in the lens database.<br />
<br />
Assume image is 180 deg diagonal filed of view. Regardless if it is rectangular or fisheye of any field of view. Map image to the nadir of a sphere, taking into account any offset from center of image.<br />
<br />
The bottom of the remapped image is the center of the original. Moving up the remapped image is the same as moving away from the center of the original image.<br />
<br />
Now we no longer have to deal with radial shift but vertical shift. The image can be divided into a number of strips going across the entire width of the image. Each strip represents a circle a different distance from the center. The strips are shifted up and down the same amount over the entire image width. Each strip can have the channel data adjusted up and down to find the best match to eliminate CAt at that position. One channel does not move while the other two are adjusted. The best result of the two channels are recored for every strip. Sub pixel accuracy can be achieved by increasing the height of the result when creating the remapped image.<br />
<br />
This can be done manually in real-time giving visual feedback of the channels alignment. Or it can be done programmability doing a difference between the two channels and looking at the histogram. The blackest result has the best alignment. If accurate automated results are possible then there is no need for the manual method.<br />
<br />
Current methods of correcting [http://hugin.sourceforge.net/tutorials/tca/en.shtml tCA] are fairly complicated. Though it can be [http://thread.gmane.org/gmane.comp.misc.ptx/8183/focus=8236 completely automated] using a patched version of [[align_image_stack]] from the [[hugin]] project, this technique works very well but could use some optimisation work to make it faster (and the align_image_stack patch needs integrating).<br />
<br />
Also according to [http://lists.freedesktop.org/archives/create/2008-February/001093.html this post] by the author of ufraw, the tCA correction in the latest [[dcraw]] is done before bayer interpolation (note that my interpretation of this code was the opposite , so what do I know - [[User:Bruno|Bruno]]). This tool should also create parameters for use by dcraw.<br />
<br />
== Extend hugin's output options for stitching ==<br />
<br />
''Note this project would need to be complementary to any work done on [[SoC_2010_ideas#Makefile_system_and_Detection_of_panoramas]]. i.e. the framework for creating it doesn't yet exist.''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Currently hugin offers jpg, png, tiff and layered tiff output. Suggested are other formats like layered psd; swf , java and html generation for web publishing. Despite of all software projects efforts, stitched panoramas have some errors (like ghost objects) that can be easily removed in Photoshop or Gimp with layered output. A lot of open source graphical software already offers proposed file formats, but despite it is not an easy task that can be implemented in a week and therefore it is suitable to be a standalone SoC project<br />
<br />
Note that this is potentially complimentary and orthogonal to the ''batch stitching'' project described above, Makefiles are a good way to provide additional output types and quite suitable for HTML generation or even uploading.<br />
<br />
hugin and other tools generate [[Cropped TIFF]] files, with each 'layer' as a separate file. The workflow described above for using this data in image editors really requires file formats that contain all layers in a single file such as ''multilayer TIFF'' or [[PSD]]. Command-line tools for assembling these files are currently either too buggy to use or non-existent and fixing this situation would be a good project in itself.<br />
<br />
'''Skills'''<br />
<br />
== Utility for creating a Philosphere ==<br />
<br />
''update: note that during the proposal stage this project was discarded as being too small, also mathmap is a better tool for implementing this kind of thing''<br />
<br />
'''Primary Mentor'''<br />
<br />
Zoran Mesec<br />
<br />
'''Description'''<br />
<br />
Goal: A utility integrated into hugin for creating images from panoramas, suitable for printing.<br />
<br />
Tasks:<br />
* Implementation of described process using modified PT scripts and them combining partial results to final image<br />
* Integration into hugin<br />
<br />
Discussion:<br />
There are several possible outputs that can be used to print a panorama. Examples: polyhedron, "orange slices", rhombicuboctahedron...<br />
<br />
Resources:<br />
* http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm<br />
* [[PTStitcher]]<br />
* [http://www.flickr.com/photos/sbprzd/tags/foldable/ experiments with mathmap] by [[User:Seb Przd]] - Particularly note the 'conformal cube'.<br />
<br />
'''Skills'''<br />
<br />
Required knowledge or interest in:<br />
* panoramic imaging<br />
* C++ and scripting languages development skills.<br />
<br />
== Sky identification ==<br />
<br />
''Update: this was completed as part of GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
'''Primary Mentor'''<br />
<br />
'''Description'''<br />
<br />
Feature matching tools have a tendency to identify potentially useful features in clouds, this is not surprising given the amount of useful contrast and detail in a typical cloud.<br />
<br />
This tendency is problematic when matching images for panorama stitching, as clouds can move significant distances even between photos taken seconds apart.<br />
<br />
This project would find a suitable method of identifying areas of sky based on a search of existing literature, and implement it as a standalone tool capable of pruning [[Control points]] from existing panotools/hugin format script files.<br />
<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC2007_projects&diff=13336Historical:SoC2007 projects2011-03-30T23:25:48Z<p>Bruno: /* Automatic feature matching for panoramic images */</p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= Introduction =<br />
<br />
The Google Summer of Code 2007 is officially over.<br />
<br />
If you land here as a student looking for an internship opportunity, get ready in case there is a 2008 edition of this initiative:<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx].<br />
* learn and understand panorama photography. Concepts like the pinhole camera, 3D projections, etc. You are on the right Wiki for that!<br />
* learn about our code. [http://sourceforge.net/projects/hugin/ hugin] [http://sourceforge.net/projects/panotools/ panotools] [http://sourceforge.net/projects/freepv/ freepv]<br />
* one of the best ways to join the community as a coder is to submit a patch - download the latest SVN code, make an improvement / bugfix and submit a patch to the maintainers.<br />
<br />
If you land here as a person with software development skills and time to spare, we'd love to have you in our community as well. The steps are similar as for the students.<br />
<br />
Panoramic imaging is a very broad field and touches many different areas of expertise, such as photography, computer vision, art and programming.<br />
There is a thriving community with experience from arts to science that provides many interesting ideas and explores new territory in panoramic imaging. In addition to the mentors, this open community will provide good support and innovative ideas.<br />
<br />
Generally, all development should be done with multiple platforms in mind (at least Windows, OSX and Linux/Unix). We have an open communication culture via mailing-lists and mostly develop using C and C++.<br />
<br />
The projects below are just suggestions. If you are an interested student and have questions or new ideas, please let us know on the developers discussion list [https://lists.sourceforge.net/lists/listinfo/panotools-devel panotools-devel].<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]).<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
== Intuitive yet powerful GUI for panorama creation ==<br />
<br />
''Update: this was implemented as a major refactoring of the codebase, separating wxwidgets GUI from the backend code and available since Hugin 0.7.0''<br />
<br />
Project successfully completed. The new GUI framework is there and it is waiting for coders to write widgets (in Qt) and bring the functionality to the surface. [http://google-summer-of-code-2007-pano.googlecode.com/files/Ippei_Ukai.tar.gz]<br />
<br />
== Automatic feature detection for panoramic images ==<br />
<br />
''update: this has been successfully implemented as [[cpfind]] in the current [[Hugin]] codebase''<br />
<br />
Project successfully completed. Code is being further improved. Integration requires feature matching.<br />
<br />
== Automatic feature matching for panoramic images ==<br />
<br />
''update: this has been successfully implemented as [[cpfind]] in the current [[Hugin]] codebase''<br />
''update: this was completed in GSoC 2008, control point generators still need work''<br />
<br />
Goal: Robust and efficient matching of local image features.<br />
<br />
Tasks:<br />
* Implementation of the matching step, including geometry based outlier pruning (for example using RANSAC) and nearest neighbour matching, possibly using a fast algorithm such as cover trees. For the panoramic imaging use case, several heuristics could be used to improve the matching behaviour, including using the EXIF timestamps, or previously known approximate orientation of the images.<br />
<br />
'''Further details are being discussed in the separate [[SoC2007 project Feature Matching|SoC Feature Matching project]] page'''.<br />
<br />
A desired result of the projects would be:<br />
* Standalone program for the feature matching part, which at the end should accept the features found by the automatic feature detection task. Preliminary studies can be done using the existing SIFT and SURF detector/descriptors.<br />
* Integration into [[hugin]] and a standalone executable similar to [[Autopano-sift]] or [[Autopano]]<br />
<br />
Required knowledge or interest in:<br />
* signal or image processing background<br />
* C or C++ development skills.<br />
<br />
Possibly useful resources and libraries:<br />
* [http://hunch.net/~jl/projects/cover_tree/cover_tree.html Fast nearest neighbour matching using cover trees]<br />
<br />
Mentor: Pablo d'Angelo, ?<br />
<br />
License: GPL<br />
<br />
== Interactive panoramic viewer ==<br />
<br />
''Update: the freepv panorama viewer was integrated into VLC in GSoC 2008''<br />
<br />
Project successfully completed. The code now supports also SPi-V panoramas. There are always advanced features that are not yet implemented and could be. If you have ideas of what you want to implement, and you have time to do it, contact us.<br />
<br />
One idea is to turn freepv into a library and write a wrapper around it so that existing multi-media plugin can pass on to freepv qtvr and spi-v panoramas to display. this will avoid the current race condition, that either freepv or one of the existing multi-media plugins take over the content and so either VR or movies but not both can be displayed in the browser.<br />
<br />
Improvement ideas:<br />
* Support for hotspots<br />
* Optimisation for panoramas larger than the Video RAM<br />
* Display of high dynamic range panoramas with adaptive exposure<br />
* Fallback software renderer<br />
<br />
Required knowledge or interest in:<br />
* OpenGL or other 3D programming experience.<br />
* Creating cool and nice looking interactive experiences.<br />
<br />
Mentor: Pablo d'Angelo, Fulvio Senore ?<br />
<br />
Student: [[User:Leonox|Leon Moctezuma]]<br />
<br />
[[Interactive Panoramic Viewer|Project detail page]]<br />
<br />
License: LGPL<br />
<br />
== Anti-ghosting HDR panorama blending and merging algorithm ==<br />
<br />
''Update: anti-ghosting for HDR was implemented in GSoC 2008 and anti-ghosting for enfuse was implemented in GSoC 2009. Deghosting for enfuse will be available in Hugin 2010.0.0''<br />
<br />
Project was successful and is being integrated in the next hugin release.<br />
<br />
== Processing of very large images ==<br />
<br />
Project open.<br />
<br />
Goal: Allow the creation of arbitrary large panoramas.<br />
[http://flickr.com/groups/83823859@N00/discuss/72157594574253488/]<br />
<br />
Currently panotools, as well as hugin/nona require memory to hold the complete input and the remapped output image in memory, which consumes a lot of RAM, especially for spherical panoramas. [http://www.vips.ecs.soton.ac.uk/ VIPS] is a powerful and modular image processing library that supports very large images and multiple processors natively. By porting the core remapping routines of panotools/hugin to VIPS, panoramas of almost arbitrary size can be computed.<br />
<br />
A desired result of the projects would be:<br />
* VIPS operations that support the geometric and photometric (vignetting correction) transformations.<br />
* Standalone command line program that remaps images using these routines.<br />
* Program/script to convert panotools scripts to nip2 projects.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* image processing<br />
<br />
Mentor: John Cupitt, Pablo d'Angelo<br />
<br />
License: GPL<br />
<br />
== Architectural Overhaul of Panotools ==<br />
<br />
Some of this has been done in the GUI framework project.<br />
<br />
Panotools is a very monolithic application. The goal of this project is to refactor the functionality of panotools into 4 main parts, as independent of each other as possible.<br />
These parts are (at least):<br />
<br />
* Calculation of position of images (optimization)<br />
* Mapping from input images to output images<br />
* Projection related computations<br />
* Parsing of input scripts/Generation of input scripts<br />
<br />
Were this project successful the functionality of panotools will be available as a collection of routines that be called directly (as opposed to the current model that requires<br />
the creation and parsing of a script). It will make it easier to replace one component of panotools with another one; and it will improve the future maintenance of panotools.<br />
<br />
'''Details to be discussed on [[SoC2007 project Panotools Architecture|the separate page]]'''.<br />
<br />
A desired result of the projects would be:<br />
* Set of functions/classes that are available to hugin to perform optimization and remapping of images<br />
* Test suite to verify that the functionality before and after is equivalent.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* Knowledge of Numerical methods<br />
* Basic knowledge of image processing<br />
<br />
Mentor: D.M. German<br />
<br />
License: GPL<br />
<br />
== PTButcher ==<br />
<br />
''Update: the Hugin Batch Processor was implemented in GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
A batch creator-project manager for batch creating projects, optimizing, managing groups of projects, names outputs, indipendently invoke the software parts and feed scripts.<br />
<br />
All the software is based on advanced find-replace in text files, generation of script files, but needs an user-friendly GUI, the main investment in the coding I suppose.<br />
<br />
General<br />
* ability to translate projects between the various gui.<br />
* To search projects in subfolders<br />
* to keep history of all operations, with undos ability.<br />
<br />
batch building projects<br />
* creates projects basing on the subfolder of a main folders, creates CPs and optimizes.<br />
* Default name schemes customizable for result images and projects. As well as project folder-locations<br />
* Template application (selection in base of image number, or exif)<br />
* Customizable CP finder and refinery<br />
* Customizable optimizer<br />
* report with result and-or creation of a little test image<br />
* capable of hugin-ptgui-whatever panorama project format.<br />
<br />
project manager, <br />
you have a table of all your project, with ability to change, one by one or in group, and without opening them<br />
<br />
* relative and absolute paths for images, changing the full path or a part of it, allowing HD migrations even if projects are foldered in creative ways.<br />
* Path for output image<br />
* output image type, resolution, layers.<br />
* Involved software and modificators.<br />
* 16 bit workflow warnings<br />
<br />
Batch stitching<br />
* ability of batch processing stitch operations, or to invoke the specific software and feed its batch<br />
<br />
Ability to stitch panovideos:<br />
Given a template with the (n) of images involved and (n) folders, containing (m) png images <br />
extracted from the (n) streams to stitch together.<br />
Invoke itself the softwares, and cycles the batch to build (m) images in a new folder.<br />
<br />
Support for HDR or ADR workflows, always template based.<br />
i.e.<br />
Given 3 set of 4 fisheye images and the corresponding template, it generates the main project, optimizes images together, and THEN, render 3images (a,b,c) involving images 0,3,6,9 (a) 1,4,7,10) (b) (2,5,8,11) (c)<br />
<br />
See [http://search.cpan.org/dist/Panotools-Script/ Panotools::Script] for a perl approach to this.<br />
Note that the PanoTools script format is is a bit hard to understand, there is a proposal in the<br />
[[SoC2007 project Panotools Architecture]] to replace it with a more workable XML file format, so work should concentrate on the workflow aspects instead of another panotools script parser.<br />
<br />
Proposal: Luca Vascon<br />
<br />
Mentor: Yuval Levy<br />
<br />
Licence: GPL<br />
<br />
Student: [[User:Stereo sl|Zoran Mesec]]<br />
<br />
[[PTButcher proposal]]<br />
<br />
== PtPatcher, module for Interactive panoramic viewer ==<br />
Was: PTeditor2.<br />
<br />
''Note: This functionality is available via [[panoglview]] and [http://www.flickr.com/photos/36383814@N00/2845671569/ pafextract]''<br />
<br />
The basic need would be to have it integrated in photoshop and Gimp, with a simple “paint on this side” interface. 16Bit workflow needed, as multiple input-output filetype.<br />
See also skypaint for inspiration interface and capabilities.<br />
<br />
There is a lot of overlap here with [[SoC2007 projects#Interactive panoramic viewer|SoC2007 Interactive Panorama Viewer]]. Note<br />
that the viewer simply needs to fork and pass the current filename, pitch, yaw and Field of View to an external script which can handle<br />
the extraction, editing and reinsertion - The viewer itself doesn't need to be involved with any image processing.<br />
<br />
: - If this should be a photoshop plugin it would be a possibility to interact with the Adjust (or PTAdjust) plugin, which can do the extraction and insertion within photoshop (might be possible for the Gimp, too. See [[Panorama Tools Plugins#Adjust]] for details.<small>--[[User:Erik Krause|Erik Krause]] 23:55, 23 March 2007 (CET)</small><br />
<br />
The viewer should allow to save a fileproject in order to allow:<br />
* unlimited close and reopen of the viewer<br />
* multiple interventions and extractions with only one final reinsertion, in order not to loose quality<br />
* working in parallel with multiple images <br />
* batchable alone or with PTButcher, in order to extraxct all nadirs and/or zeniths, with given view angle 'XxY' of panos in a folder and then reinsert them all.<br />
<br />
Proposal: Luca Vascon<br />
<br />
Mentor: <br />
<br />
Do we incorporate this with the viewer?<br />
<br />
Licence: GPL<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:SoC2007_projects&diff=13335Historical:SoC2007 projects2011-03-30T23:24:56Z<p>Bruno: /* Automatic feature detection for panoramic images */</p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= Introduction =<br />
<br />
The Google Summer of Code 2007 is officially over.<br />
<br />
If you land here as a student looking for an internship opportunity, get ready in case there is a 2008 edition of this initiative:<br />
* join our community at [http://groups.google.com/group/hugin-ptx/ hugin-ptx].<br />
* learn and understand panorama photography. Concepts like the pinhole camera, 3D projections, etc. You are on the right Wiki for that!<br />
* learn about our code. [http://sourceforge.net/projects/hugin/ hugin] [http://sourceforge.net/projects/panotools/ panotools] [http://sourceforge.net/projects/freepv/ freepv]<br />
* one of the best ways to join the community as a coder is to submit a patch - download the latest SVN code, make an improvement / bugfix and submit a patch to the maintainers.<br />
<br />
If you land here as a person with software development skills and time to spare, we'd love to have you in our community as well. The steps are similar as for the students.<br />
<br />
Panoramic imaging is a very broad field and touches many different areas of expertise, such as photography, computer vision, art and programming.<br />
There is a thriving community with experience from arts to science that provides many interesting ideas and explores new territory in panoramic imaging. In addition to the mentors, this open community will provide good support and innovative ideas.<br />
<br />
Generally, all development should be done with multiple platforms in mind (at least Windows, OSX and Linux/Unix). We have an open communication culture via mailing-lists and mostly develop using C and C++.<br />
<br />
The projects below are just suggestions. If you are an interested student and have questions or new ideas, please let us know on the developers discussion list [https://lists.sourceforge.net/lists/listinfo/panotools-devel panotools-devel].<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]).<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
== Intuitive yet powerful GUI for panorama creation ==<br />
<br />
''Update: this was implemented as a major refactoring of the codebase, separating wxwidgets GUI from the backend code and available since Hugin 0.7.0''<br />
<br />
Project successfully completed. The new GUI framework is there and it is waiting for coders to write widgets (in Qt) and bring the functionality to the surface. [http://google-summer-of-code-2007-pano.googlecode.com/files/Ippei_Ukai.tar.gz]<br />
<br />
== Automatic feature detection for panoramic images ==<br />
<br />
''update: this has been successfully implemented as [[cpfind]] in the current [[Hugin]] codebase''<br />
<br />
Project successfully completed. Code is being further improved. Integration requires feature matching.<br />
<br />
== Automatic feature matching for panoramic images ==<br />
<br />
''update: this was completed in GSoC 2008, control point generators still need work''<br />
<br />
Goal: Robust and efficient matching of local image features.<br />
<br />
Tasks:<br />
* Implementation of the matching step, including geometry based outlier pruning (for example using RANSAC) and nearest neighbour matching, possibly using a fast algorithm such as cover trees. For the panoramic imaging use case, several heuristics could be used to improve the matching behaviour, including using the EXIF timestamps, or previously known approximate orientation of the images.<br />
<br />
'''Further details are being discussed in the separate [[SoC2007 project Feature Matching|SoC Feature Matching project]] page'''.<br />
<br />
A desired result of the projects would be:<br />
* Standalone program for the feature matching part, which at the end should accept the features found by the automatic feature detection task. Preliminary studies can be done using the existing SIFT and SURF detector/descriptors.<br />
* Integration into [[hugin]] and a standalone executable similar to [[Autopano-sift]] or [[Autopano]]<br />
<br />
Required knowledge or interest in:<br />
* signal or image processing background<br />
* C or C++ development skills.<br />
<br />
Possibly useful resources and libraries:<br />
* [http://hunch.net/~jl/projects/cover_tree/cover_tree.html Fast nearest neighbour matching using cover trees]<br />
<br />
Mentor: Pablo d'Angelo, ?<br />
<br />
License: GPL<br />
<br />
== Interactive panoramic viewer ==<br />
<br />
''Update: the freepv panorama viewer was integrated into VLC in GSoC 2008''<br />
<br />
Project successfully completed. The code now supports also SPi-V panoramas. There are always advanced features that are not yet implemented and could be. If you have ideas of what you want to implement, and you have time to do it, contact us.<br />
<br />
One idea is to turn freepv into a library and write a wrapper around it so that existing multi-media plugin can pass on to freepv qtvr and spi-v panoramas to display. this will avoid the current race condition, that either freepv or one of the existing multi-media plugins take over the content and so either VR or movies but not both can be displayed in the browser.<br />
<br />
Improvement ideas:<br />
* Support for hotspots<br />
* Optimisation for panoramas larger than the Video RAM<br />
* Display of high dynamic range panoramas with adaptive exposure<br />
* Fallback software renderer<br />
<br />
Required knowledge or interest in:<br />
* OpenGL or other 3D programming experience.<br />
* Creating cool and nice looking interactive experiences.<br />
<br />
Mentor: Pablo d'Angelo, Fulvio Senore ?<br />
<br />
Student: [[User:Leonox|Leon Moctezuma]]<br />
<br />
[[Interactive Panoramic Viewer|Project detail page]]<br />
<br />
License: LGPL<br />
<br />
== Anti-ghosting HDR panorama blending and merging algorithm ==<br />
<br />
''Update: anti-ghosting for HDR was implemented in GSoC 2008 and anti-ghosting for enfuse was implemented in GSoC 2009. Deghosting for enfuse will be available in Hugin 2010.0.0''<br />
<br />
Project was successful and is being integrated in the next hugin release.<br />
<br />
== Processing of very large images ==<br />
<br />
Project open.<br />
<br />
Goal: Allow the creation of arbitrary large panoramas.<br />
[http://flickr.com/groups/83823859@N00/discuss/72157594574253488/]<br />
<br />
Currently panotools, as well as hugin/nona require memory to hold the complete input and the remapped output image in memory, which consumes a lot of RAM, especially for spherical panoramas. [http://www.vips.ecs.soton.ac.uk/ VIPS] is a powerful and modular image processing library that supports very large images and multiple processors natively. By porting the core remapping routines of panotools/hugin to VIPS, panoramas of almost arbitrary size can be computed.<br />
<br />
A desired result of the projects would be:<br />
* VIPS operations that support the geometric and photometric (vignetting correction) transformations.<br />
* Standalone command line program that remaps images using these routines.<br />
* Program/script to convert panotools scripts to nip2 projects.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* image processing<br />
<br />
Mentor: John Cupitt, Pablo d'Angelo<br />
<br />
License: GPL<br />
<br />
== Architectural Overhaul of Panotools ==<br />
<br />
Some of this has been done in the GUI framework project.<br />
<br />
Panotools is a very monolithic application. The goal of this project is to refactor the functionality of panotools into 4 main parts, as independent of each other as possible.<br />
These parts are (at least):<br />
<br />
* Calculation of position of images (optimization)<br />
* Mapping from input images to output images<br />
* Projection related computations<br />
* Parsing of input scripts/Generation of input scripts<br />
<br />
Were this project successful the functionality of panotools will be available as a collection of routines that be called directly (as opposed to the current model that requires<br />
the creation and parsing of a script). It will make it easier to replace one component of panotools with another one; and it will improve the future maintenance of panotools.<br />
<br />
'''Details to be discussed on [[SoC2007 project Panotools Architecture|the separate page]]'''.<br />
<br />
A desired result of the projects would be:<br />
* Set of functions/classes that are available to hugin to perform optimization and remapping of images<br />
* Test suite to verify that the functionality before and after is equivalent.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* Knowledge of Numerical methods<br />
* Basic knowledge of image processing<br />
<br />
Mentor: D.M. German<br />
<br />
License: GPL<br />
<br />
== PTButcher ==<br />
<br />
''Update: the Hugin Batch Processor was implemented in GSoC 2008 and has been available since Hugin 0.8.0''<br />
<br />
A batch creator-project manager for batch creating projects, optimizing, managing groups of projects, names outputs, indipendently invoke the software parts and feed scripts.<br />
<br />
All the software is based on advanced find-replace in text files, generation of script files, but needs an user-friendly GUI, the main investment in the coding I suppose.<br />
<br />
General<br />
* ability to translate projects between the various gui.<br />
* To search projects in subfolders<br />
* to keep history of all operations, with undos ability.<br />
<br />
batch building projects<br />
* creates projects basing on the subfolder of a main folders, creates CPs and optimizes.<br />
* Default name schemes customizable for result images and projects. As well as project folder-locations<br />
* Template application (selection in base of image number, or exif)<br />
* Customizable CP finder and refinery<br />
* Customizable optimizer<br />
* report with result and-or creation of a little test image<br />
* capable of hugin-ptgui-whatever panorama project format.<br />
<br />
project manager, <br />
you have a table of all your project, with ability to change, one by one or in group, and without opening them<br />
<br />
* relative and absolute paths for images, changing the full path or a part of it, allowing HD migrations even if projects are foldered in creative ways.<br />
* Path for output image<br />
* output image type, resolution, layers.<br />
* Involved software and modificators.<br />
* 16 bit workflow warnings<br />
<br />
Batch stitching<br />
* ability of batch processing stitch operations, or to invoke the specific software and feed its batch<br />
<br />
Ability to stitch panovideos:<br />
Given a template with the (n) of images involved and (n) folders, containing (m) png images <br />
extracted from the (n) streams to stitch together.<br />
Invoke itself the softwares, and cycles the batch to build (m) images in a new folder.<br />
<br />
Support for HDR or ADR workflows, always template based.<br />
i.e.<br />
Given 3 set of 4 fisheye images and the corresponding template, it generates the main project, optimizes images together, and THEN, render 3images (a,b,c) involving images 0,3,6,9 (a) 1,4,7,10) (b) (2,5,8,11) (c)<br />
<br />
See [http://search.cpan.org/dist/Panotools-Script/ Panotools::Script] for a perl approach to this.<br />
Note that the PanoTools script format is is a bit hard to understand, there is a proposal in the<br />
[[SoC2007 project Panotools Architecture]] to replace it with a more workable XML file format, so work should concentrate on the workflow aspects instead of another panotools script parser.<br />
<br />
Proposal: Luca Vascon<br />
<br />
Mentor: Yuval Levy<br />
<br />
Licence: GPL<br />
<br />
Student: [[User:Stereo sl|Zoran Mesec]]<br />
<br />
[[PTButcher proposal]]<br />
<br />
== PtPatcher, module for Interactive panoramic viewer ==<br />
Was: PTeditor2.<br />
<br />
''Note: This functionality is available via [[panoglview]] and [http://www.flickr.com/photos/36383814@N00/2845671569/ pafextract]''<br />
<br />
The basic need would be to have it integrated in photoshop and Gimp, with a simple “paint on this side” interface. 16Bit workflow needed, as multiple input-output filetype.<br />
See also skypaint for inspiration interface and capabilities.<br />
<br />
There is a lot of overlap here with [[SoC2007 projects#Interactive panoramic viewer|SoC2007 Interactive Panorama Viewer]]. Note<br />
that the viewer simply needs to fork and pass the current filename, pitch, yaw and Field of View to an external script which can handle<br />
the extraction, editing and reinsertion - The viewer itself doesn't need to be involved with any image processing.<br />
<br />
: - If this should be a photoshop plugin it would be a possibility to interact with the Adjust (or PTAdjust) plugin, which can do the extraction and insertion within photoshop (might be possible for the Gimp, too. See [[Panorama Tools Plugins#Adjust]] for details.<small>--[[User:Erik Krause|Erik Krause]] 23:55, 23 March 2007 (CET)</small><br />
<br />
The viewer should allow to save a fileproject in order to allow:<br />
* unlimited close and reopen of the viewer<br />
* multiple interventions and extractions with only one final reinsertion, in order not to loose quality<br />
* working in parallel with multiple images <br />
* batchable alone or with PTButcher, in order to extraxct all nadirs and/or zeniths, with given view angle 'XxY' of panos in a folder and then reinsert them all.<br />
<br />
Proposal: Luca Vascon<br />
<br />
Mentor: <br />
<br />
Do we incorporate this with the viewer?<br />
<br />
Licence: GPL<br />
[[Category:Community:Project]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13334Historical:GSOC 2011 Ideas2011-03-30T23:23:28Z<p>Bruno: add 2007</p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad]<br />
<br />
See also ideas from previous years, some of which haven't been implemented:<br />
<br />
* [[SoC 2010 ideas]]<br />
* [[SoC 2009 idea|SoC 2009 ideas]]<br />
* [[SoC 2008 ideas]]<br />
* [[SoC2007 projects|SoC 2007 ideas]]</div>Brunohttps://wiki.panotools.org/index.php?title=Historical:GSOC_2011_Ideas&diff=13333Historical:GSOC 2011 Ideas2011-03-30T23:21:51Z<p>Bruno: link to ideas pages from previous years</p>
<hr />
<div>We will probably list all ideas and ask for students ideas on this page, for the moment we collected some ideas as [https://blueprints.launchpad.net/hugin blueprints over at launchpad]<br />
<br />
See also ideas from previous years, some of which haven't been implemented:<br />
<br />
* [[SoC 2008 ideas]]<br />
* [[SoC 2009 idea]]<br />
* [[SoC 2010 ideas]]</div>Brunohttps://wiki.panotools.org/index.php?title=Panini&diff=13322Panini2011-03-22T23:54:18Z<p>Bruno: categorise</p>
<hr />
<div>The projection labelled "Panini" in libpano13 is not actually the standard Pannini (cylindrical stereographic) projection, but a variant having an exaggerated vertical scale. It is not very useful and should probably be removed from the library. <br />
<br />
For true Pannini projections, select "equirectangular Panini" or "[[The General Panini Projection|Panini general]]". The latter, available since early 2010, is identical to the former at default parameter settings, and is adjustable for a wide range of perspective effects.<br />
<br />
== see also ==<br />
For the similarly named viewer ''Panini perspective tool'' by Thomas Sharpless see [[Panorama Viewers#Stand_alone_Viewers|Panorama Viewers]].<br />
<br />
[[Category:Glossary]]</div>Brunohttps://wiki.panotools.org/index.php?title=Equirectangular_Panini&diff=13321Equirectangular Panini2011-03-22T23:54:07Z<p>Bruno: categorise</p>
<hr />
<div>The projection labelled "equirectangular Panini" in libpano13 is the standard Pannini projection, which is the cylindrical analogue of the stereographic projection. The "[[The General Panini Projection|Panini general]]" projection, available since early 2010, is an adjustable projection that is identical to "equirectangular Panini" at its default parameter settings.<br />
<br />
[[Category:Glossary]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Stitcher_tab&diff=13307Hugin Stitcher tab2011-03-14T22:49:47Z<p>Bruno: rearrange to match GUI</p>
<hr />
<div>The rest of [[hugin]] is all about setting up the project and aligning images, the '''Stitcher''' tab is where<br />
the final output file is created.<br />
<br />
= Projection =<br />
<br />
Here you can set the output '''[[Projections|Projection]]''' of your project, there are lots<br />
to choose from, each with different advantages and disadvantages:<br />
<br />
* [[Rectilinear Projection|Rectilinear]], this is the same projection as a photo taken with a 'normal' camera and lens. Use this if you are just stitching a handful of photographs together with a narrow [[Field of View]] or [[Perspective correction|correcting perspective]] in a single shot.<br />
* [[Cylindrical Projection|Cylindrical]], actually a simple [[Cylindrical Projection]] as used by traditional rotating panoramic cameras. A good projection for printing a 360 degree panorama, though you may prefer ''Mercator Projection''.<br />
* [[Equirectangular Projection|Equirectangular]], the all purpose format for representing an entire spherical scene. It covers 360 degrees horizontally as well as the [[zenith]] and [[nadir]].<br />
* [[Fisheye Projection|Fisheye]], the same projection as a photo taken with a ''fisheye lens''. Better for representing a wide [[Field of View]] than ''rectilinear'', but in many cases ''Stereographic Projection'' gives less distortion than simple ''fisheye''.<br />
* [[Stereographic Projection|Stereographic]], a ''conformal'' fisheye image. Objects in a stereographic image keep the same shape and show less distortion than simple ''fisheye''.<br />
* [[Projections#mercator projection|Mercator]], a ''conformal'' cylindrical image. A good projection for printing a 360 degree panorama.<br />
* [[Projections#Transverse mercator projection|Trans Mercator]], a ''mercator'' image rotated 90 degrees, suitable for displaying tall or overhead objects.<br />
* [[Projections#sinusoidal projection|Sinusoidal]], an ''equal area'' projection of an entire spherical scene.<br />
* [[Lambert Equal Area Cylindrical Projection|Lambert Cylindrical Equal Area]]<br />
* [[Lambert Equal Area Azimuthal Projection|Lambert Equal Area Azimuthal]]<br />
* [[Albers Equal Area Conic Projection|Albers Equal Area Conic]]<br />
* [[Miller Cylindrical Projection|Miller Cylindrical]]<br />
* [[Panini]]<br />
* [[Architectural]]<br />
* [[Orthographic]]<br />
* [[Equisolid]]<br />
* [[Equirectangular Panini]]<br />
* [[Biplane]]<br />
* [[Triplane]]<br />
* [[The General Panini Projection|Panini General]]<br />
* [[Thoby Projection]]<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical [[Field of View|angle of view]] of the output image,<br />
clicking '''Calculate Field of View''' will shrink or enlarge the field of view of the<br />
output to fit the arrangement of the input images - The '''Fit''' button in the<br />
[[Hugin Preview window]] does the same thing.<br />
<br />
Note that some [[Projections]] have a limited field of view, notably:<br />
<br />
* Rectilinear has to be less than 180 degrees both vertically and horizontally.<br />
* Panoramic (cylindrical) has to be less than 180 degrees vertically.<br />
* Stereographic has to be less than 360 degrees both vertically and horizontally.<br />
* Mercator has to be less than 180 degrees vertically.<br />
* Transverse Mercator has to be less than 180 degrees horizontally.<br />
<br />
== Canvas Size ==<br />
<br />
Set the '''width''' and '''height''' of your output panorama in pixels. '''Calculate Optimal Size''' will estimate<br />
a size that has about the same resolution as your input images.<br />
<br />
Some examples: a ''three megapixel'' image has pixel dimensions of 2048 x 1536, an A4 print at 300 pixels per inch will<br />
have a pixel size of 3500 x 2480, a ''full screen'' spherical [[Equirectangular Projection]] image will have pixel<br />
dimensions of 6000 x 3000 or greater and a ''gigapixel'' image has a pixel size of 32768 x 32768.<br />
<br />
Note that the [[interpolation]] used by [[hugin]] doesn't handle downsampling very well, so output images smaller<br />
than about half the size of the ''Optimal Size'' will show [[aliasing]] artefacts. If you want to create high quality<br />
small images, it is better to create an ''Optimal Size'' image in hugin and downsize it later in an image editor such as [[Gimp]].<br />
<br />
== Crop ==<br />
<br />
The crop settings allow just a portion of the panorama to be stitched, there are various reasons to do this:<br />
<br />
* When [[Perspective correction|correcting perspective]] large areas of the panorama output will be empty anyway.<br />
* Large 'gigapixel' style panoramas can be stitched in sections then blended later.<br />
<br />
The cropped-out areas are shown darkened in the [[hugin Preview window]].<br />
<br />
The '''Fit Crop to Images''' button will automatically determine a crop that has a maximum number of pixels and no empty space. This is the same function as the '''Autocrop''' button in the [[Hugin Fast Preview window]]. <br />
<br />
== Output ==<br />
<br />
Hugin can output 'normal' stitched images, [[Exposure fusion|exposure fused]] images or high dynamic range ([[HDR]]) images.<br />
The following options determine which kind of image is created, and allow keeping the intermediate images created during the process.<br />
<br />
=== Normal ===<br />
<br />
If '''Exposure corrected, low dynamic range''' is enabled then [[enblend]] is used for blending. In the final stitching process [[nona]] reprojects and distorts images to fit, '''enblend''' takes these images as individual [[TIFF]] files and merges them using sophisticated seam positioning and blending. Further '''enblend''' settings can be found in the [[hugin Preferences]].<br />
<br />
Enable '''Exposure corrected, low dynamic range''' under '''Remapped Images''' if you want to keep the intermediate images that '''enblend''' uses as input - For example modifying the [[alpha channel]] of these images and then blending manually is one technique for including and excluding people or objects that move between shots.<br />
<br />
=== Exposure fusion ===<br />
<br />
If '''Exposure fused from stacks''' is enabled then hugin will group the input images into exposure stacks by comparing positions, any images with more than 70 % overlap are grouped like this. Each of these [[Bracketing|bracketed]] exposure stacks will be [[Exposure fusion|exposure fused]] with [[enfuse]] and the results seam blended together into a panorama with [[enblend]].<br />
<br />
Note that for this to work, the scene has to be photographed multiple times using exposure [[bracketing]] and the EV exposure values set either manually in the [[hugin Camera and Lens tab]], automatically from [[EXIF]] data or by optimising exposure in the [[hugin Assistant tab]] or [[hugin Exposure tab]].<br />
<br />
Note also that unlike '''Normal''' and '''HDR merging''' options where images are exposure corrected as part of the remapping process, enfuse requires that each exposure layer is supplied uncorrected - Hugin takes care of this automatically and will not apply exposure correction in this case.<br />
<br />
If '''Exposure fused from any arrangement''' is enabled then hugin will seam blend images with similar exposure with [[enblend]] and than it will [[Exposure fusion|exposure fuse]] them using [[enfuse]]. This variant is often much more successful than '''Exposure fused from stacks''' in two situations:<br />
<br />
* Where entire panoramas have been shot at each EV level consecutively rather than each shot [[Bracketing|bracketed]], in this case it isn't guaranteed that shots will line up into the approximate stacks expected by the '''Exposure fused from stacks''' option.<br />
<br />
* When the panorama has been shot entirely on automatic exposure, in this situation it is useful to seam blend adjacent photos with small EV differences, but then exposure fuse larger EV differences - As effectively happens with this option.<br />
<br />
Note that hugin uses a threshold of 0.5 EV exposure difference to determine which photos can be fused into each layer.<br />
<br />
Enable '''Blended layers of similar exposure, without exposure correction''' from '''Layers''' to keep exposure layers from the '''Exposure fused from any arrangement''' step, these are useful for manual [[Contrast Blending]].<br />
<br />
Enable '''No exposure correction, low dynamic range''' from '''Remapped Images''' to keep the intermediate images supplied to [[enblend]] and [[enfuse]].<br />
<br />
Normal '''Format''' can be in one several output file types:<br />
<br />
* '''[[TIFF]]''', various compression options. [[16bit]] and ''8bit'' depth supported. '''None''' compression is supported by most other applications, '''LZW''' compression is common in Windows/Mac applications and '''Deflate''' compression is more common with Linux tools.<br />
* '''[[JPEG|JPG]]''', lossy compression suitable for web/email. '''Quality''' can vary from ''0'' (extremely low quality, small file size) and ''100'' (high quality, large file size). A typical quality setting for web/email would be between ''70'' and ''80''<br />
* '''[[PNG]]''', lossless compression. [[16bit]] and ''8bit'' depth supported.<br />
<br />
=== HDR merging ===<br />
<br />
If '''High dynamic range''' is enabled then hugin will identify likely [[Bracketing|bracketed]] stacks of images, then create remapped [[HDR]] images which are then blended with [[enblend]].<br />
<br />
Note that like the Exposure fusion option above, this generally only makes sense if the scene has been photographed multiple times using exposure bracketing, and the EV exposure values optimised in the [[hugin Exposure tab]].<br />
<br />
Enable '''High dynamic range merged stacks''' from '''Combined stacks''' to keep copies of the remapped HDR images as supplied to enblend.<br />
<br />
Enable '''High dynamic range''' from '''Remapped Images''' to keep copies of each image remapped in linear colour space before merging to HDR.<br />
<br />
Click '''Stitch now!''' to generate output panoramas immediately. Selecting '''Save project and send to batch''' adds the current project to the [[Hugin Batch Processor]] stitching queue, note that the queue won't be processed unless this queue manager is running.<br />
<br />
High dynamic range '''Format''' can be either:<br />
<br />
* ''floating-point'' [[TIFF]], various compression options.<br />
* '''[[OpenEXR|EXR]]''', this is a high dynamic range format which is more compact than a high dynamic range TIFF.<br />
<br />
= Processing =<br />
<br />
[[nona]] is the default '''Remapper''' (stitching engine) supplied with [[hugin]], normally there is no need to<br />
change this or any of the options below.<br />
<br />
Set the '''Interpolator (i)''' to change the sampling [[interpolation]]. You probably won't notice<br />
much difference between the various options except that '''Nearest Neighbour''' is fast but with<br />
very low quality. The default of '''Poly3 (bicubic)''' is generally good for most purposes.<br />
<br />
[[Cropped TIFF]] files are smaller and more efficient because unused parts of the image are not stored in the file. You should<br />
always '''save cropped images''' unless you need to open them in an image editor without [[Cropped TIFF]] support.<br />
<br />
[[enfuse]] is the default for [[Exposure fusion]], '''Options''' are similar to [[enblend]].<br />
<br />
The default '''HDR merger''' is [[hugin_hdrmerge]].<br />
<br />
[[enblend]] is the default '''Blender''' for use with [[hugin]], normally there is no need to change this. Additional command-line '''Options''' can be set here or in the [[hugin Preferences]] for new projects.<br />
<br />
__NOTOC__<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Stitcher_tab&diff=13306Hugin Stitcher tab2011-03-14T21:46:58Z<p>Bruno: /* Processing */ rearrange to match new layout</p>
<hr />
<div>The rest of [[hugin]] is all about setting up the project and aligning images, the '''Stitcher''' tab is where<br />
the final output file is created.<br />
<br />
= Projection =<br />
<br />
Here you can set the output '''[[Projections|Projection]]''' of your project, there are lots<br />
to choose from, each with different advantages and disadvantages:<br />
<br />
* [[Rectilinear Projection|Rectilinear]], this is the same projection as a photo taken with a 'normal' camera and lens. Use this if you are just stitching a handful of photographs together with a narrow [[Field of View]] or [[Perspective correction|correcting perspective]] in a single shot.<br />
* [[Cylindrical Projection|Cylindrical]], actually a simple [[Cylindrical Projection]] as used by traditional rotating panoramic cameras. A good projection for printing a 360 degree panorama, though you may prefer ''Mercator Projection''.<br />
* [[Equirectangular Projection|Equirectangular]], the all purpose format for representing an entire spherical scene. It covers 360 degrees horizontally as well as the [[zenith]] and [[nadir]].<br />
* [[Fisheye Projection|Fisheye]], the same projection as a photo taken with a ''fisheye lens''. Better for representing a wide [[Field of View]] than ''rectilinear'', but in many cases ''Stereographic Projection'' gives less distortion than simple ''fisheye''.<br />
* [[Stereographic Projection|Stereographic]], a ''conformal'' fisheye image. Objects in a stereographic image keep the same shape and show less distortion than simple ''fisheye''.<br />
* [[Projections#mercator projection|Mercator]], a ''conformal'' cylindrical image. A good projection for printing a 360 degree panorama.<br />
* [[Projections#Transverse mercator projection|Trans Mercator]], a ''mercator'' image rotated 90 degrees, suitable for displaying tall or overhead objects.<br />
* [[Projections#sinusoidal projection|Sinusoidal]], an ''equal area'' projection of an entire spherical scene.<br />
* [[Lambert Equal Area Cylindrical Projection|Lambert Cylindrical Equal Area]]<br />
* [[Lambert Equal Area Azimuthal Projection|Lambert Equal Area Azimuthal]]<br />
* [[Albers Equal Area Conic Projection|Albers Equal Area Conic]]<br />
* [[Miller Cylindrical Projection|Miller Cylindrical]]<br />
* [[Panini]]<br />
* [[Architectural]]<br />
* [[Orthographic]]<br />
* [[Equisolid]]<br />
* [[Equirectangular Panini]]<br />
* [[Biplane]]<br />
* [[Triplane]]<br />
* [[The General Panini Projection|Panini General]]<br />
* [[Thoby Projection]]<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical [[Field of View|angle of view]] of the output image,<br />
clicking '''Calculate Field of View''' will shrink or enlarge the field of view of the<br />
output to fit the arrangement of the input images - The '''Fit''' button in the<br />
[[Hugin Preview window]] does the same thing.<br />
<br />
Note that some [[Projections]] have a limited field of view, notably:<br />
<br />
* Rectilinear has to be less than 180 degrees both vertically and horizontally.<br />
* Panoramic (cylindrical) has to be less than 180 degrees vertically.<br />
* Stereographic has to be less than 360 degrees both vertically and horizontally.<br />
* Mercator has to be less than 180 degrees vertically.<br />
* Transverse Mercator has to be less than 180 degrees horizontally.<br />
<br />
== Canvas Size ==<br />
<br />
Set the '''width''' and '''height''' of your output panorama in pixels. '''Calculate Optimal Size''' will estimate<br />
a size that has about the same resolution as your input images.<br />
<br />
Some examples: a ''three megapixel'' image has pixel dimensions of 2048 x 1536, an A4 print at 300 pixels per inch will<br />
have a pixel size of 3500 x 2480, a ''full screen'' spherical [[Equirectangular Projection]] image will have pixel<br />
dimensions of 6000 x 3000 or greater and a ''gigapixel'' image has a pixel size of 32768 x 32768.<br />
<br />
Note that the [[interpolation]] used by [[hugin]] doesn't handle downsampling very well, so output images smaller<br />
than about half the size of the ''Optimal Size'' will show [[aliasing]] artefacts. If you want to create high quality<br />
small images, it is better to create an ''Optimal Size'' image in hugin and downsize it later in an image editor such as [[Gimp]].<br />
<br />
== Crop ==<br />
<br />
The crop settings allow just a portion of the panorama to be stitched, there are various reasons to do this:<br />
<br />
* When [[Perspective correction|correcting perspective]] large areas of the panorama output will be empty anyway.<br />
* Large 'gigapixel' style panoramas can be stitched in sections then blended later.<br />
<br />
The cropped-out areas are shown darkened in the [[hugin Preview window]].<br />
<br />
The '''Fit Crop to Images''' button will automatically determine a crop that has a maximum number of pixels and no empty space. This is the same function as the '''Autocrop''' button in the [[Hugin Fast Preview window]]. <br />
<br />
== Output ==<br />
<br />
Hugin can output 'normal' stitched images, [[Exposure fusion|exposure fused]] images or high dynamic range ([[HDR]]) images.<br />
The following options determine which kind of image is created, and allow keeping the intermediate images created during the process.<br />
<br />
=== Normal ===<br />
<br />
If '''Exposure corrected, low dynamic range''' is enabled then [[enblend]] is used for blending. In the final stitching process [[nona]] reprojects and distorts images to fit, '''enblend''' takes these images as individual [[TIFF]] files and merges them using sophisticated seam positioning and blending. Further '''enblend''' settings can be found in the [[hugin Preferences]].<br />
<br />
Enable '''Exposure corrected, low dynamic range''' under '''Remapped Images''' if you want to keep the intermediate images that '''enblend''' uses as input - For example modifying the [[alpha channel]] of these images and then blending manually is one technique for including and excluding people or objects that move between shots.<br />
<br />
=== Exposure fusion ===<br />
<br />
If '''Exposure fused from stacks''' is enabled then hugin will group the input images into exposure stacks by comparing positions, any images with more than 70 % overlap are grouped like this. Each of these [[Bracketing|bracketed]] exposure stacks will be [[Exposure fusion|exposure fused]] with [[enfuse]] and the results seam blended together into a panorama with [[enblend]].<br />
<br />
Note that for this to work, the scene has to be photographed multiple times using exposure [[bracketing]] and the EV exposure values set either manually in the [[hugin Camera and Lens tab]], automatically from [[EXIF]] data or by optimising exposure in the [[hugin Assistant tab]] or [[hugin Exposure tab]].<br />
<br />
Note also that unlike '''Normal''' and '''HDR merging''' options where images are exposure corrected as part of the remapping process, enfuse requires that each exposure layer is supplied uncorrected - Hugin takes care of this automatically and will not apply exposure correction in this case.<br />
<br />
If '''Exposure fused from any arrangement''' is enabled then hugin will seam blend images with similar exposure with [[enblend]] and than it will [[Exposure fusion|exposure fuse]] them using [[enfuse]]. This variant is often much more successful than '''Exposure fused from stacks''' in two situations:<br />
<br />
* Where entire panoramas have been shot at each EV level consecutively rather than each shot [[Bracketing|bracketed]], in this case it isn't guaranteed that shots will line up into the approximate stacks expected by the '''Exposure fused from stacks''' option.<br />
<br />
* When the panorama has been shot entirely on automatic exposure, in this situation it is useful to seam blend adjacent photos with small EV differences, but then exposure fuse larger EV differences - As effectively happens with this option.<br />
<br />
Note that hugin uses a threshold of 0.5 EV exposure difference to determine which photos can be fused into each layer.<br />
<br />
Enable '''Blended layers of similar exposure, without exposure correction''' from '''Layers''' to keep exposure layers from the '''Exposure fused from any arrangement''' step, these are useful for manual [[Contrast Blending]].<br />
<br />
Enable '''No exposure correction, low dynamic range''' from '''Remapped Images''' to keep the intermediate images supplied to [[enblend]] and [[enfuse]].<br />
<br />
=== HDR merging ===<br />
<br />
If '''High dynamic range''' is enabled then hugin will identify likely [[Bracketing|bracketed]] stacks of images, then create remapped [[HDR]] images which are then blended with [[enblend]].<br />
<br />
Note that like the Exposure fusion option above, this generally only makes sense if the scene has been photographed multiple times using exposure bracketing, and the EV exposure values optimised in the [[hugin Exposure tab]].<br />
<br />
Enable '''High dynamic range merged stacks''' from '''Combined stacks''' to keep copies of the remapped HDR images as supplied to enblend.<br />
<br />
Enable '''High dynamic range''' from '''Remapped Images''' to keep copies of each image remapped in linear colour space before merging to HDR.<br />
<br />
Click '''Stitch now!''' to generate output panoramas immediately. Selecting '''Save project and send to batch''' adds the current project to the [[Hugin Batch Processor]] stitching queue, note that the queue won't be processed unless this queue manager is running.<br />
<br />
= Processing =<br />
<br />
[[nona]] is the default '''Remapper''' (stitching engine) supplied with [[hugin]], normally there is no need to<br />
change this or any of the options below.<br />
<br />
Set the '''Interpolator (i)''' to change the sampling [[interpolation]]. You probably won't notice<br />
much difference between the various options except that '''Nearest Neighbour''' is fast but with<br />
very low quality. The default of '''Poly3 (bicubic)''' is generally good for most purposes.<br />
<br />
[[Cropped TIFF]] files are smaller and more efficient because unused parts of the image are not stored in the file. You should<br />
always '''save cropped images''' unless you need to open them in an image editor without [[Cropped TIFF]] support.<br />
<br />
[[enfuse]] is the default for [[Exposure fusion]], '''Options''' are similar to [[enblend]].<br />
<br />
The default '''HDR merger''' is [[hugin_hdrmerge]].<br />
<br />
[[enblend]] is the default '''Blender''' for use with [[hugin]], normally there is no need to change this. Additional command-line '''Options''' can be set here or in the [[hugin Preferences]] for new projects.<br />
<br />
== File formats ==<br />
<br />
'''Normal Output''' can be in one several formats:<br />
<br />
* '''[[TIFF]]''', various compression options. [[16bit]] and ''8bit'' depth supported. '''None''' compression is supported by most other applications, '''LZW''' compression is common in Windows/Mac applications and '''Deflate''' compression is more common with Linux tools.<br />
* '''[[JPEG|JPG]]''', lossy compression suitable for web/email. '''Quality''' can vary from ''0'' (extremely low quality, small file size) and ''100'' (high quality, large file size). A typical quality setting for web/email would be between ''70'' and ''80''<br />
* '''[[PNG]]''', lossless compression. [[16bit]] and ''8bit'' depth supported.<br />
<!-- * '''[[OpenEXR|EXR]]''', not sure what use this is doing here (TODO). -- not there as of 0.7.0 --><br />
<br />
::''Note that some versions of enblend doesn't support all output formats; as an example some Linux enblend versions will probably fail unless you choose '''TIFF'''.''<br />
<br />
'''HDR Output''' can be either:<br />
<br />
* ''floating-point'' [[TIFF]], various compression options.<br />
* '''[[OpenEXR|EXR]]''', this is a high dynamic range format which is more compact than a high dynamic range TIFF.<br />
<br />
__NOTOC__<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Stitcher_tab&diff=13305Hugin Stitcher tab2011-03-14T21:42:28Z<p>Bruno: /* s/Panorama/Projection/ */</p>
<hr />
<div>The rest of [[hugin]] is all about setting up the project and aligning images, the '''Stitcher''' tab is where<br />
the final output file is created.<br />
<br />
= Projection =<br />
<br />
Here you can set the output '''[[Projections|Projection]]''' of your project, there are lots<br />
to choose from, each with different advantages and disadvantages:<br />
<br />
* [[Rectilinear Projection|Rectilinear]], this is the same projection as a photo taken with a 'normal' camera and lens. Use this if you are just stitching a handful of photographs together with a narrow [[Field of View]] or [[Perspective correction|correcting perspective]] in a single shot.<br />
* [[Cylindrical Projection|Cylindrical]], actually a simple [[Cylindrical Projection]] as used by traditional rotating panoramic cameras. A good projection for printing a 360 degree panorama, though you may prefer ''Mercator Projection''.<br />
* [[Equirectangular Projection|Equirectangular]], the all purpose format for representing an entire spherical scene. It covers 360 degrees horizontally as well as the [[zenith]] and [[nadir]].<br />
* [[Fisheye Projection|Fisheye]], the same projection as a photo taken with a ''fisheye lens''. Better for representing a wide [[Field of View]] than ''rectilinear'', but in many cases ''Stereographic Projection'' gives less distortion than simple ''fisheye''.<br />
* [[Stereographic Projection|Stereographic]], a ''conformal'' fisheye image. Objects in a stereographic image keep the same shape and show less distortion than simple ''fisheye''.<br />
* [[Projections#mercator projection|Mercator]], a ''conformal'' cylindrical image. A good projection for printing a 360 degree panorama.<br />
* [[Projections#Transverse mercator projection|Trans Mercator]], a ''mercator'' image rotated 90 degrees, suitable for displaying tall or overhead objects.<br />
* [[Projections#sinusoidal projection|Sinusoidal]], an ''equal area'' projection of an entire spherical scene.<br />
* [[Lambert Equal Area Cylindrical Projection|Lambert Cylindrical Equal Area]]<br />
* [[Lambert Equal Area Azimuthal Projection|Lambert Equal Area Azimuthal]]<br />
* [[Albers Equal Area Conic Projection|Albers Equal Area Conic]]<br />
* [[Miller Cylindrical Projection|Miller Cylindrical]]<br />
* [[Panini]]<br />
* [[Architectural]]<br />
* [[Orthographic]]<br />
* [[Equisolid]]<br />
* [[Equirectangular Panini]]<br />
* [[Biplane]]<br />
* [[Triplane]]<br />
* [[The General Panini Projection|Panini General]]<br />
* [[Thoby Projection]]<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical [[Field of View|angle of view]] of the output image,<br />
clicking '''Calculate Field of View''' will shrink or enlarge the field of view of the<br />
output to fit the arrangement of the input images - The '''Fit''' button in the<br />
[[Hugin Preview window]] does the same thing.<br />
<br />
Note that some [[Projections]] have a limited field of view, notably:<br />
<br />
* Rectilinear has to be less than 180 degrees both vertically and horizontally.<br />
* Panoramic (cylindrical) has to be less than 180 degrees vertically.<br />
* Stereographic has to be less than 360 degrees both vertically and horizontally.<br />
* Mercator has to be less than 180 degrees vertically.<br />
* Transverse Mercator has to be less than 180 degrees horizontally.<br />
<br />
== Canvas Size ==<br />
<br />
Set the '''width''' and '''height''' of your output panorama in pixels. '''Calculate Optimal Size''' will estimate<br />
a size that has about the same resolution as your input images.<br />
<br />
Some examples: a ''three megapixel'' image has pixel dimensions of 2048 x 1536, an A4 print at 300 pixels per inch will<br />
have a pixel size of 3500 x 2480, a ''full screen'' spherical [[Equirectangular Projection]] image will have pixel<br />
dimensions of 6000 x 3000 or greater and a ''gigapixel'' image has a pixel size of 32768 x 32768.<br />
<br />
Note that the [[interpolation]] used by [[hugin]] doesn't handle downsampling very well, so output images smaller<br />
than about half the size of the ''Optimal Size'' will show [[aliasing]] artefacts. If you want to create high quality<br />
small images, it is better to create an ''Optimal Size'' image in hugin and downsize it later in an image editor such as [[Gimp]].<br />
<br />
== Crop ==<br />
<br />
The crop settings allow just a portion of the panorama to be stitched, there are various reasons to do this:<br />
<br />
* When [[Perspective correction|correcting perspective]] large areas of the panorama output will be empty anyway.<br />
* Large 'gigapixel' style panoramas can be stitched in sections then blended later.<br />
<br />
The cropped-out areas are shown darkened in the [[hugin Preview window]].<br />
<br />
The '''Fit Crop to Images''' button will automatically determine a crop that has a maximum number of pixels and no empty space. This is the same function as the '''Autocrop''' button in the [[Hugin Fast Preview window]]. <br />
<br />
== Output ==<br />
<br />
Hugin can output 'normal' stitched images, [[Exposure fusion|exposure fused]] images or high dynamic range ([[HDR]]) images.<br />
The following options determine which kind of image is created, and allow keeping the intermediate images created during the process.<br />
<br />
=== Normal ===<br />
<br />
If '''Exposure corrected, low dynamic range''' is enabled then [[enblend]] is used for blending. In the final stitching process [[nona]] reprojects and distorts images to fit, '''enblend''' takes these images as individual [[TIFF]] files and merges them using sophisticated seam positioning and blending. Further '''enblend''' settings can be found in the [[hugin Preferences]].<br />
<br />
Enable '''Exposure corrected, low dynamic range''' under '''Remapped Images''' if you want to keep the intermediate images that '''enblend''' uses as input - For example modifying the [[alpha channel]] of these images and then blending manually is one technique for including and excluding people or objects that move between shots.<br />
<br />
=== Exposure fusion ===<br />
<br />
If '''Exposure fused from stacks''' is enabled then hugin will group the input images into exposure stacks by comparing positions, any images with more than 70 % overlap are grouped like this. Each of these [[Bracketing|bracketed]] exposure stacks will be [[Exposure fusion|exposure fused]] with [[enfuse]] and the results seam blended together into a panorama with [[enblend]].<br />
<br />
Note that for this to work, the scene has to be photographed multiple times using exposure [[bracketing]] and the EV exposure values set either manually in the [[hugin Camera and Lens tab]], automatically from [[EXIF]] data or by optimising exposure in the [[hugin Assistant tab]] or [[hugin Exposure tab]].<br />
<br />
Note also that unlike '''Normal''' and '''HDR merging''' options where images are exposure corrected as part of the remapping process, enfuse requires that each exposure layer is supplied uncorrected - Hugin takes care of this automatically and will not apply exposure correction in this case.<br />
<br />
If '''Exposure fused from any arrangement''' is enabled then hugin will seam blend images with similar exposure with [[enblend]] and than it will [[Exposure fusion|exposure fuse]] them using [[enfuse]]. This variant is often much more successful than '''Exposure fused from stacks''' in two situations:<br />
<br />
* Where entire panoramas have been shot at each EV level consecutively rather than each shot [[Bracketing|bracketed]], in this case it isn't guaranteed that shots will line up into the approximate stacks expected by the '''Exposure fused from stacks''' option.<br />
<br />
* When the panorama has been shot entirely on automatic exposure, in this situation it is useful to seam blend adjacent photos with small EV differences, but then exposure fuse larger EV differences - As effectively happens with this option.<br />
<br />
Note that hugin uses a threshold of 0.5 EV exposure difference to determine which photos can be fused into each layer.<br />
<br />
Enable '''Blended layers of similar exposure, without exposure correction''' from '''Layers''' to keep exposure layers from the '''Exposure fused from any arrangement''' step, these are useful for manual [[Contrast Blending]].<br />
<br />
Enable '''No exposure correction, low dynamic range''' from '''Remapped Images''' to keep the intermediate images supplied to [[enblend]] and [[enfuse]].<br />
<br />
=== HDR merging ===<br />
<br />
If '''High dynamic range''' is enabled then hugin will identify likely [[Bracketing|bracketed]] stacks of images, then create remapped [[HDR]] images which are then blended with [[enblend]].<br />
<br />
Note that like the Exposure fusion option above, this generally only makes sense if the scene has been photographed multiple times using exposure bracketing, and the EV exposure values optimised in the [[hugin Exposure tab]].<br />
<br />
Enable '''High dynamic range merged stacks''' from '''Combined stacks''' to keep copies of the remapped HDR images as supplied to enblend.<br />
<br />
Enable '''High dynamic range''' from '''Remapped Images''' to keep copies of each image remapped in linear colour space before merging to HDR.<br />
<br />
Click '''Stitch now!''' to generate output panoramas immediately. Selecting '''Save project and send to batch''' adds the current project to the [[Hugin Batch Processor]] stitching queue, note that the queue won't be processed unless this queue manager is running.<br />
<br />
= Processing =<br />
<br />
[[nona]] is the default '''Remapper''' (stitching engine) supplied with [[hugin]], normally there is no need to<br />
change this or any of the options below.<br />
<br />
Set the '''Interpolator (i)''' to change the sampling [[interpolation]]. You probably won't notice<br />
much difference between the various options except that '''Nearest Neighbour''' is fast but with<br />
very low quality. The default of '''Poly3 (bicubic)''' is generally good for most purposes.<br />
<br />
[[Cropped TIFF]] files are smaller and more efficient because unused parts of the image are not stored in the file. You should<br />
always '''save cropped images''' unless you need to open them in an image editor without [[Cropped TIFF]] support.<br />
<br />
[[enblend]] is the default '''Blender''' for use with [[hugin]], normally there is no need to change this. Additional command-line '''Options''' can be set here or in the [[hugin Preferences]] for new projects.<br />
<br />
[[enfuse]] is the default for [[Exposure fusion]], '''Options''' are similar to [[enblend]].<br />
<br />
== File formats ==<br />
<br />
'''Normal Output''' can be in one several formats:<br />
<br />
* '''[[TIFF]]''', various compression options. [[16bit]] and ''8bit'' depth supported. '''None''' compression is supported by most other applications, '''LZW''' compression is common in Windows/Mac applications and '''Deflate''' compression is more common with Linux tools.<br />
* '''[[JPEG|JPG]]''', lossy compression suitable for web/email. '''Quality''' can vary from ''0'' (extremely low quality, small file size) and ''100'' (high quality, large file size). A typical quality setting for web/email would be between ''70'' and ''80''<br />
* '''[[PNG]]''', lossless compression. [[16bit]] and ''8bit'' depth supported.<br />
<!-- * '''[[OpenEXR|EXR]]''', not sure what use this is doing here (TODO). -- not there as of 0.7.0 --><br />
<br />
::''Note that some versions of enblend doesn't support all output formats; as an example some Linux enblend versions will probably fail unless you choose '''TIFF'''.''<br />
<br />
'''HDR Output''' can be either:<br />
<br />
* ''floating-point'' [[TIFF]], various compression options.<br />
* '''[[OpenEXR|EXR]]''', this is a high dynamic range format which is more compact than a high dynamic range TIFF.<br />
<br />
__NOTOC__<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Fast_Preview_window&diff=13304Hugin Fast Preview window2011-03-14T21:28:05Z<p>Bruno: /* Image:Fast_preview_icon_drag.svg Move/Drag tab */</p>
<hr />
<div>= Distinction =<br />
<br />
Like the more accurate [[Hugin Preview window]], the fast preview shows something similar to the final stitched output, but with a few important differences:<br />
<br />
* The window features a row of tabs at the top, clicking on a tab switches between modes that allow you to interact with the panorama in different ways.<br />
* Reduced resolution input images are used, so some areas can appear blurred that will be sharp in the final output.<br />
* Seams are not created, images are simply overlaid with the first image at the bottom of the stack and the last at the top.<br />
* Blending by a tool such as [[enblend]] isn't shown.<br />
* The brightness display of [[HDR]] and 16bit images is controlled by settings in the hugin Preferences, these settings are not used when stitching. The colouring of these images will also be inaccurate when using exposure or white balance correction. For HDR panoramas, the [[Hugin Preview window]] is recommended instead.<br />
* Only the first photo from each stack is visible (the others are hidden behind), if you want to see the combined stack then use the HDR mode of the [[Hugin Preview window]] instead.<br />
* Photometric correction only includes white balance and exposure, unless full photometric correction is enabled with the the Photometrics button.<br />
* The remappings are approximate, the output by a tool such as [[nona]] is more accurate. If this concerns you more than speed, use the [[Hugin Preview window]] instead.<br />
* It's much faster ;-)<br />
<br />
= General features =<br />
<br />
== Overview ==<br />
<br />
[[image:hugin-2011.0_fpw_overview.png|thumb|200px|left|Screenshot of docked Overview in Panosphere mode]]<br />
The '''Overview''' introduced in Hugin 2011.0 represents an interactive preview of the panorama.<br />
<br />
Just click the button 'Show/Hide' to toggle the display the docked Overview window. Zoom it by dragging the handle located at the center of the border to the preview canvas.<br />
<br />
The 'Grid' checkbox can be used to toggle the grid overlay in both overview and the preview canvas.<br />
<br />
Clicking the small pin icon in the header of the docked Overview area (or dragging the Overview title bar) will switch to a floating window instead. To put that floating window back in a docked position just drag it in either the top, bottom, left or right boundary of the preview's actual image area.<br />
<br />
The default mode is a Panosphere to display typical panoramas and can be used to e.g. easily check for errors in the nadir or zenith regions.<br />
{{clr}}<br />
<br />
== Displayed images ==<br />
<br />
Every input image in the preview has ''toggle'' button where display can be disabled or enabled.<br />
<br />
In addition, this display also controls the behaviour of the [[hugin Optimizer tab]] and the [[hugin Stitcher tab]] - Any photos disabled here are not used in optimisation or stitching.<br />
<br />
=== [[Image:Hugin_preview_show_all.png]] All ===<br />
<br />
By default all input images are shown in the preview, however individual images can be enabled and disabled in the<br />
'''Displayed images''' section. Use the '''All''' button to return to the default and display all the images.<br />
<br />
=== [[Image:Hugin_preview_show_none.png]] None ===<br />
<br />
Similarly, hide all images with the '''None''' button, use this if you want to enable preview images one by one.<br />
<br />
== Preview canvas ==<br />
<br />
The image window itself shows a representation of the final stitched output panorama, use the scroll bars<br />
to change the horizontal and vertical [[Field of View]].<br />
<br />
To toggle the grid use the checkbox ''Grid'' in the Overview window.<br />
<br />
<br />
= Preview tab =<br />
<br />
== [[Image:Fast_preview_icon_identify.svg]] Identify ==<br />
<br />
Using this tool you can find where your images are, and match them to their number. You can also edit control points.<br />
<br />
When this tool is turned on, move the mouse over the visibility buttons for the images (the numbers at the top of the preview). The image with the number on the button under the mouse lights up red in the preview. Moving the mouse over the panorama highlights all the images under the mouse in different colours. The buttons for those images lights up in matching colours.<br />
<br />
When the mouse is on the overlap of two images, click to edit the control points between those images.<br />
<br />
== [[Image:Fast_preview_icon_photometric.svg]] Photometrics ==<br />
<br />
Enables full photometric correction. When turned on, this will cause significant delay when changing photometric parameters. It also takes a while to turn on and off. However, with it enabled you get much better representation of the colours in the output. With it turned off, you get correction only for exposure and white balance. With it turned on, you also get vignetting and colour response correction. The [[Hugin Preview window]] does all these things by default, so you may wish to use that instead.<br />
<br />
== [[Image:Show_Control_Points_Button.svg]] Show control points ==<br />
<br />
When this tool is turned on, all [[Control points]] are drawn as lines with crosses at each end. Green, yellow, orange, and red lines and their crosses indicate 'normal' control points. A red control point is misaligned (the ends of the line are father apart), and a green control point is well aligned (the ends of the line are almost in the same position). Blue indicates [[horizontal control points]], [[vertical control points]] or [[straight line control points]].<br />
<br />
== Blend mode ==<br />
<br />
The ''normal'' blend mode will draw the images with the first photos in the project above later photos as this approximates the order that blending is performed.. The ''difference'' blend mode will do the same, except the image under the mouse pointer will be subtracted from the rest of the stack. Use this to determine if the alignment went well: where you can see edges in the subtracted image, these edges are misaligned. Be warned that this isn't fully accurate, the other preview has a better difference mode.<br />
<br />
== EV ==<br />
<br />
'''EV''' stands for ''Exposure Value'', clicking the '''Reset''' button will set it to the average of all<br />
the input image exposures or setting it to '''0''' (zero)<br />
will result in no exposure change being applied to the panorama (note that unless all the photos also have their individual EV set to zero in the [[Hugin Camera and Lens tab]] they will likely appear incredibly bright or dark).<br />
<br />
'''EV''' is a standard photographic scale, each increase or decrease by one unit will change the exposure by<br />
the equivalent of one ''f-stop'' (ie. halving or doubling the exposure). It is worth adjusting the exposure<br />
here in [[hugin]] rather than later in an external image editor, since '''hugin''' uses the [[camera response curve]]<br />
calculated in the [[hugin Exposure tab]] to perform the correction in a ''linear'' colour space.<br />
<br />
The average value isn't always wanted. If you see colour artefacts in bright sky areas, set this<br />
to the negative of the darkest input image - This has a side-effect of clipping brighter images.<br />
<br />
== Grey Picker ==<br />
<br />
Hugin can align the white balance ([[w:Color balance]]) of the photos in the panorama to match that of the ''anchor'' photo, this is done when optimising '''White Balance''' in the [[Hugin Exposure tab]] or when you use the '''Align...''' button in the [[Hugin Assistant tab]] - Usually this ''anchor'' is the first photo in the project, but it can be changed using '''anchor this image for exposure''' in the [[Hugin Images tab]].<br />
<br />
However, often the first photo, or even none of the photos, in the project has the wanted white balance. You can use the '''Grey Picker''' button to adjust the white balance of the whole panorama by using any 'neutral' colour object in the scene as a sample. Just push the button and then click on the object in the preview canvas.<br />
<br />
An ideal neutral colour object is white or grey, this could be a test card, an overcast sky, snow, or a white object - It is important to remember that white paint and paper comes in lots of colour shades so it really isn't very reliable, prefer a transparent material that is white due to light diffusion such as etched glass or polystyrene foam. Avoid objects that are 'blown out', or which are in shade and illuminated only by secondary light sources in the scene.<br />
<br />
= [[Image:preview_layout.svg]]Layout tab =<br />
The Layout tab shows the entire project as a diagram with colour-coded lines connecting each of the photographs.<br />
<br />
[[File:layout-small.png]]<br />
<br />
Green lines connecting images show the control points have a small error, red lines show a large error. Grey lines show no control points connecting the images.<br />
<br />
You can see where the project is OK and where there are problems if it isn't quite right. Just click on any connection and Hugin jumps to the Control Points tab to edit that pair of photos.<br />
<br />
Use the '''Scale''' slider to change the size of the photo thumbnails, this only effects the Layout display and won't change the final panorama.<br />
<br />
= Projection tab =<br />
<br />
This tab is for adjusting [[Projections|projection]] of the panorama, some projections have adjustable parameters which will appear when selected.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical angle of view of the output image.<br />
<br />
== Projection ==<br />
<br />
Use the drop down list to change the output projection of the panorama, the list is exactly the same as that<br />
in the [[hugin Stitcher tab]]. Note that for some projections, the scroll-bar sliders to change the<br />
[[Field of View]] are disabled. If you are having trouble, switch to [[Equirectangular Projection]], adjust<br />
the field of view and switch back.<br />
<br />
= [[Image:Fast_preview_icon_drag.svg]] Move/Drag tab =<br />
<br />
Using this tool you can recentre the panorama interactively. With it turned on, try the following:<br />
* Drag the panorama with the left mouse button to rotate the panorama's images. The centre of rotation is the point where you pushed the mouse button down.<br />
* Hold shift when doing the above to constrain movement to yaw or pitch. Note pitch is affected by the centre of rotation.<br />
* Drag the panorama with the right mouse button or hold control and drag with the left to roll the panorama (rotate around the middle)<br />
<br />
If the panorama contains unconnected components (i.e. not connected by [[control points]]), they will move individually. There is also an '''Individual''' Drag mode, see below.<br />
<br />
== Drag mode ==<br />
This determines what parameters that are changed when the images are dragged.<br />
* '''Normal''' - When dragged left-right, the yaw parameter is changed and when dragged up-down the pitch parameter is changed. I.e. the camera is tilted in the yaw and pitch angles.<br />
* '''Normal, individual''' - Adds checkboxes to the '''displayed images''' buttons, here you can select which images to drag individually or together. With this mode selected the control point connections between photos are ignored.<br />
* '''Mosaic''' - When dragged left-right, X parameter is changed and when dragged up-down the Y parameter is changed. I.e. the camera is moved in the X and Y dimensions.<br />
* '''Mosaic, individual''' - Allows selected photos to be dragged in mosaic mode.<br />
<br />
== [[Image:Hugin_center_pano.png]] Center ==<br />
<br />
This button horizontally ''pans'' the output, changing the [[yaw]] of the remapped images so they fit to the centre of the output frame. This is useful if there is a lot of black space on the left or right of the output. This also performs a '''Fit''', equivalent to the next button.<br />
<br />
Note that centering a [[Rectilinear Projection]] or [[Fisheye Projection]] panorama will change the perspective, this may be unwanted.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== [[Image:Hugin_straighten_pano.png]] Straighten ==<br />
<br />
Straightening the panorama optimises the [[roll]] and [[pitch]] of the input images without changing their relative positions, levelling the panorama in the process. This normally produces good results, if you need more accurate positioning, try adding [[vertical control points]] in the [[hugin Control Points tab]] and reoptimise.<br />
<br />
== Numeric Transform ==<br />
<br />
Enter a '''numerical transform''' to rotate the input images without changing their relative positions - Effectively this rotates the entire panorama. Enter [[roll]], [[pitch]] and [[yaw]] values in degrees.<br />
<br />
= [[Image:Fast_preview_icon_crop.svg]] Crop tab =<br />
<br />
Using this tool you can set the output cropping region interactively. To do this precisely instead, use the [[Hugin Stitcher tab| Stitcher tab]]. Initially, the entire panorama is in the output region (i.e. nothing is cropped).<br />
<br />
To change the cropping at each edge, move the mouse towards that edge until a white box appears along it, then drag with the left mouse button until the edge is where you want it. The darker areas represent the region that is cropped off. You can move two edges at once by moving the mouse towards the corner shared by the edges until both white boxes appear. If you wish to move the whole region at once, move the mouse into the middle so that all four edges have boxes along them and drag.<br />
<br />
== [[Image:Fast_preview_icon_autocrop.svg]] Autocrop ==<br />
<br />
The autocrop button adjusts the crop rectangle so that it is entirely within the image area, i.e. there will be no 'black' borders in the final stitched image. It does this by maximising the area of the rectangle rather than the width or height.<br />
<br />
= In practice =<br />
[[Image:Fast_preview_guide_start.png | thumb | A panorama with unconnected image groups after optimisation.]]<br />
Let's try using this preview to help with a panorama where automatic alignment failed. This panorama was taken where a lot of things were blowing around in the wind, and the clouds were changing quickly, so it is not surprising that it aligning it is a struggle. The [[Hugin Assistant tab|Assistant tab]] tells us there are multiple unconnected image groups. We can optimise the panorama and end up with a images correctly positioned amongst the group they are in, but the groups themselves are not aligned. Try this first. <br />
<br />
[[Image:Fast_preview_guide_drag.png | thumb | Dragging images with the drag tool.]]<br />
Using the Drag tool, we can roughly align the groups together:<br />
# Turn on the tool with the ''Drag'' button.<br />
# Drag each component so the horizon is in the middle, using the left mouse button.<br />
# Drag with the right mouse button (or hold control and drag with the left) to level the horizon.[[Image:Fast_preview_guide_rotate_drag.png | thumb | Rotating images with the drag tool.]]<br />
# Hold shift and drag with the left mouse button sideways to approximately line up the image with the other groups.<br />
<br />
[[Image:Fast_preview_guide_identify.png | thumb | Two images highlighted in the preview window.]]<br />
When we have the images in approximately the right position, we can begin placing control points to guide the optimiser. The Identify tool lends a hand here. Firstly, turn on the identify tool. Move the mouse on an overlap that was recently created between two image groups. The images in the overlap light up. Move the mouse to a place where there is only two images in that overlap, and click. The two images are opened in the [[Hugin Control Points tab|control point editor]] (there may be a short pause while the images are loaded). Once you have placed control points manually, you can return to the preview to find some more image pairs.<br />
<br />
[[Image:Fast_preview_guide_crop.png | thumb | Adjusting the cropping region.]]<br />
When you are happy that your panorama contains sufficient control points, optimise it again. The panorama will likely have the horizon at the wrong angle, in this case press ''Straighten'' on the preview window. You can then frame the panorama using the drag tool (hold shift so you don't make it wonky again!). Use your artistic judgement here. If you want to crop your panorama, click ''Crop'' and drag the edges of the cropping rectangle.<br />
<br />
[[Category:Software:Hugin]]<br />
[[Category:Tutorial:Nice to know]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Fast_Preview_window&diff=13303Hugin Fast Preview window2011-03-14T21:15:00Z<p>Bruno: /* Image:preview_layout.svgLayout tab */</p>
<hr />
<div>= Distinction =<br />
<br />
Like the more accurate [[Hugin Preview window]], the fast preview shows something similar to the final stitched output, but with a few important differences:<br />
<br />
* The window features a row of tabs at the top, clicking on a tab switches between modes that allow you to interact with the panorama in different ways.<br />
* Reduced resolution input images are used, so some areas can appear blurred that will be sharp in the final output.<br />
* Seams are not created, images are simply overlaid with the first image at the bottom of the stack and the last at the top.<br />
* Blending by a tool such as [[enblend]] isn't shown.<br />
* The brightness display of [[HDR]] and 16bit images is controlled by settings in the hugin Preferences, these settings are not used when stitching. The colouring of these images will also be inaccurate when using exposure or white balance correction. For HDR panoramas, the [[Hugin Preview window]] is recommended instead.<br />
* Only the first photo from each stack is visible (the others are hidden behind), if you want to see the combined stack then use the HDR mode of the [[Hugin Preview window]] instead.<br />
* Photometric correction only includes white balance and exposure, unless full photometric correction is enabled with the the Photometrics button.<br />
* The remappings are approximate, the output by a tool such as [[nona]] is more accurate. If this concerns you more than speed, use the [[Hugin Preview window]] instead.<br />
* It's much faster ;-)<br />
<br />
= General features =<br />
<br />
== Overview ==<br />
<br />
[[image:hugin-2011.0_fpw_overview.png|thumb|200px|left|Screenshot of docked Overview in Panosphere mode]]<br />
The '''Overview''' introduced in Hugin 2011.0 represents an interactive preview of the panorama.<br />
<br />
Just click the button 'Show/Hide' to toggle the display the docked Overview window. Zoom it by dragging the handle located at the center of the border to the preview canvas.<br />
<br />
The 'Grid' checkbox can be used to toggle the grid overlay in both overview and the preview canvas.<br />
<br />
Clicking the small pin icon in the header of the docked Overview area (or dragging the Overview title bar) will switch to a floating window instead. To put that floating window back in a docked position just drag it in either the top, bottom, left or right boundary of the preview's actual image area.<br />
<br />
The default mode is a Panosphere to display typical panoramas and can be used to e.g. easily check for errors in the nadir or zenith regions.<br />
{{clr}}<br />
<br />
== Displayed images ==<br />
<br />
Every input image in the preview has ''toggle'' button where display can be disabled or enabled.<br />
<br />
In addition, this display also controls the behaviour of the [[hugin Optimizer tab]] and the [[hugin Stitcher tab]] - Any photos disabled here are not used in optimisation or stitching.<br />
<br />
=== [[Image:Hugin_preview_show_all.png]] All ===<br />
<br />
By default all input images are shown in the preview, however individual images can be enabled and disabled in the<br />
'''Displayed images''' section. Use the '''All''' button to return to the default and display all the images.<br />
<br />
=== [[Image:Hugin_preview_show_none.png]] None ===<br />
<br />
Similarly, hide all images with the '''None''' button, use this if you want to enable preview images one by one.<br />
<br />
== Preview canvas ==<br />
<br />
The image window itself shows a representation of the final stitched output panorama, use the scroll bars<br />
to change the horizontal and vertical [[Field of View]].<br />
<br />
To toggle the grid use the checkbox ''Grid'' in the Overview window.<br />
<br />
<br />
= Preview tab =<br />
<br />
== [[Image:Fast_preview_icon_identify.svg]] Identify ==<br />
<br />
Using this tool you can find where your images are, and match them to their number. You can also edit control points.<br />
<br />
When this tool is turned on, move the mouse over the visibility buttons for the images (the numbers at the top of the preview). The image with the number on the button under the mouse lights up red in the preview. Moving the mouse over the panorama highlights all the images under the mouse in different colours. The buttons for those images lights up in matching colours.<br />
<br />
When the mouse is on the overlap of two images, click to edit the control points between those images.<br />
<br />
== [[Image:Fast_preview_icon_photometric.svg]] Photometrics ==<br />
<br />
Enables full photometric correction. When turned on, this will cause significant delay when changing photometric parameters. It also takes a while to turn on and off. However, with it enabled you get much better representation of the colours in the output. With it turned off, you get correction only for exposure and white balance. With it turned on, you also get vignetting and colour response correction. The [[Hugin Preview window]] does all these things by default, so you may wish to use that instead.<br />
<br />
== [[Image:Show_Control_Points_Button.svg]] Show control points ==<br />
<br />
When this tool is turned on, all [[Control points]] are drawn as lines with crosses at each end. Green, yellow, orange, and red lines and their crosses indicate 'normal' control points. A red control point is misaligned (the ends of the line are father apart), and a green control point is well aligned (the ends of the line are almost in the same position). Blue indicates [[horizontal control points]], [[vertical control points]] or [[straight line control points]].<br />
<br />
== Blend mode ==<br />
<br />
The ''normal'' blend mode will draw the images with the first photos in the project above later photos as this approximates the order that blending is performed.. The ''difference'' blend mode will do the same, except the image under the mouse pointer will be subtracted from the rest of the stack. Use this to determine if the alignment went well: where you can see edges in the subtracted image, these edges are misaligned. Be warned that this isn't fully accurate, the other preview has a better difference mode.<br />
<br />
== EV ==<br />
<br />
'''EV''' stands for ''Exposure Value'', clicking the '''Reset''' button will set it to the average of all<br />
the input image exposures or setting it to '''0''' (zero)<br />
will result in no exposure change being applied to the panorama (note that unless all the photos also have their individual EV set to zero in the [[Hugin Camera and Lens tab]] they will likely appear incredibly bright or dark).<br />
<br />
'''EV''' is a standard photographic scale, each increase or decrease by one unit will change the exposure by<br />
the equivalent of one ''f-stop'' (ie. halving or doubling the exposure). It is worth adjusting the exposure<br />
here in [[hugin]] rather than later in an external image editor, since '''hugin''' uses the [[camera response curve]]<br />
calculated in the [[hugin Exposure tab]] to perform the correction in a ''linear'' colour space.<br />
<br />
The average value isn't always wanted. If you see colour artefacts in bright sky areas, set this<br />
to the negative of the darkest input image - This has a side-effect of clipping brighter images.<br />
<br />
== Grey Picker ==<br />
<br />
Hugin can align the white balance ([[w:Color balance]]) of the photos in the panorama to match that of the ''anchor'' photo, this is done when optimising '''White Balance''' in the [[Hugin Exposure tab]] or when you use the '''Align...''' button in the [[Hugin Assistant tab]] - Usually this ''anchor'' is the first photo in the project, but it can be changed using '''anchor this image for exposure''' in the [[Hugin Images tab]].<br />
<br />
However, often the first photo, or even none of the photos, in the project has the wanted white balance. You can use the '''Grey Picker''' button to adjust the white balance of the whole panorama by using any 'neutral' colour object in the scene as a sample. Just push the button and then click on the object in the preview canvas.<br />
<br />
An ideal neutral colour object is white or grey, this could be a test card, an overcast sky, snow, or a white object - It is important to remember that white paint and paper comes in lots of colour shades so it really isn't very reliable, prefer a transparent material that is white due to light diffusion such as etched glass or polystyrene foam. Avoid objects that are 'blown out', or which are in shade and illuminated only by secondary light sources in the scene.<br />
<br />
= [[Image:preview_layout.svg]]Layout tab =<br />
The Layout tab shows the entire project as a diagram with colour-coded lines connecting each of the photographs.<br />
<br />
[[File:layout-small.png]]<br />
<br />
Green lines connecting images show the control points have a small error, red lines show a large error. Grey lines show no control points connecting the images.<br />
<br />
You can see where the project is OK and where there are problems if it isn't quite right. Just click on any connection and Hugin jumps to the Control Points tab to edit that pair of photos.<br />
<br />
Use the '''Scale''' slider to change the size of the photo thumbnails, this only effects the Layout display and won't change the final panorama.<br />
<br />
= Projection tab =<br />
<br />
This tab is for adjusting [[Projections|projection]] of the panorama, some projections have adjustable parameters which will appear when selected.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical angle of view of the output image.<br />
<br />
== Projection ==<br />
<br />
Use the drop down list to change the output projection of the panorama, the list is exactly the same as that<br />
in the [[hugin Stitcher tab]]. Note that for some projections, the scroll-bar sliders to change the<br />
[[Field of View]] are disabled. If you are having trouble, switch to [[Equirectangular Projection]], adjust<br />
the field of view and switch back.<br />
<br />
= [[Image:Fast_preview_icon_drag.svg]] Move/Drag tab =<br />
<br />
Using this tool you can recentre the panorama interactively. With it turned on, try the following:<br />
* Drag the panorama with the left mouse button to rotate the panorama's images. The centre of rotation is the point where you pushed the mouse button down.<br />
* Hold shift when doing the above to constrain movement to yaw or pitch. Note pitch is affected by the centre of rotation.<br />
* Drag the panorama with the right mouse button or hold control and drag with the left to roll the panorama (rotate around the middle)<br />
<br />
If the panorama contains unconnected components, they will move individually.<br />
<br />
== Drag mode ==<br />
This determines what parameters that are changed when the images are dragged.<br />
* Normal - When dragged left-right, the yaw parameter is changed and when dragged up-down the pitch parameter is changed. I.e. the camera is tilted in the yaw and pitch angles.<br />
* Mosaic - When dragged left-right, X parameter is changed and when dragged up-down the Y parameter is changed. I.e. the camera is moved in the X and Y dimensions.<br />
<br />
== [[Image:Hugin_center_pano.png]] Center ==<br />
<br />
This button horizontally ''pans'' the output, changing the [[yaw]] of the remapped images so they fit to the centre of the output frame. This is useful if there is a lot of black space on the left or right of the output. This also performs a '''Fit''', equivalent to the next button.<br />
<br />
Note that centering a [[Rectilinear Projection]] or [[Fisheye Projection]] panorama will change the perspective, this may be unwanted.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== [[Image:Hugin_straighten_pano.png]] Straighten ==<br />
<br />
Straightening the panorama optimises the [[roll]] and [[pitch]] of the input images without changing their relative positions, levelling the panorama in the process. This normally produces good results, if you need more accurate positioning, try adding [[vertical control points]] in the [[hugin Control Points tab]] and reoptimise.<br />
<br />
== Numeric Transform ==<br />
<br />
Enter a '''numerical transform''' to rotate the input images without changing their relative positions - Effectively this rotates the entire panorama. Enter [[roll]], [[pitch]] and [[yaw]] values in degrees.<br />
<br />
= [[Image:Fast_preview_icon_crop.svg]] Crop tab =<br />
<br />
Using this tool you can set the output cropping region interactively. To do this precisely instead, use the [[Hugin Stitcher tab| Stitcher tab]]. Initially, the entire panorama is in the output region (i.e. nothing is cropped).<br />
<br />
To change the cropping at each edge, move the mouse towards that edge until a white box appears along it, then drag with the left mouse button until the edge is where you want it. The darker areas represent the region that is cropped off. You can move two edges at once by moving the mouse towards the corner shared by the edges until both white boxes appear. If you wish to move the whole region at once, move the mouse into the middle so that all four edges have boxes along them and drag.<br />
<br />
== [[Image:Fast_preview_icon_autocrop.svg]] Autocrop ==<br />
<br />
The autocrop button adjusts the crop rectangle so that it is entirely within the image area, i.e. there will be no 'black' borders in the final stitched image. It does this by maximising the area of the rectangle rather than the width or height.<br />
<br />
= In practice =<br />
[[Image:Fast_preview_guide_start.png | thumb | A panorama with unconnected image groups after optimisation.]]<br />
Let's try using this preview to help with a panorama where automatic alignment failed. This panorama was taken where a lot of things were blowing around in the wind, and the clouds were changing quickly, so it is not surprising that it aligning it is a struggle. The [[Hugin Assistant tab|Assistant tab]] tells us there are multiple unconnected image groups. We can optimise the panorama and end up with a images correctly positioned amongst the group they are in, but the groups themselves are not aligned. Try this first. <br />
<br />
[[Image:Fast_preview_guide_drag.png | thumb | Dragging images with the drag tool.]]<br />
Using the Drag tool, we can roughly align the groups together:<br />
# Turn on the tool with the ''Drag'' button.<br />
# Drag each component so the horizon is in the middle, using the left mouse button.<br />
# Drag with the right mouse button (or hold control and drag with the left) to level the horizon.[[Image:Fast_preview_guide_rotate_drag.png | thumb | Rotating images with the drag tool.]]<br />
# Hold shift and drag with the left mouse button sideways to approximately line up the image with the other groups.<br />
<br />
[[Image:Fast_preview_guide_identify.png | thumb | Two images highlighted in the preview window.]]<br />
When we have the images in approximately the right position, we can begin placing control points to guide the optimiser. The Identify tool lends a hand here. Firstly, turn on the identify tool. Move the mouse on an overlap that was recently created between two image groups. The images in the overlap light up. Move the mouse to a place where there is only two images in that overlap, and click. The two images are opened in the [[Hugin Control Points tab|control point editor]] (there may be a short pause while the images are loaded). Once you have placed control points manually, you can return to the preview to find some more image pairs.<br />
<br />
[[Image:Fast_preview_guide_crop.png | thumb | Adjusting the cropping region.]]<br />
When you are happy that your panorama contains sufficient control points, optimise it again. The panorama will likely have the horizon at the wrong angle, in this case press ''Straighten'' on the preview window. You can then frame the panorama using the drag tool (hold shift so you don't make it wonky again!). Use your artistic judgement here. If you want to crop your panorama, click ''Crop'' and drag the edges of the cropping rectangle.<br />
<br />
[[Category:Software:Hugin]]<br />
[[Category:Tutorial:Nice to know]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Fast_Preview_window&diff=13302Hugin Fast Preview window2011-03-14T21:11:50Z<p>Bruno: /* EV */</p>
<hr />
<div>= Distinction =<br />
<br />
Like the more accurate [[Hugin Preview window]], the fast preview shows something similar to the final stitched output, but with a few important differences:<br />
<br />
* The window features a row of tabs at the top, clicking on a tab switches between modes that allow you to interact with the panorama in different ways.<br />
* Reduced resolution input images are used, so some areas can appear blurred that will be sharp in the final output.<br />
* Seams are not created, images are simply overlaid with the first image at the bottom of the stack and the last at the top.<br />
* Blending by a tool such as [[enblend]] isn't shown.<br />
* The brightness display of [[HDR]] and 16bit images is controlled by settings in the hugin Preferences, these settings are not used when stitching. The colouring of these images will also be inaccurate when using exposure or white balance correction. For HDR panoramas, the [[Hugin Preview window]] is recommended instead.<br />
* Only the first photo from each stack is visible (the others are hidden behind), if you want to see the combined stack then use the HDR mode of the [[Hugin Preview window]] instead.<br />
* Photometric correction only includes white balance and exposure, unless full photometric correction is enabled with the the Photometrics button.<br />
* The remappings are approximate, the output by a tool such as [[nona]] is more accurate. If this concerns you more than speed, use the [[Hugin Preview window]] instead.<br />
* It's much faster ;-)<br />
<br />
= General features =<br />
<br />
== Overview ==<br />
<br />
[[image:hugin-2011.0_fpw_overview.png|thumb|200px|left|Screenshot of docked Overview in Panosphere mode]]<br />
The '''Overview''' introduced in Hugin 2011.0 represents an interactive preview of the panorama.<br />
<br />
Just click the button 'Show/Hide' to toggle the display the docked Overview window. Zoom it by dragging the handle located at the center of the border to the preview canvas.<br />
<br />
The 'Grid' checkbox can be used to toggle the grid overlay in both overview and the preview canvas.<br />
<br />
Clicking the small pin icon in the header of the docked Overview area (or dragging the Overview title bar) will switch to a floating window instead. To put that floating window back in a docked position just drag it in either the top, bottom, left or right boundary of the preview's actual image area.<br />
<br />
The default mode is a Panosphere to display typical panoramas and can be used to e.g. easily check for errors in the nadir or zenith regions.<br />
{{clr}}<br />
<br />
== Displayed images ==<br />
<br />
Every input image in the preview has ''toggle'' button where display can be disabled or enabled.<br />
<br />
In addition, this display also controls the behaviour of the [[hugin Optimizer tab]] and the [[hugin Stitcher tab]] - Any photos disabled here are not used in optimisation or stitching.<br />
<br />
=== [[Image:Hugin_preview_show_all.png]] All ===<br />
<br />
By default all input images are shown in the preview, however individual images can be enabled and disabled in the<br />
'''Displayed images''' section. Use the '''All''' button to return to the default and display all the images.<br />
<br />
=== [[Image:Hugin_preview_show_none.png]] None ===<br />
<br />
Similarly, hide all images with the '''None''' button, use this if you want to enable preview images one by one.<br />
<br />
== Preview canvas ==<br />
<br />
The image window itself shows a representation of the final stitched output panorama, use the scroll bars<br />
to change the horizontal and vertical [[Field of View]].<br />
<br />
To toggle the grid use the checkbox ''Grid'' in the Overview window.<br />
<br />
<br />
= Preview tab =<br />
<br />
== [[Image:Fast_preview_icon_identify.svg]] Identify ==<br />
<br />
Using this tool you can find where your images are, and match them to their number. You can also edit control points.<br />
<br />
When this tool is turned on, move the mouse over the visibility buttons for the images (the numbers at the top of the preview). The image with the number on the button under the mouse lights up red in the preview. Moving the mouse over the panorama highlights all the images under the mouse in different colours. The buttons for those images lights up in matching colours.<br />
<br />
When the mouse is on the overlap of two images, click to edit the control points between those images.<br />
<br />
== [[Image:Fast_preview_icon_photometric.svg]] Photometrics ==<br />
<br />
Enables full photometric correction. When turned on, this will cause significant delay when changing photometric parameters. It also takes a while to turn on and off. However, with it enabled you get much better representation of the colours in the output. With it turned off, you get correction only for exposure and white balance. With it turned on, you also get vignetting and colour response correction. The [[Hugin Preview window]] does all these things by default, so you may wish to use that instead.<br />
<br />
== [[Image:Show_Control_Points_Button.svg]] Show control points ==<br />
<br />
When this tool is turned on, all [[Control points]] are drawn as lines with crosses at each end. Green, yellow, orange, and red lines and their crosses indicate 'normal' control points. A red control point is misaligned (the ends of the line are father apart), and a green control point is well aligned (the ends of the line are almost in the same position). Blue indicates [[horizontal control points]], [[vertical control points]] or [[straight line control points]].<br />
<br />
== Blend mode ==<br />
<br />
The ''normal'' blend mode will draw the images with the first photos in the project above later photos as this approximates the order that blending is performed.. The ''difference'' blend mode will do the same, except the image under the mouse pointer will be subtracted from the rest of the stack. Use this to determine if the alignment went well: where you can see edges in the subtracted image, these edges are misaligned. Be warned that this isn't fully accurate, the other preview has a better difference mode.<br />
<br />
== EV ==<br />
<br />
'''EV''' stands for ''Exposure Value'', clicking the '''Reset''' button will set it to the average of all<br />
the input image exposures or setting it to '''0''' (zero)<br />
will result in no exposure change being applied to the panorama (note that unless all the photos also have their individual EV set to zero in the [[Hugin Camera and Lens tab]] they will likely appear incredibly bright or dark).<br />
<br />
'''EV''' is a standard photographic scale, each increase or decrease by one unit will change the exposure by<br />
the equivalent of one ''f-stop'' (ie. halving or doubling the exposure). It is worth adjusting the exposure<br />
here in [[hugin]] rather than later in an external image editor, since '''hugin''' uses the [[camera response curve]]<br />
calculated in the [[hugin Exposure tab]] to perform the correction in a ''linear'' colour space.<br />
<br />
The average value isn't always wanted. If you see colour artefacts in bright sky areas, set this<br />
to the negative of the darkest input image - This has a side-effect of clipping brighter images.<br />
<br />
== Grey Picker ==<br />
<br />
Hugin can align the white balance ([[w:Color balance]]) of the photos in the panorama to match that of the ''anchor'' photo, this is done when optimising '''White Balance''' in the [[Hugin Exposure tab]] or when you use the '''Align...''' button in the [[Hugin Assistant tab]] - Usually this ''anchor'' is the first photo in the project, but it can be changed using '''anchor this image for exposure''' in the [[Hugin Images tab]].<br />
<br />
However, often the first photo, or even none of the photos, in the project has the wanted white balance. You can use the '''Grey Picker''' button to adjust the white balance of the whole panorama by using any 'neutral' colour object in the scene as a sample. Just push the button and then click on the object in the preview canvas.<br />
<br />
An ideal neutral colour object is white or grey, this could be a test card, an overcast sky, snow, or a white object - It is important to remember that white paint and paper comes in lots of colour shades so it really isn't very reliable, prefer a transparent material that is white due to light diffusion such as etched glass or polystyrene foam. Avoid objects that are 'blown out', or which are in shade and illuminated only by secondary light sources in the scene.<br />
<br />
= [[Image:preview_layout.svg]]Layout tab =<br />
The Layout tab shows the entire project as a diagram with colour-coded lines connecting each of the photographs.<br />
<br />
[[File:layout-small.png]]<br />
<br />
Green lines connecting images show the control points have a small error, red lines show a large error. Grey lines show no control points connecting the images.<br />
<br />
You can see where the project is OK and where there are problems if it isn't quite right. Just click on any connection and Hugin jumps to the Control Points tab to edit that pair of photos.<br />
<br />
= Projection tab =<br />
<br />
This tab is for adjusting [[Projections|projection]] of the panorama, some projections have adjustable parameters which will appear when selected.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical angle of view of the output image.<br />
<br />
== Projection ==<br />
<br />
Use the drop down list to change the output projection of the panorama, the list is exactly the same as that<br />
in the [[hugin Stitcher tab]]. Note that for some projections, the scroll-bar sliders to change the<br />
[[Field of View]] are disabled. If you are having trouble, switch to [[Equirectangular Projection]], adjust<br />
the field of view and switch back.<br />
<br />
= [[Image:Fast_preview_icon_drag.svg]] Move/Drag tab =<br />
<br />
Using this tool you can recentre the panorama interactively. With it turned on, try the following:<br />
* Drag the panorama with the left mouse button to rotate the panorama's images. The centre of rotation is the point where you pushed the mouse button down.<br />
* Hold shift when doing the above to constrain movement to yaw or pitch. Note pitch is affected by the centre of rotation.<br />
* Drag the panorama with the right mouse button or hold control and drag with the left to roll the panorama (rotate around the middle)<br />
<br />
If the panorama contains unconnected components, they will move individually.<br />
<br />
== Drag mode ==<br />
This determines what parameters that are changed when the images are dragged.<br />
* Normal - When dragged left-right, the yaw parameter is changed and when dragged up-down the pitch parameter is changed. I.e. the camera is tilted in the yaw and pitch angles.<br />
* Mosaic - When dragged left-right, X parameter is changed and when dragged up-down the Y parameter is changed. I.e. the camera is moved in the X and Y dimensions.<br />
<br />
== [[Image:Hugin_center_pano.png]] Center ==<br />
<br />
This button horizontally ''pans'' the output, changing the [[yaw]] of the remapped images so they fit to the centre of the output frame. This is useful if there is a lot of black space on the left or right of the output. This also performs a '''Fit''', equivalent to the next button.<br />
<br />
Note that centering a [[Rectilinear Projection]] or [[Fisheye Projection]] panorama will change the perspective, this may be unwanted.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== [[Image:Hugin_straighten_pano.png]] Straighten ==<br />
<br />
Straightening the panorama optimises the [[roll]] and [[pitch]] of the input images without changing their relative positions, levelling the panorama in the process. This normally produces good results, if you need more accurate positioning, try adding [[vertical control points]] in the [[hugin Control Points tab]] and reoptimise.<br />
<br />
== Numeric Transform ==<br />
<br />
Enter a '''numerical transform''' to rotate the input images without changing their relative positions - Effectively this rotates the entire panorama. Enter [[roll]], [[pitch]] and [[yaw]] values in degrees.<br />
<br />
= [[Image:Fast_preview_icon_crop.svg]] Crop tab =<br />
<br />
Using this tool you can set the output cropping region interactively. To do this precisely instead, use the [[Hugin Stitcher tab| Stitcher tab]]. Initially, the entire panorama is in the output region (i.e. nothing is cropped).<br />
<br />
To change the cropping at each edge, move the mouse towards that edge until a white box appears along it, then drag with the left mouse button until the edge is where you want it. The darker areas represent the region that is cropped off. You can move two edges at once by moving the mouse towards the corner shared by the edges until both white boxes appear. If you wish to move the whole region at once, move the mouse into the middle so that all four edges have boxes along them and drag.<br />
<br />
== [[Image:Fast_preview_icon_autocrop.svg]] Autocrop ==<br />
<br />
The autocrop button adjusts the crop rectangle so that it is entirely within the image area, i.e. there will be no 'black' borders in the final stitched image. It does this by maximising the area of the rectangle rather than the width or height.<br />
<br />
= In practice =<br />
[[Image:Fast_preview_guide_start.png | thumb | A panorama with unconnected image groups after optimisation.]]<br />
Let's try using this preview to help with a panorama where automatic alignment failed. This panorama was taken where a lot of things were blowing around in the wind, and the clouds were changing quickly, so it is not surprising that it aligning it is a struggle. The [[Hugin Assistant tab|Assistant tab]] tells us there are multiple unconnected image groups. We can optimise the panorama and end up with a images correctly positioned amongst the group they are in, but the groups themselves are not aligned. Try this first. <br />
<br />
[[Image:Fast_preview_guide_drag.png | thumb | Dragging images with the drag tool.]]<br />
Using the Drag tool, we can roughly align the groups together:<br />
# Turn on the tool with the ''Drag'' button.<br />
# Drag each component so the horizon is in the middle, using the left mouse button.<br />
# Drag with the right mouse button (or hold control and drag with the left) to level the horizon.[[Image:Fast_preview_guide_rotate_drag.png | thumb | Rotating images with the drag tool.]]<br />
# Hold shift and drag with the left mouse button sideways to approximately line up the image with the other groups.<br />
<br />
[[Image:Fast_preview_guide_identify.png | thumb | Two images highlighted in the preview window.]]<br />
When we have the images in approximately the right position, we can begin placing control points to guide the optimiser. The Identify tool lends a hand here. Firstly, turn on the identify tool. Move the mouse on an overlap that was recently created between two image groups. The images in the overlap light up. Move the mouse to a place where there is only two images in that overlap, and click. The two images are opened in the [[Hugin Control Points tab|control point editor]] (there may be a short pause while the images are loaded). Once you have placed control points manually, you can return to the preview to find some more image pairs.<br />
<br />
[[Image:Fast_preview_guide_crop.png | thumb | Adjusting the cropping region.]]<br />
When you are happy that your panorama contains sufficient control points, optimise it again. The panorama will likely have the horizon at the wrong angle, in this case press ''Straighten'' on the preview window. You can then frame the panorama using the drag tool (hold shift so you don't make it wonky again!). Use your artistic judgement here. If you want to crop your panorama, click ''Crop'' and drag the edges of the cropping rectangle.<br />
<br />
[[Category:Software:Hugin]]<br />
[[Category:Tutorial:Nice to know]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Fast_Preview_window&diff=13301Hugin Fast Preview window2011-03-14T21:07:12Z<p>Bruno: /* Blend mode */</p>
<hr />
<div>= Distinction =<br />
<br />
Like the more accurate [[Hugin Preview window]], the fast preview shows something similar to the final stitched output, but with a few important differences:<br />
<br />
* The window features a row of tabs at the top, clicking on a tab switches between modes that allow you to interact with the panorama in different ways.<br />
* Reduced resolution input images are used, so some areas can appear blurred that will be sharp in the final output.<br />
* Seams are not created, images are simply overlaid with the first image at the bottom of the stack and the last at the top.<br />
* Blending by a tool such as [[enblend]] isn't shown.<br />
* The brightness display of [[HDR]] and 16bit images is controlled by settings in the hugin Preferences, these settings are not used when stitching. The colouring of these images will also be inaccurate when using exposure or white balance correction. For HDR panoramas, the [[Hugin Preview window]] is recommended instead.<br />
* Only the first photo from each stack is visible (the others are hidden behind), if you want to see the combined stack then use the HDR mode of the [[Hugin Preview window]] instead.<br />
* Photometric correction only includes white balance and exposure, unless full photometric correction is enabled with the the Photometrics button.<br />
* The remappings are approximate, the output by a tool such as [[nona]] is more accurate. If this concerns you more than speed, use the [[Hugin Preview window]] instead.<br />
* It's much faster ;-)<br />
<br />
= General features =<br />
<br />
== Overview ==<br />
<br />
[[image:hugin-2011.0_fpw_overview.png|thumb|200px|left|Screenshot of docked Overview in Panosphere mode]]<br />
The '''Overview''' introduced in Hugin 2011.0 represents an interactive preview of the panorama.<br />
<br />
Just click the button 'Show/Hide' to toggle the display the docked Overview window. Zoom it by dragging the handle located at the center of the border to the preview canvas.<br />
<br />
The 'Grid' checkbox can be used to toggle the grid overlay in both overview and the preview canvas.<br />
<br />
Clicking the small pin icon in the header of the docked Overview area (or dragging the Overview title bar) will switch to a floating window instead. To put that floating window back in a docked position just drag it in either the top, bottom, left or right boundary of the preview's actual image area.<br />
<br />
The default mode is a Panosphere to display typical panoramas and can be used to e.g. easily check for errors in the nadir or zenith regions.<br />
{{clr}}<br />
<br />
== Displayed images ==<br />
<br />
Every input image in the preview has ''toggle'' button where display can be disabled or enabled.<br />
<br />
In addition, this display also controls the behaviour of the [[hugin Optimizer tab]] and the [[hugin Stitcher tab]] - Any photos disabled here are not used in optimisation or stitching.<br />
<br />
=== [[Image:Hugin_preview_show_all.png]] All ===<br />
<br />
By default all input images are shown in the preview, however individual images can be enabled and disabled in the<br />
'''Displayed images''' section. Use the '''All''' button to return to the default and display all the images.<br />
<br />
=== [[Image:Hugin_preview_show_none.png]] None ===<br />
<br />
Similarly, hide all images with the '''None''' button, use this if you want to enable preview images one by one.<br />
<br />
== Preview canvas ==<br />
<br />
The image window itself shows a representation of the final stitched output panorama, use the scroll bars<br />
to change the horizontal and vertical [[Field of View]].<br />
<br />
To toggle the grid use the checkbox ''Grid'' in the Overview window.<br />
<br />
<br />
= Preview tab =<br />
<br />
== [[Image:Fast_preview_icon_identify.svg]] Identify ==<br />
<br />
Using this tool you can find where your images are, and match them to their number. You can also edit control points.<br />
<br />
When this tool is turned on, move the mouse over the visibility buttons for the images (the numbers at the top of the preview). The image with the number on the button under the mouse lights up red in the preview. Moving the mouse over the panorama highlights all the images under the mouse in different colours. The buttons for those images lights up in matching colours.<br />
<br />
When the mouse is on the overlap of two images, click to edit the control points between those images.<br />
<br />
== [[Image:Fast_preview_icon_photometric.svg]] Photometrics ==<br />
<br />
Enables full photometric correction. When turned on, this will cause significant delay when changing photometric parameters. It also takes a while to turn on and off. However, with it enabled you get much better representation of the colours in the output. With it turned off, you get correction only for exposure and white balance. With it turned on, you also get vignetting and colour response correction. The [[Hugin Preview window]] does all these things by default, so you may wish to use that instead.<br />
<br />
== [[Image:Show_Control_Points_Button.svg]] Show control points ==<br />
<br />
When this tool is turned on, all [[Control points]] are drawn as lines with crosses at each end. Green, yellow, orange, and red lines and their crosses indicate 'normal' control points. A red control point is misaligned (the ends of the line are father apart), and a green control point is well aligned (the ends of the line are almost in the same position). Blue indicates [[horizontal control points]], [[vertical control points]] or [[straight line control points]].<br />
<br />
== Blend mode ==<br />
<br />
The ''normal'' blend mode will draw the images with the first photos in the project above later photos as this approximates the order that blending is performed.. The ''difference'' blend mode will do the same, except the image under the mouse pointer will be subtracted from the rest of the stack. Use this to determine if the alignment went well: where you can see edges in the subtracted image, these edges are misaligned. Be warned that this isn't fully accurate, the other preview has a better difference mode.<br />
<br />
== EV ==<br />
<br />
'''EV''' stands for ''Exposure Value'', clicking the '''Reset''' button will set it to the average of all<br />
the input image exposures or setting it to '''0''' (zero)<br />
will result in no exposure change being applied to the panorama.<br />
<br />
'''EV''' is a standard photographic scale, each increase or decrease by one unit will change the exposure by<br />
the equivalent of one ''f-stop'' (ie. halving or doubling the exposure). It is worth adjusting the exposure<br />
here in [[hugin]] rather than later in an external image editor, since '''hugin''' uses the [[camera response curve]]<br />
calculated in the [[hugin Exposure tab]] to perform the correction in a ''linear'' colour space.<br />
<br />
The average value isn't always wanted. If you see colour artefacts in bright sky areas, set this<br />
to the negative of the darkest input image - This has a side-effect of clipping brighter images.<br />
<br />
== Grey Picker ==<br />
<br />
Hugin can align the white balance ([[w:Color balance]]) of the photos in the panorama to match that of the ''anchor'' photo, this is done when optimising '''White Balance''' in the [[Hugin Exposure tab]] or when you use the '''Align...''' button in the [[Hugin Assistant tab]] - Usually this ''anchor'' is the first photo in the project, but it can be changed using '''anchor this image for exposure''' in the [[Hugin Images tab]].<br />
<br />
However, often the first photo, or even none of the photos, in the project has the wanted white balance. You can use the '''Grey Picker''' button to adjust the white balance of the whole panorama by using any 'neutral' colour object in the scene as a sample. Just push the button and then click on the object in the preview canvas.<br />
<br />
An ideal neutral colour object is white or grey, this could be a test card, an overcast sky, snow, or a white object - It is important to remember that white paint and paper comes in lots of colour shades so it really isn't very reliable, prefer a transparent material that is white due to light diffusion such as etched glass or polystyrene foam. Avoid objects that are 'blown out', or which are in shade and illuminated only by secondary light sources in the scene.<br />
<br />
= [[Image:preview_layout.svg]]Layout tab =<br />
The Layout tab shows the entire project as a diagram with colour-coded lines connecting each of the photographs.<br />
<br />
[[File:layout-small.png]]<br />
<br />
Green lines connecting images show the control points have a small error, red lines show a large error. Grey lines show no control points connecting the images.<br />
<br />
You can see where the project is OK and where there are problems if it isn't quite right. Just click on any connection and Hugin jumps to the Control Points tab to edit that pair of photos.<br />
<br />
= Projection tab =<br />
<br />
This tab is for adjusting [[Projections|projection]] of the panorama, some projections have adjustable parameters which will appear when selected.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical angle of view of the output image.<br />
<br />
== Projection ==<br />
<br />
Use the drop down list to change the output projection of the panorama, the list is exactly the same as that<br />
in the [[hugin Stitcher tab]]. Note that for some projections, the scroll-bar sliders to change the<br />
[[Field of View]] are disabled. If you are having trouble, switch to [[Equirectangular Projection]], adjust<br />
the field of view and switch back.<br />
<br />
= [[Image:Fast_preview_icon_drag.svg]] Move/Drag tab =<br />
<br />
Using this tool you can recentre the panorama interactively. With it turned on, try the following:<br />
* Drag the panorama with the left mouse button to rotate the panorama's images. The centre of rotation is the point where you pushed the mouse button down.<br />
* Hold shift when doing the above to constrain movement to yaw or pitch. Note pitch is affected by the centre of rotation.<br />
* Drag the panorama with the right mouse button or hold control and drag with the left to roll the panorama (rotate around the middle)<br />
<br />
If the panorama contains unconnected components, they will move individually.<br />
<br />
== Drag mode ==<br />
This determines what parameters that are changed when the images are dragged.<br />
* Normal - When dragged left-right, the yaw parameter is changed and when dragged up-down the pitch parameter is changed. I.e. the camera is tilted in the yaw and pitch angles.<br />
* Mosaic - When dragged left-right, X parameter is changed and when dragged up-down the Y parameter is changed. I.e. the camera is moved in the X and Y dimensions.<br />
<br />
== [[Image:Hugin_center_pano.png]] Center ==<br />
<br />
This button horizontally ''pans'' the output, changing the [[yaw]] of the remapped images so they fit to the centre of the output frame. This is useful if there is a lot of black space on the left or right of the output. This also performs a '''Fit''', equivalent to the next button.<br />
<br />
Note that centering a [[Rectilinear Projection]] or [[Fisheye Projection]] panorama will change the perspective, this may be unwanted.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== [[Image:Hugin_straighten_pano.png]] Straighten ==<br />
<br />
Straightening the panorama optimises the [[roll]] and [[pitch]] of the input images without changing their relative positions, levelling the panorama in the process. This normally produces good results, if you need more accurate positioning, try adding [[vertical control points]] in the [[hugin Control Points tab]] and reoptimise.<br />
<br />
== Numeric Transform ==<br />
<br />
Enter a '''numerical transform''' to rotate the input images without changing their relative positions - Effectively this rotates the entire panorama. Enter [[roll]], [[pitch]] and [[yaw]] values in degrees.<br />
<br />
= [[Image:Fast_preview_icon_crop.svg]] Crop tab =<br />
<br />
Using this tool you can set the output cropping region interactively. To do this precisely instead, use the [[Hugin Stitcher tab| Stitcher tab]]. Initially, the entire panorama is in the output region (i.e. nothing is cropped).<br />
<br />
To change the cropping at each edge, move the mouse towards that edge until a white box appears along it, then drag with the left mouse button until the edge is where you want it. The darker areas represent the region that is cropped off. You can move two edges at once by moving the mouse towards the corner shared by the edges until both white boxes appear. If you wish to move the whole region at once, move the mouse into the middle so that all four edges have boxes along them and drag.<br />
<br />
== [[Image:Fast_preview_icon_autocrop.svg]] Autocrop ==<br />
<br />
The autocrop button adjusts the crop rectangle so that it is entirely within the image area, i.e. there will be no 'black' borders in the final stitched image. It does this by maximising the area of the rectangle rather than the width or height.<br />
<br />
= In practice =<br />
[[Image:Fast_preview_guide_start.png | thumb | A panorama with unconnected image groups after optimisation.]]<br />
Let's try using this preview to help with a panorama where automatic alignment failed. This panorama was taken where a lot of things were blowing around in the wind, and the clouds were changing quickly, so it is not surprising that it aligning it is a struggle. The [[Hugin Assistant tab|Assistant tab]] tells us there are multiple unconnected image groups. We can optimise the panorama and end up with a images correctly positioned amongst the group they are in, but the groups themselves are not aligned. Try this first. <br />
<br />
[[Image:Fast_preview_guide_drag.png | thumb | Dragging images with the drag tool.]]<br />
Using the Drag tool, we can roughly align the groups together:<br />
# Turn on the tool with the ''Drag'' button.<br />
# Drag each component so the horizon is in the middle, using the left mouse button.<br />
# Drag with the right mouse button (or hold control and drag with the left) to level the horizon.[[Image:Fast_preview_guide_rotate_drag.png | thumb | Rotating images with the drag tool.]]<br />
# Hold shift and drag with the left mouse button sideways to approximately line up the image with the other groups.<br />
<br />
[[Image:Fast_preview_guide_identify.png | thumb | Two images highlighted in the preview window.]]<br />
When we have the images in approximately the right position, we can begin placing control points to guide the optimiser. The Identify tool lends a hand here. Firstly, turn on the identify tool. Move the mouse on an overlap that was recently created between two image groups. The images in the overlap light up. Move the mouse to a place where there is only two images in that overlap, and click. The two images are opened in the [[Hugin Control Points tab|control point editor]] (there may be a short pause while the images are loaded). Once you have placed control points manually, you can return to the preview to find some more image pairs.<br />
<br />
[[Image:Fast_preview_guide_crop.png | thumb | Adjusting the cropping region.]]<br />
When you are happy that your panorama contains sufficient control points, optimise it again. The panorama will likely have the horizon at the wrong angle, in this case press ''Straighten'' on the preview window. You can then frame the panorama using the drag tool (hold shift so you don't make it wonky again!). Use your artistic judgement here. If you want to crop your panorama, click ''Crop'' and drag the edges of the cropping rectangle.<br />
<br />
[[Category:Software:Hugin]]<br />
[[Category:Tutorial:Nice to know]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Fast_Preview_window&diff=13300Hugin Fast Preview window2011-03-14T21:04:40Z<p>Bruno: note that stacks are only visible in the old preview</p>
<hr />
<div>= Distinction =<br />
<br />
Like the more accurate [[Hugin Preview window]], the fast preview shows something similar to the final stitched output, but with a few important differences:<br />
<br />
* The window features a row of tabs at the top, clicking on a tab switches between modes that allow you to interact with the panorama in different ways.<br />
* Reduced resolution input images are used, so some areas can appear blurred that will be sharp in the final output.<br />
* Seams are not created, images are simply overlaid with the first image at the bottom of the stack and the last at the top.<br />
* Blending by a tool such as [[enblend]] isn't shown.<br />
* The brightness display of [[HDR]] and 16bit images is controlled by settings in the hugin Preferences, these settings are not used when stitching. The colouring of these images will also be inaccurate when using exposure or white balance correction. For HDR panoramas, the [[Hugin Preview window]] is recommended instead.<br />
* Only the first photo from each stack is visible (the others are hidden behind), if you want to see the combined stack then use the HDR mode of the [[Hugin Preview window]] instead.<br />
* Photometric correction only includes white balance and exposure, unless full photometric correction is enabled with the the Photometrics button.<br />
* The remappings are approximate, the output by a tool such as [[nona]] is more accurate. If this concerns you more than speed, use the [[Hugin Preview window]] instead.<br />
* It's much faster ;-)<br />
<br />
= General features =<br />
<br />
== Overview ==<br />
<br />
[[image:hugin-2011.0_fpw_overview.png|thumb|200px|left|Screenshot of docked Overview in Panosphere mode]]<br />
The '''Overview''' introduced in Hugin 2011.0 represents an interactive preview of the panorama.<br />
<br />
Just click the button 'Show/Hide' to toggle the display the docked Overview window. Zoom it by dragging the handle located at the center of the border to the preview canvas.<br />
<br />
The 'Grid' checkbox can be used to toggle the grid overlay in both overview and the preview canvas.<br />
<br />
Clicking the small pin icon in the header of the docked Overview area (or dragging the Overview title bar) will switch to a floating window instead. To put that floating window back in a docked position just drag it in either the top, bottom, left or right boundary of the preview's actual image area.<br />
<br />
The default mode is a Panosphere to display typical panoramas and can be used to e.g. easily check for errors in the nadir or zenith regions.<br />
{{clr}}<br />
<br />
== Displayed images ==<br />
<br />
Every input image in the preview has ''toggle'' button where display can be disabled or enabled.<br />
<br />
In addition, this display also controls the behaviour of the [[hugin Optimizer tab]] and the [[hugin Stitcher tab]] - Any photos disabled here are not used in optimisation or stitching.<br />
<br />
=== [[Image:Hugin_preview_show_all.png]] All ===<br />
<br />
By default all input images are shown in the preview, however individual images can be enabled and disabled in the<br />
'''Displayed images''' section. Use the '''All''' button to return to the default and display all the images.<br />
<br />
=== [[Image:Hugin_preview_show_none.png]] None ===<br />
<br />
Similarly, hide all images with the '''None''' button, use this if you want to enable preview images one by one.<br />
<br />
== Preview canvas ==<br />
<br />
The image window itself shows a representation of the final stitched output panorama, use the scroll bars<br />
to change the horizontal and vertical [[Field of View]].<br />
<br />
To toggle the grid use the checkbox ''Grid'' in the Overview window.<br />
<br />
<br />
= Preview tab =<br />
<br />
== [[Image:Fast_preview_icon_identify.svg]] Identify ==<br />
<br />
Using this tool you can find where your images are, and match them to their number. You can also edit control points.<br />
<br />
When this tool is turned on, move the mouse over the visibility buttons for the images (the numbers at the top of the preview). The image with the number on the button under the mouse lights up red in the preview. Moving the mouse over the panorama highlights all the images under the mouse in different colours. The buttons for those images lights up in matching colours.<br />
<br />
When the mouse is on the overlap of two images, click to edit the control points between those images.<br />
<br />
== [[Image:Fast_preview_icon_photometric.svg]] Photometrics ==<br />
<br />
Enables full photometric correction. When turned on, this will cause significant delay when changing photometric parameters. It also takes a while to turn on and off. However, with it enabled you get much better representation of the colours in the output. With it turned off, you get correction only for exposure and white balance. With it turned on, you also get vignetting and colour response correction. The [[Hugin Preview window]] does all these things by default, so you may wish to use that instead.<br />
<br />
== [[Image:Show_Control_Points_Button.svg]] Show control points ==<br />
<br />
When this tool is turned on, all [[Control points]] are drawn as lines with crosses at each end. Green, yellow, orange, and red lines and their crosses indicate 'normal' control points. A red control point is misaligned (the ends of the line are father apart), and a green control point is well aligned (the ends of the line are almost in the same position). Blue indicates [[horizontal control points]], [[vertical control points]] or [[straight line control points]].<br />
<br />
== Blend mode ==<br />
<br />
The ''normal'' blend mode will draw the images as a stack. The ''difference'' blend mode will do the same, except the image under the mouse pointer will be subtracted from the rest of the stack. Use this to determine if the alignment went well: where you can see edges in the subtracted image, these edges are misaligned. Be warned that this isn't fully accurate, the other preview has a better difference mode.<br />
<br />
== EV ==<br />
<br />
'''EV''' stands for ''Exposure Value'', clicking the '''Reset''' button will set it to the average of all<br />
the input image exposures or setting it to '''0''' (zero)<br />
will result in no exposure change being applied to the panorama.<br />
<br />
'''EV''' is a standard photographic scale, each increase or decrease by one unit will change the exposure by<br />
the equivalent of one ''f-stop'' (ie. halving or doubling the exposure). It is worth adjusting the exposure<br />
here in [[hugin]] rather than later in an external image editor, since '''hugin''' uses the [[camera response curve]]<br />
calculated in the [[hugin Exposure tab]] to perform the correction in a ''linear'' colour space.<br />
<br />
The average value isn't always wanted. If you see colour artefacts in bright sky areas, set this<br />
to the negative of the darkest input image - This has a side-effect of clipping brighter images.<br />
<br />
== Grey Picker ==<br />
<br />
Hugin can align the white balance ([[w:Color balance]]) of the photos in the panorama to match that of the ''anchor'' photo, this is done when optimising '''White Balance''' in the [[Hugin Exposure tab]] or when you use the '''Align...''' button in the [[Hugin Assistant tab]] - Usually this ''anchor'' is the first photo in the project, but it can be changed using '''anchor this image for exposure''' in the [[Hugin Images tab]].<br />
<br />
However, often the first photo, or even none of the photos, in the project has the wanted white balance. You can use the '''Grey Picker''' button to adjust the white balance of the whole panorama by using any 'neutral' colour object in the scene as a sample. Just push the button and then click on the object in the preview canvas.<br />
<br />
An ideal neutral colour object is white or grey, this could be a test card, an overcast sky, snow, or a white object - It is important to remember that white paint and paper comes in lots of colour shades so it really isn't very reliable, prefer a transparent material that is white due to light diffusion such as etched glass or polystyrene foam. Avoid objects that are 'blown out', or which are in shade and illuminated only by secondary light sources in the scene.<br />
<br />
= [[Image:preview_layout.svg]]Layout tab =<br />
The Layout tab shows the entire project as a diagram with colour-coded lines connecting each of the photographs.<br />
<br />
[[File:layout-small.png]]<br />
<br />
Green lines connecting images show the control points have a small error, red lines show a large error. Grey lines show no control points connecting the images.<br />
<br />
You can see where the project is OK and where there are problems if it isn't quite right. Just click on any connection and Hugin jumps to the Control Points tab to edit that pair of photos.<br />
<br />
= Projection tab =<br />
<br />
This tab is for adjusting [[Projections|projection]] of the panorama, some projections have adjustable parameters which will appear when selected.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== Field of View ==<br />
<br />
This is the horizontal and vertical angle of view of the output image.<br />
<br />
== Projection ==<br />
<br />
Use the drop down list to change the output projection of the panorama, the list is exactly the same as that<br />
in the [[hugin Stitcher tab]]. Note that for some projections, the scroll-bar sliders to change the<br />
[[Field of View]] are disabled. If you are having trouble, switch to [[Equirectangular Projection]], adjust<br />
the field of view and switch back.<br />
<br />
= [[Image:Fast_preview_icon_drag.svg]] Move/Drag tab =<br />
<br />
Using this tool you can recentre the panorama interactively. With it turned on, try the following:<br />
* Drag the panorama with the left mouse button to rotate the panorama's images. The centre of rotation is the point where you pushed the mouse button down.<br />
* Hold shift when doing the above to constrain movement to yaw or pitch. Note pitch is affected by the centre of rotation.<br />
* Drag the panorama with the right mouse button or hold control and drag with the left to roll the panorama (rotate around the middle)<br />
<br />
If the panorama contains unconnected components, they will move individually.<br />
<br />
== Drag mode ==<br />
This determines what parameters that are changed when the images are dragged.<br />
* Normal - When dragged left-right, the yaw parameter is changed and when dragged up-down the pitch parameter is changed. I.e. the camera is tilted in the yaw and pitch angles.<br />
* Mosaic - When dragged left-right, X parameter is changed and when dragged up-down the Y parameter is changed. I.e. the camera is moved in the X and Y dimensions.<br />
<br />
== [[Image:Hugin_center_pano.png]] Center ==<br />
<br />
This button horizontally ''pans'' the output, changing the [[yaw]] of the remapped images so they fit to the centre of the output frame. This is useful if there is a lot of black space on the left or right of the output. This also performs a '''Fit''', equivalent to the next button.<br />
<br />
Note that centering a [[Rectilinear Projection]] or [[Fisheye Projection]] panorama will change the perspective, this may be unwanted.<br />
<br />
== [[Image:Hugin_fit_pano.png]] Fit ==<br />
<br />
This doesn't change any input image parameters, it just readjusts the output [[Field of View]] such that all the input images are visible. If the images are all off-centre, then there will be a lot of black space.<br />
<br />
== [[Image:Hugin_straighten_pano.png]] Straighten ==<br />
<br />
Straightening the panorama optimises the [[roll]] and [[pitch]] of the input images without changing their relative positions, levelling the panorama in the process. This normally produces good results, if you need more accurate positioning, try adding [[vertical control points]] in the [[hugin Control Points tab]] and reoptimise.<br />
<br />
== Numeric Transform ==<br />
<br />
Enter a '''numerical transform''' to rotate the input images without changing their relative positions - Effectively this rotates the entire panorama. Enter [[roll]], [[pitch]] and [[yaw]] values in degrees.<br />
<br />
= [[Image:Fast_preview_icon_crop.svg]] Crop tab =<br />
<br />
Using this tool you can set the output cropping region interactively. To do this precisely instead, use the [[Hugin Stitcher tab| Stitcher tab]]. Initially, the entire panorama is in the output region (i.e. nothing is cropped).<br />
<br />
To change the cropping at each edge, move the mouse towards that edge until a white box appears along it, then drag with the left mouse button until the edge is where you want it. The darker areas represent the region that is cropped off. You can move two edges at once by moving the mouse towards the corner shared by the edges until both white boxes appear. If you wish to move the whole region at once, move the mouse into the middle so that all four edges have boxes along them and drag.<br />
<br />
== [[Image:Fast_preview_icon_autocrop.svg]] Autocrop ==<br />
<br />
The autocrop button adjusts the crop rectangle so that it is entirely within the image area, i.e. there will be no 'black' borders in the final stitched image. It does this by maximising the area of the rectangle rather than the width or height.<br />
<br />
= In practice =<br />
[[Image:Fast_preview_guide_start.png | thumb | A panorama with unconnected image groups after optimisation.]]<br />
Let's try using this preview to help with a panorama where automatic alignment failed. This panorama was taken where a lot of things were blowing around in the wind, and the clouds were changing quickly, so it is not surprising that it aligning it is a struggle. The [[Hugin Assistant tab|Assistant tab]] tells us there are multiple unconnected image groups. We can optimise the panorama and end up with a images correctly positioned amongst the group they are in, but the groups themselves are not aligned. Try this first. <br />
<br />
[[Image:Fast_preview_guide_drag.png | thumb | Dragging images with the drag tool.]]<br />
Using the Drag tool, we can roughly align the groups together:<br />
# Turn on the tool with the ''Drag'' button.<br />
# Drag each component so the horizon is in the middle, using the left mouse button.<br />
# Drag with the right mouse button (or hold control and drag with the left) to level the horizon.[[Image:Fast_preview_guide_rotate_drag.png | thumb | Rotating images with the drag tool.]]<br />
# Hold shift and drag with the left mouse button sideways to approximately line up the image with the other groups.<br />
<br />
[[Image:Fast_preview_guide_identify.png | thumb | Two images highlighted in the preview window.]]<br />
When we have the images in approximately the right position, we can begin placing control points to guide the optimiser. The Identify tool lends a hand here. Firstly, turn on the identify tool. Move the mouse on an overlap that was recently created between two image groups. The images in the overlap light up. Move the mouse to a place where there is only two images in that overlap, and click. The two images are opened in the [[Hugin Control Points tab|control point editor]] (there may be a short pause while the images are loaded). Once you have placed control points manually, you can return to the preview to find some more image pairs.<br />
<br />
[[Image:Fast_preview_guide_crop.png | thumb | Adjusting the cropping region.]]<br />
When you are happy that your panorama contains sufficient control points, optimise it again. The panorama will likely have the horizon at the wrong angle, in this case press ''Straighten'' on the preview window. You can then frame the panorama using the drag tool (hold shift so you don't make it wonky again!). Use your artistic judgement here. If you want to crop your panorama, click ''Crop'' and drag the edges of the cropping rectangle.<br />
<br />
[[Category:Software:Hugin]]<br />
[[Category:Tutorial:Nice to know]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Preferences&diff=13299Hugin Preferences2011-03-13T23:55:47Z<p>Bruno: /* Control Point Detectors */</p>
<hr />
<div>= General =<br />
<br />
== Resource usage ==<br />
<br />
To speed things up [[Hugin]] keeps a copy in memory of as many input photos as possible. With very large projects, this would use all your system memory, so set '''Image cache memory''' to a value below your available free RAM. The default of 256MB should be ok for a system with 512MB of RAM, however this is very conservative, for large projects you will want to set this to a high proportion of your available system memory.<br />
<br />
The [[Hugin Preview window]] is multi-threaded so can use more than one CPU/core if required. Set '''Number of CPUs''' to how many CPUs you wish to use.<br />
<br />
== User interface ==<br />
<br />
Changing the language of the user interface can be useful e.g. if you want to test your new [[Hugin translation guide|translation]].<br />
<br />
Usually, [[Hugin]] will use the current locale to determine the language of buttons, menus etc...<br />
Set the '''Language''' if you need to switch languages temporarily or if you are using a platform such as Windows95 that doesn't support localised software. Hugin won't change language immediately, you will need to stop and restart it.<br />
<br />
The "language" option in the Hugin Preferences doesn't work for the Mac version. On Mac OS X the system's country settings will be used instead: change the language setting there (i.e. drag the preferred language to the top of the list), and Hugin will reflect that when you restart the program. An alternative but more time consuming way to set another language than the current system language is to quit Hugin, reveal it's icon in the Finder, click on it and open the Information window (Cmd.-I). After deselecting all unwanted language options you can start Hugin in your preferred language.<br />
<br />
== File options ==<br />
<br />
Some [[Hugin]] actions generate large temporary files, change the '''Temporary dir''' to specify an alternative location for writing these files. One reason for setting this independently to the operating system default would be to use a RAM disk to speed up stitching.<br />
<br />
Note that intermediate stitching files are created in the output folder and not in this '''Temporary dir'''.<br />
<br />
= Assistant =<br />
<br />
The [[Hugin Assistant tab]] automates the entire panorama creation process, these<br />
settings allow you to customise the assistant.<br />
<br />
== Image loading ==<br />
<br />
Select '''Automatically align images after loading''' to run the second '''Align...'''<br />
step immediately after loading the images.<br />
<br />
== Automatic control point checking after detecting control points==<br />
<br />
Select '''Remove cloud-like control points (Celeste)''' to run [[Celeste standalone|celeste]] after detecting control points. Celeste will remove [[Control points]] set to clouds, this is useful because clouds will move several pixels between shots and are therefore bad scene objects to use for alignment.<br />
<br />
Select '''Remove outlying control points by statistical method''' to run [[cpclean]], this will try to remove control points with positions that are not credible under pairwise optimisation.<br />
<br />
== Auto align ==<br />
<br />
Auto align uses [[autopano-sift]] or [[autopano]] to generate [[control points]]<br />
between pairs of images, set '''Number of Ctrl Points per overlap''' to control<br />
the number of control points. Note that although most pictures can be stitched<br />
with just three or four control points, automatically generated points tend not<br />
to be very evenly distributed, so this number should be set to ten or more<br />
<br />
The size of the output '''Panorama Image Size''' is usually set in the<br />
[[Hugin Stitcher tab]] where it is also possible to '''Calculate Optimal Size'''<br />
based on the sizes of the input images. The '''Auto align''' process<br />
does something similar, though here you can set a smaller output as a percentage.<br />
Generally setting a percentage of 70% leads to no great loss of quality due to<br />
the way a camera [[CCD]] samples data.<br />
<br />
== Show preview ==<br />
After completing '''Align...''', the [[Hugin Assistant tab]] will usually display the result in a preview window, here you can change this to '''Nothing''' for no preview at all, [[Hugin Fast Preview window|Fast Preview Window]] or [[Hugin Preview window|Preview Window]].<br />
<br />
<br />
<br />
{{clr}}<br />
<br />
= Control Points Editor =<br />
<br />
== HDR and 16bit display ==<br />
<br />
[[Hugin]] supports both [[HDR]] and [[16bit]] imaging. These image formats<br />
contain a lot more brightness and colour information than can be displayed<br />
on a standard computer monitor, so Hugin only shows a rough representation<br />
of these pictures.<br />
<br />
16bit data can have ''linear'' or ''corrected'' [[gamma]]. Linear images<br />
appear very dark on many monitors, so set the '''Curve''' to '''gamma 2.2'''.<br />
<br />
For HDR data, try setting the '''Curve'''<br />
to '''logarithmic'''.<br />
<br />
Changes to the '''HDR and 16bit display mode''' require restarting Hugin to<br />
take effect.<br />
<br />
== Fine-tune ==<br />
<br />
[[Hugin]] helps position [[control points]] to within a fraction of a pixel distance automatically:<br />
<br />
* When '''auto fine-tune''' is selected in the [[Hugin Control Points tab]] while picking control points.<br />
* When clicking '''Fine-tune''' in the [[Hugin Control Points tab]]<br />
* When picking '''Fine-tune all Points''' in the [[Hugin Main window]] '''Edit''' menu.<br />
<br />
* '''Patch width''', the size of the square of pixels taken from the left photo to match with the right photo when picking [[control points]], reduce if this is taking a long time on your system.<br />
* '''Search area width''', the percentage area of the right photo that is searched when picking '''control points''', reduce if this is taking a long time on your system.<br />
* '''Local search area width''', the region of the right photo searched when you click '''Fine-tune''' in the [[Hugin Control Points tab]] or '''Fine-tune all Points''' in the [[Hugin Main window]] '''Edit''' menu.<br />
* '''Correlation Threshold'''. For each '''Fine-tune''', [[Hugin]] calculates the quality of the '''control points''' match, raise this threshold to reject dubious matches.<br />
* '''Peak Curvature Threshold''', Currently unused.<br />
<br />
== Rotation search ==<br />
<br />
Enable this if your photos:<br />
<br />
* have a very wide angle [[Field of View]] or [[fisheye Projection]].<br />
* are tilted up or down, [[control points]] near the [[zenith]] or [[nadir]] may need to have full 360 degree rotation search<br />
<br />
{{clr}}<br />
= Control Point Detectors =<br />
[[Hugin]] uses an internal or external tool for automatically creating [[control points]] for a set of images either when<br />
* clicking the '''2. Align...''' button in the [[Hugin Assistant tab]] or<br />
* clicking the '''Create control points''' button in the [[Hugin Images tab]].<br />
<br />
''Note: If you have upgraded from an older release of Hugin, you will need to '''Load Defaults''' to update these preferences.''<br />
<br />
In the '''Control Point Detector Programs''' list box you can choose between several presets such as:<br />
* '''[[cpfind|Hugin's CPFind]]''' - This is the new general purpose control point generator introduced with Hugin 2010.4.0.<br />
* '''Hugin's CPFind + Celeste''' - This is the same as the [[cpfind|CPFind]] setting plus points in areas of sky are removed using the [[celeste]] tool. See [[Using Celeste with hugin]] for more details.<br />
* '''Cpfind (multirow/stacked)''' - This is the same as the [[cpfind|CPFind]] setting, except that [[Align image stack]] is used to match photos in [[bracketing|bracketed]] stacks.<br />
* '''[[autopano-sift-C]]''' - a C version of [[autopano-sift]], installed separately.<br />
* '''[[Panomatic]] (by Anael Orlinski)''', installed separately.<br />
* '''autopano-sift-c (multirow/stacked)''' - This is the same as the [[autopano-sift-C]] setting, except that [[Align image stack]] is used to match photos in [[bracketing|bracketed]] stacks.<br />
* '''[[Align image stack]]''' - part of Hugin suite. Note that align_image_stack is not a general purpose control point detector, but is very effective for aligning images within stacks.<br />
* '''Align image stack FullFrameFisheye''' - This the same as the [[Align image stack]] setting above except with an addition setting suitable for fisheye images.<br />
<br />
Parameters for these tools can be customized in the [[Hugin Parameters for Control Point Detectors dialog]] which you can access by clicking one of the buttons '''Edit...''' or '''New...'''.<br />
<br />
These [[Hugin Parameters for Control Point Detectors dialog|parameters]] are also helpful if you want to use a similar command line tool that isn't already listed. Click the '''New...''' button to configure a new preset to use in the [[Hugin Assistant tab|Assistant]] or the [[Hugin Images tab|Images]] tabs.<br />
<br />
The '''Set default''' button will mark the preset selected in this list box to be used automatically in the [[Hugin Assistant tab]] when clicking the '''2. Align...''' button.<br />
<br />
= Stitching =<br />
<br />
In the final stitching process [[nona]] reprojects and distorts images to fit, [[enblend]] takes these<br />
images as individual [[TIFF]] files and merges them using sophisticated seam positioning and blending and/or [[Exposure fusion]] into<br />
a single finished image file.<br />
<br />
'''Important note:''' The settings here are the defaults for ''new projects'', change settings for the ''current project'' in the [[Hugin Stitcher tab]].<br />
<br />
== Nona == <br />
<br />
Here you can set the '''Default interpolator''' used during stitching. [[Interpolation]] is a quality setting, but the default of '''Poly3 (Bicubic)''' is good for most purposes. You are unlikely to notice any difference between interpolators other than that '''Nearest neighbor''' is fast but very low quality.<br />
<br />
You can '''Create cropped images by default''', these [[Cropped TIFF]] images will speed up stitching, but some image editors do not process the offsets correctly.<br />
<br />
'''Use GPU for remapping''' will activate experimental [[nona]] code to remap images using the shading language of the ''Graphics Processing Unit'' in modern video hardware. However some projections and the translation parameters are not yet supported by this experimental code. In this case Nona will automatically switch back to CPU calculation.<br />
<br />
== Enblend ==<br />
<br />
The '''Use alternative Enblend program''' option allows you to use other tools with a similar interface<br />
such as [[smartblend]] or [[enblend-mask]].<br />
<br />
enblend supports a range of '''Additional arguments''', for example you may want to set:<br />
<br />
* '''-a''' Pre-assemble non-overlapping images to speed up blending. This is generally useful, but will slow blending in rare cases.<br />
* '''-l number''' Number of levels to use (1 to 29), larger numbers result in wider seams. E.g. setting 1 will result in a 2 pixel wide blend, 8 will result in a 256 pixel wide blend and you are extremely unlikely to want a blend level as high as 16.<br />
<!--* '''-z''' Use LZW compression. The [[TIFF]] file format has a 2GiB limit (or 4GiB or 8GiB, depending on who you ask) so you will find this useful for large panoramas.--><br />
* '''-b kilobytes''' Image cache block size (default=2MiB)<br />
* '''-c''' Use CIECAM02 to blend colors. Your input images need to have embedded [[Colour profile|colour profiles]] for this to work.<br />
* '''-m megabytes''' Use this much memory before going to disk (default=1GiB). Increase if you have a lot of memory on your system.<br />
* '''--fine-mask''' Enables detailed mask generation.<br />
* '''--no-optimize''' Turn off mask optimization.<br />
<br />
Note that setting '''Additional arguments''' here will only effect new projects, to change [[enblend]] and [[enfuse]] settings for the current project use the [[Hugin Stitcher tab]].<br />
<br />
== Enfuse ==<br />
<br />
If one of '''Exposure fusion''' output options is selected in the [[Hugin Stitcher tab]] then [[enfuse]] will be used to merge bracketed exposures during stitching.<br />
<br />
= Celeste =<br />
<br />
Often a project has many control points attached to clouds in the sky, this is usually unwanted as clouds move between photos. [[Using Celeste with hugin|celeste]] will attempt to identify 'sky' control points and delete them.<br />
<br />
= Troubleshooting =<br />
<br />
Sometimes when updating a hugin installation new features such as the settings for a new control point editor won't appear where expected. The cause might be a conflict with the preferences file of a previous version of hugin. A good idea before pressing the "Reset do defaults" button might be to back up the old preferences file since it is a plain text file that contains your specific settings in a readable format. Saving this file gives you the chance to recreate these individual settings later on. The name and location of the preferences file is this for the following platforms:<br />
*Linux: ".hugin" can be found in your home directory '''(FIXME)'''<br />
*Mac OS X: "hugin Preferences" can be found in ''Macintosh HD/Users/<YourUserAccount>/Library/Preferences/''<br />
*Windows: '''(FIXME)'''<br />
Quit hugin, rename the preferences file (e.g. add the previous version number) and on the next start of hugin a new preferences file will be generated.<br />
<br />
Other fixes for occurring problems can be found in the [[Hugin FAQ]].<br />
<br />
{{clr}}<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Control_Points_tab&diff=13296Hugin Control Points tab2011-03-13T22:26:59Z<p>Bruno: /* Keyboard shortcuts */</p>
<hr />
<div>== About Control points ==<br />
[[Control points]] are central to [[Panorama Tools]] and [[hugin]], because they are used to estimate the position of image position and lens parameters described above.<br />
A control point specifies a corresponding point between two images. Using these corresponding points, the [[hugin Optimizer tab]] can estimate the image position and lens parameters.<br />
It is therefore important that the control points are accurate and usually at least 3 well distributed control points should be used to estimate the image position ([[yaw]], [[roll]] and [[pitch]]) and maybe the [[Field of View|HFOV]].<br />
For accurate estimation of the a,b,c distortion parameters, many well distributed control points, and a large overlap (up to 50%) are required.<br />
<br />
== Description ==<br />
The Tab consists of two image displays and associated pull-down lists to switch images to be edited.<br />
The bottom contains a list view where Points can be selected and some fields to edit a selected point.<br />
Points can also be selected by clicking or dragging on them in the images.<br />
It is possible to zoom out to show the full image.<br />
<br />
Entries in the pull-down lists have a coloured block indicating the average quality of the control-points between the selected photos, a short red block indicates a 'bad' alignment, whereas a larger green block indicates a 'good' alignment. No coloured block indicates that there are no control-points between the photos.<br />
<br />
Adding a control point works by selecting one point in the left or right image, and then clicking onto the corresponding point in the other image.<br />
If '''auto add''' is not set, the points can be moved by clicking at some other place in the images.<br />
They are added to the list of control points by pressing the '''right mouse button''', the '''a''' key or by pushing the '''Add''' button.<br />
If you press the '''right mouse button''' when only one point is selected, the point selection will be aborted.<br />
'''auto add''' adds the control point as soon as both points have been specified.<br />
<br />
If the images are zoomed out (fit to window), the first click zooms to a temporary 100% view to give you the chance to refine your selection.<br />
Note that only the second click will trigger the auto estimate.<br />
<br />
For good results, the [[control points]] should be as accurate as possible. However, it is often tedious to select a particular point exactly, and it may be helpful to use the '''arrow keys''' (''left'', ''right'', ''up'', and ''down'') to nudge the selection point in various directions pixel-by-pixel (users of X11 may need to ensure that a particular image pane has the focus by placing the mouse cursor within its bounds). Once a point pair has been roughly selected, the '''fine tune''' function of [[hugin]] can be used to estimate the corresponding point up to one tenth of a pixel.<br />
The keyboard short cut for the '''fine tune''' function is the '''f''' key.<br />
Fine tune only search in a small neighbourhood of the currently selected points.<br />
The size of this neighbourhood can be controlled by opening the [[Hugin Preferences]] panel and setting the '''Local area search width'''.<br />
<br />
Note that the fine tune function estimates the translation of the patch around the point selected in the other image with respect to the current image.<br />
This works well if the rotation between the images is small and narrow angle lenses have been used.<br />
If wide angle or [[Fisheye Projection]] images are used, rotation search should be activated in the [[Hugin Preferences]] panel.<br />
Then [[hugin]] also searches for rotated occurrences of the patch around the selected point.<br />
<br />
The image can be scrolled by pressing the '''middle mouse button''' or the '''CTRL''' key while moving the mouse.<br />
If the '''shift''' key is pressed instead, both images will be scrolled.<br />
This is very useful if [[control points]] are set using the 100% zoom level.<br />
<br />
Control point creation is also influenced by the following check boxes:<br />
<br />
* '''auto fine tune''' [[hugin]] helps you to find the second point by looking for it in a search region (shown by a rectangle around the cursor). This might not always work, but usually is reliable, if the image distortions are not too big. Try and play with it.<br />
* '''auto add''' A control point is automatically added when both points are known. You won't have time to refine the selection before adding the point.<br />
* '''auto estimate''' Tries to estimate the position of the second point by estimating the translation between the two images. This is very crude and probably only works for single row panoramas created from [[Rectilinear Projection]] images.<br />
<br />
All these flags can be combined. I typically use '''auto fine tune''' and '''auto estimate''' at the same time.<br />
Then [[hugin]] usually automatically selects the second point correctly, at least for normal, [[Rectilinear Projection]] images that are not rotated too much.<br />
<br />
[[hugin]] also includes an experimental [[control points]] creation algorithm.<br />
It can be invoked by pressing the '''g''' key. Corners in the currently selected image are detected, and corresponding control points are set based on the current relative positions of the two images. The images need to be approximately aligned already for this to be useful. Note that these points then need to be aligned by eye, with the '''Fine-tune''' button or with the '''Fine-tune all Points''' function in the Edit menu of the [[Hugin Main window]].<br />
<br />
== Control point mode ==<br />
<br />
Use the '''mode''' pull down menu to change the type of an existing pair of [[control points]].<br />
<br />
=== normal control points ===<br />
<br />
The '''normal''' control point mode is used to align pairs of overlapping photos by matching<br />
identical features in both photos.<br />
<br />
=== vertical line and horizontal line control points ===<br />
<br />
Pairs of [[vertical control points]] and [[horizontal control points]] are different from<br />
'''normal''' control points since they are used to align input images to particular alignments<br />
in the output panorama rather than simply stitching images together.<br />
<br />
Select two points along a feature that you want to be aligned vertically or horizontally in<br />
the final panorama. If these are in the same photo, [[hugin]] will usually detect that you are<br />
trying to create ''horizontal'' or ''vertical'' control points and set the mode appropriately,<br />
if they are in different photos then you will need to set the mode manually.<br />
<br />
Typically ''horizontal'' and ''vertical'' points are used either to [[Leveling a Finished Panorama|level a spherical panorama]]<br />
or to [[Perspective correction|correct perspective]].<br />
<br />
=== Straight line control points ===<br />
<br />
Adding [[straight line control points]] is basically the same as<br />
creating '''horizontal control points''' and '''vertical control points''', except that you<br />
need more than just one pair to make up a straight line.<br />
<br />
Create a pair of points in the '''hugin Control Points tab''', then pick<br />
'''Add new line''' in the '''mode''' pull-down. This first line will be called<br />
'''Line 3''', you can assign more pairs of points to it using the same<br />
'''mode''' pull-down.<br />
<br />
== Keyboard shortcuts ==<br />
<br />
Here is a summary of the keyboard shortcuts available in the Control Point tab:<br />
<br />
Key Function<br />
<br />
* '''a''' add a new point that has been selected in both images, and the '''auto add''' is switched off.<br />
* '''f''' fine tune currently selected control point pair. Same as the '''Fine Tune''' button<br />
* '''g''' experimental control point generation algorithm.<br />
* '''Del''' Remove currently selected control point.<br />
* '''0''' Zoom out to full view.<br />
* '''1''' 100% view.<br />
* '''2''' 200% view.<br />
* '''arrow keys''' nudge a selection point or selected control point around pixel-by-pixel.<br />
* '''shift + arrow keys''' scroll both images at the same time.<br />
* '''Ctrl + left arrow''' and '''Ctrl + right arrow''' switch to the next pair of photos.<br />
<br />
Mouse function Function<br />
<br />
* '''control key + mouse movement''' Scroll image under cursor<br />
* '''shift key + mouse movement''' Scroll both images<br />
* '''left button''' Use left mouse button to select new points or drag existing points.<br />
* '''right mouse button''' Add control point, if '''auto add''' is switched off<br />
* '''middle mouse button''' Scroll image under cursor<br />
* '''shift + middle mouse button''' Scroll both images<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Control_Points_tab&diff=13294Hugin Control Points tab2011-03-13T22:19:16Z<p>Bruno: /* Keyboard shortcuts */</p>
<hr />
<div>== About Control points ==<br />
[[Control points]] are central to [[Panorama Tools]] and [[hugin]], because they are used to estimate the position of image position and lens parameters described above.<br />
A control point specifies a corresponding point between two images. Using these corresponding points, the [[hugin Optimizer tab]] can estimate the image position and lens parameters.<br />
It is therefore important that the control points are accurate and usually at least 3 well distributed control points should be used to estimate the image position ([[yaw]], [[roll]] and [[pitch]]) and maybe the [[Field of View|HFOV]].<br />
For accurate estimation of the a,b,c distortion parameters, many well distributed control points, and a large overlap (up to 50%) are required.<br />
<br />
== Description ==<br />
The Tab consists of two image displays and associated pull-down lists to switch images to be edited.<br />
The bottom contains a list view where Points can be selected and some fields to edit a selected point.<br />
Points can also be selected by clicking or dragging on them in the images.<br />
It is possible to zoom out to show the full image.<br />
<br />
Entries in the pull-down lists have a coloured block indicating the average quality of the control-points between the selected photos, a short red block indicates a 'bad' alignment, whereas a larger green block indicates a 'good' alignment. No coloured block indicates that there are no control-points between the photos.<br />
<br />
Adding a control point works by selecting one point in the left or right image, and then clicking onto the corresponding point in the other image.<br />
If '''auto add''' is not set, the points can be moved by clicking at some other place in the images.<br />
They are added to the list of control points by pressing the '''right mouse button''', the '''a''' key or by pushing the '''Add''' button.<br />
If you press the '''right mouse button''' when only one point is selected, the point selection will be aborted.<br />
'''auto add''' adds the control point as soon as both points have been specified.<br />
<br />
If the images are zoomed out (fit to window), the first click zooms to a temporary 100% view to give you the chance to refine your selection.<br />
Note that only the second click will trigger the auto estimate.<br />
<br />
For good results, the [[control points]] should be as accurate as possible. However, it is often tedious to select a particular point exactly, and it may be helpful to use the '''arrow keys''' (''left'', ''right'', ''up'', and ''down'') to nudge the selection point in various directions pixel-by-pixel (users of X11 may need to ensure that a particular image pane has the focus by placing the mouse cursor within its bounds). Once a point pair has been roughly selected, the '''fine tune''' function of [[hugin]] can be used to estimate the corresponding point up to one tenth of a pixel.<br />
The keyboard short cut for the '''fine tune''' function is the '''f''' key.<br />
Fine tune only search in a small neighbourhood of the currently selected points.<br />
The size of this neighbourhood can be controlled by opening the [[Hugin Preferences]] panel and setting the '''Local area search width'''.<br />
<br />
Note that the fine tune function estimates the translation of the patch around the point selected in the other image with respect to the current image.<br />
This works well if the rotation between the images is small and narrow angle lenses have been used.<br />
If wide angle or [[Fisheye Projection]] images are used, rotation search should be activated in the [[Hugin Preferences]] panel.<br />
Then [[hugin]] also searches for rotated occurrences of the patch around the selected point.<br />
<br />
The image can be scrolled by pressing the '''middle mouse button''' or the '''CTRL''' key while moving the mouse.<br />
If the '''shift''' key is pressed instead, both images will be scrolled.<br />
This is very useful if [[control points]] are set using the 100% zoom level.<br />
<br />
Control point creation is also influenced by the following check boxes:<br />
<br />
* '''auto fine tune''' [[hugin]] helps you to find the second point by looking for it in a search region (shown by a rectangle around the cursor). This might not always work, but usually is reliable, if the image distortions are not too big. Try and play with it.<br />
* '''auto add''' A control point is automatically added when both points are known. You won't have time to refine the selection before adding the point.<br />
* '''auto estimate''' Tries to estimate the position of the second point by estimating the translation between the two images. This is very crude and probably only works for single row panoramas created from [[Rectilinear Projection]] images.<br />
<br />
All these flags can be combined. I typically use '''auto fine tune''' and '''auto estimate''' at the same time.<br />
Then [[hugin]] usually automatically selects the second point correctly, at least for normal, [[Rectilinear Projection]] images that are not rotated too much.<br />
<br />
[[hugin]] also includes an experimental [[control points]] creation algorithm.<br />
It can be invoked by pressing the '''g''' key. Corners in the currently selected image are detected, and corresponding control points are set based on the current relative positions of the two images. The images need to be approximately aligned already for this to be useful. Note that these points then need to be aligned by eye, with the '''Fine-tune''' button or with the '''Fine-tune all Points''' function in the Edit menu of the [[Hugin Main window]].<br />
<br />
== Control point mode ==<br />
<br />
Use the '''mode''' pull down menu to change the type of an existing pair of [[control points]].<br />
<br />
=== normal control points ===<br />
<br />
The '''normal''' control point mode is used to align pairs of overlapping photos by matching<br />
identical features in both photos.<br />
<br />
=== vertical line and horizontal line control points ===<br />
<br />
Pairs of [[vertical control points]] and [[horizontal control points]] are different from<br />
'''normal''' control points since they are used to align input images to particular alignments<br />
in the output panorama rather than simply stitching images together.<br />
<br />
Select two points along a feature that you want to be aligned vertically or horizontally in<br />
the final panorama. If these are in the same photo, [[hugin]] will usually detect that you are<br />
trying to create ''horizontal'' or ''vertical'' control points and set the mode appropriately,<br />
if they are in different photos then you will need to set the mode manually.<br />
<br />
Typically ''horizontal'' and ''vertical'' points are used either to [[Leveling a Finished Panorama|level a spherical panorama]]<br />
or to [[Perspective correction|correct perspective]].<br />
<br />
=== Straight line control points ===<br />
<br />
Adding [[straight line control points]] is basically the same as<br />
creating '''horizontal control points''' and '''vertical control points''', except that you<br />
need more than just one pair to make up a straight line.<br />
<br />
Create a pair of points in the '''hugin Control Points tab''', then pick<br />
'''Add new line''' in the '''mode''' pull-down. This first line will be called<br />
'''Line 3''', you can assign more pairs of points to it using the same<br />
'''mode''' pull-down.<br />
<br />
== Keyboard shortcuts ==<br />
<br />
Here is a summary of the keyboard shortcuts available in the Control Point tab:<br />
<br />
Key Function<br />
<br />
* '''a''' add a new point that has been selected in both images, and the '''auto add''' is switched off.<br />
* '''f''' fine tune currently selected control point pair. Same as the '''Fine Tune''' button<br />
* '''g''' experimental control point generation algorithm.<br />
* '''Del''' Remove currently selected control point.<br />
* '''0''' Zoom out to full view.<br />
* '''1''' 100% view.<br />
* '''2''' 200% view.<br />
* '''arrow keys''' nudge a selection point or selected control point around pixel-by-pixel.<br />
* '''shift + arrow keys''' scroll both images at the same time.<br />
<br />
Mouse function Function<br />
<br />
* '''control key + mouse movement''' Scroll image under cursor<br />
* '''shift key + mouse movement''' Scroll both images<br />
* '''left button''' Use left mouse button to select new points or drag existing points.<br />
* '''right mouse button''' Add control point, if '''auto add''' is switched off<br />
* '''middle mouse button''' Scroll image under cursor<br />
* '''shift + middle mouse button''' Scroll both images<br />
<br />
[[Category:Software:Hugin]]</div>Brunohttps://wiki.panotools.org/index.php?title=Hugin_Keyboard_shortcuts&diff=13293Hugin Keyboard shortcuts2011-03-13T22:13:07Z<p>Bruno: /* General shortcuts */</p>
<hr />
<div>== General shortcuts ==<br />
The following keyboard shortcuts are available anywhere in [[hugin]]:<br />
<br />
* '''Ctrl-N''', discard the current project and start a new empty project.<br />
* '''Ctrl-O''', open an existing [[hugin]], [[PTGUI]], [[PTAssembler]], [[autopano]] or [[autopano-sift]] project file.<br />
* '''Ctrl-S''', save the current project as a hugin ''pto'' file.<br />
* '''Ctrl-Q''', quit hugin.<br />
* '''Ctrl-Z''', undoes the most recent change to the current project.<br />
* '''Ctrl-R''', redoes an undo.<br />
* '''Ctrl-T''', re-optimises the current project. This has exactly the same effect as clicking '''Optimize Now!''' in the [[hugin Optimizer tab]].<br />
* '''Ctrl-P''', shows the [[hugin Preview window]].<br />
* '''Ctrl-A''', selects all photos in the [[Hugin Images tab]], [[Hugin Camera and Lens tab]] and [[Hugin Crop tab]] selects all points in the [[Hugin Control Points table]].<br />
* '''Delete''' and '''Insert''' in the [[Hugin Images tab]] removes and adds photos to the project.<br />
* '''<F1>''', opens the [[hugin]] manual.<br />
* '''<F3>''', shows the [[hugin Control Points table]].<br />
* '''<F11>''', toggles Full Screen mode. Note that the [[Hugin Main window]] and the [[Hugin Fast Preview window]] can be maximised to full screen independently.<br />
* '''Shift-<F1>''', '''Shift-<F2>''',...'''Shift-<F9>''' switches between the tabs in the main window.<br />
* '''Ctrl-Tab''', '''Ctrl-Shift-Tab''', jumps from tab to tab to the right and to the left in the main window (if frontmost).<br />
<br />
== Additional shortcuts ==<br />
In addition to this there are a number of keyboard shortcuts available only in<br />
the [[hugin Control Points tab#Keyboard_shortcuts|hugin Control Points tab]].<br />
<br />
[[Category:Software:Hugin]]</div>Bruno