[hugin-ptx] Command line stitching through Hugin
I am trying to stitch images through command line of Hugin (http:// wiki.panotools.org/Panorama_scripting_in_a_nutshell#Simple_command- line_stitching) I did the first step to create control points that is: autopano-sift-c --projection 0,50 project.pto DSC_1234.JPG DSC_1235.JPG DSC_1236.JPG But when i write this command: celeste_standalone -i project.pto -o project.pto This error comes: Couldn't open SVM model file celeste.model Also tried G:/huginbase/hugin-huild/INSTALL/FILES/share/ hugin/data/celeste.model Also for optimizer command they say HFOV value is invalid. I tried using autooptimiser -v 50 -a -l -s -m -o optimised.pto project.pto and still the same error occurred. Could someone please help me out -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: multiblend - a faster alternative to Enblend (Win x86/x64 binaries and source code) - v0.2 with JPEG support + bugfixes
Although this is slightly off topic, I feel I should mention it. On Monday, January 16, 2012 6:05:15 PM UTC+1, Monkey wrote: I've updated the download archive now - I haven't changed the version number as the fix doesn't change multiblend's functionality. Please do update version numbers if the contents of the file have changed. There may be various reasons why this should be done, but one in particular that I know of is this: There exists a cross compiler environment named Mingw-cross-env [0], which relies on the file name for versioning. Part of the script is an update procedure which checks if newer files are available. Obviously this will fail if the filename hasn't changed. Moreover, it includes a hash based check to see if the downloaded file is indeed the file we are looking for (a basic sanity check). And this part will fail if the *contents* of the file with the same file name have changed. Although this is mostly important for libs, I guess it's good practice to apply this reasoning to other packages as well. This statement is not only applicable to multiblend, it also affects any other package. I believe Hugin itself doesn't suffer from this as version numbers are properly used in file names on sourceforge (note: behavior not recently tested). [0] http://mingw-cross-env.nongnu.org/ -- Bart -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: multiblend - a faster alternative to Enblend (Win x86/x64 binaries and source code) - v0.2 with JPEG support + bugfixes
2012/1/23 Bart van Andel bavanan...@gmail.com Although this is slightly off topic, I feel I should mention it. On Monday, January 16, 2012 6:05:15 PM UTC+1, Monkey wrote: I've updated the download archive now - I haven't changed the version number as the fix doesn't change multiblend's functionality. Please do update version numbers if the contents of the file have changed. There may be various reasons why this should be done, but one in particular that I know of is this: There exists a cross compiler environment named Mingw-cross-env [0], which relies on the file name for versioning. Part of the script is an update procedure which checks if newer files are available. Obviously this will fail if the filename hasn't changed. Moreover, it includes a hash based check to see if the downloaded file is indeed the file we are looking for (a basic sanity check). And this part will fail if the *contents* of the file with the same file name have changed. Although this is mostly important for libs, I guess it's good practice to apply this reasoning to other packages as well. This statement is not only applicable to multiblend, it also affects any other package. I believe Hugin itself doesn't suffer from this as version numbers are properly used in file names on sourceforge (note: behavior not recently tested). [0] http://mingw-cross-env.nongnu.org/ -- Bart It's not off topic and I completely agree with you. I wanted to react as well but completely forgot (one get's older). You have versions, subversions and bugfixes. On some OSes you have something like: x.y.z, where x is a major change, y are minor changes and z are bugfixes. Also: where y is an equal number we speak about stable versions and where y is an odd number we speak of development versions. For packaging and bugfixing you could even have x.y.z-a, where a is a change in configuration or configure script, package configuration or even a bug fix (whether or not in the configuring or packaging part). Maybe that's all way over the top, but please update the versions with something like 0.2.1 or 0.2a like you did earlier. It makes it clear to anyone that something has changed compared to the previous version. Harry -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
