[hugin-ptx] Re: possible memory leak in enblend enfuse?
On Oct 13, 10:52 pm, Harry van der Wolf hvdw...@gmail.com wrote: For the time being I will await Christoph Spiel's actions as he also modified the patch for the current enblend version that is being used but he did not yet add it to the Enblend trunk. The change has just been committed. See, e.g., http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/diff/75de5e1ffce6/src/mask.h I assume he has a good reason for this modification. Oh, I just wanted to follow the DRY principle and to heed Roger's concerns about the runtime penalty of an if-clause inside the loop of all snake segments. Nothing fancy, really. /Chris --~--~-~--~~~---~--~~ 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] Hugin patches tracker
I've just tried to submit a patch for the italian translation of Hugin from this page http://sourceforge.net/tracker/?group_id=77506atid=550443 and I've received an error saying that I need to be registered to sourceforge to submit it. When is this changed? I'm doing something wrong or do I really need to be registered to send only some translation patch? Thanks Cristian --~--~-~--~~~---~--~~ 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: Next GUI - take 2
On 13 okt, 19:18, Yuval Levy goo...@levy.ch wrote: Also: wxPython has the same widgets as wxWidgets in C++ and one of the things to consider, since this is becoming a complete rewrite, is to start from scratch a wxPython GUI to replace the current C++ GUI. I haven't programmed either wx*, so I really don't know, but will that allow for the application to become completely scriptable? Like, you can write a script which basically replaces the current wizard tab (but still looks and works the same), and for a different workflow, this script can be modified to show a slightly different wizard. In other words: the GUI is built on-the-fly from a GUI script kind of file. Could be XML or whatever. This way Hugin could be made even less dependent on the exact tools used. Plugins could exist of (for instance) an executable and an XML file which specifies the name, version, what kind of executable it is, and how to use / call it (e.g., autopano, keypoint finder, autopano %imgfiles%) I've had another idea in my mind for some time now. It may sound a little too fancy or even surreal, but I guess this shouldn't stop me from writing it down here. that's a good idea, just a little bit ahead of time, and beyond the means of this specific project team. to push it even further and summarize it in a paragraph, imagine a tool placing the photos in real 3D space. imagine navigating the real 3D space, move between the images, freely. place any 3D structure anywhere in that space. place a point somewhere in space and project from that point to the 3D structure through the images. want ortographic projection? possible too. And then all of a sudden the 3D pixel cloud liberates itself from the flat 2D pictures Blender is the user interface for this. The project would not be the next GUI for Hugin. It would be full 3D extension for libpano; and then integration in Blender. Personally, the last time I've tried Blender, I found it not too intuitive to use. Writing a 3D engine with game-like controls isn't necessarily hard, but could be far easier to navigate than Blender (at least in my rather limited experience). Of course it might be even better to create a package which could be used both as a plugin for Blender *and* with a standalone 3D engine. Or we could use the Quake 3 [1] or Doom 3 [2] engine ;) -- Bart [1] http://en.wikipedia.org/wiki/Id_Tech_3 [2] http://en.wikipedia.org/wiki/Id_Tech_4 (source not yet released) --~--~-~--~~~---~--~~ 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: building libpano on windows using cmake
Am Tuesday 13 October 2009 schrieb allard:
Hi all,
Hi Allard,
I've fixed most of the problems I had building libpano (SVN1093 a.k.a.
beta3) with CMake on windows, but there's one little thing I still
can't get right.
Nice :)
First the solved problems:
I had to replace ADD_DEFINITIONS(-D__Win__) in Cmakelists.txt with
ADD_DEFINITIONS(-D__Ansi__) to get rid of some unresolved symbol
errors (thanks for the tip Jim Watters)
What is your compiler, maybe we could do it compiler-dependent
In fftn.c, the following line of code produced 'not found' errors
# include __FILE__
How is it possible, that _FILE_ does not expand to a valid path on your system?
so I replaced it by
# include fftn.c
Then, there is apparently some confusion about where the pano13.lib is
supposed to be located. When building the debug version, it is created
in the folder 'Debug', which is created under the build directory. But
subsequent tools sometimes expect it to be in the 'tools' folder.
Copying pano13.lib there eliminates the errors. edit upgrading to
svn1098 also
This Debug-folder was new to me. Somehow I start to think, that even cmake is
very platform independent.
Don't have here appropiate windows machine, so cannot help much.
You may try add this library in tools/CMakeLists.txt
line 18++:
if(WIN32)
list(APPEND commands panoinfo)
list(APPEND _common_libs ../Debug/pano13.lib)
endif()
After this, a lot of unresolved symbol errors related to getopt kept
showing up. Copying the compat_win32 folder all over the place didn't
help. Finally, I managed to get rid of them by adding the following
line to PTCommon.c:
#include tools/compat_win32/getopt.c
Only the .h file was included, apparently this was not enough.
Here I would add tools/compat_win32/getopt.c to the list of sources ov pano13
lib
like (from line 46 on):
IF(WIN32)
SET(wxWidgets_ROOT_DIR ${SOURCE_BASE_DIR}/wxWidgets-2.8.10)
ADD_DEFINITIONS(-D__Win__)
FIND_PACKAGE(wxWidgets REQUIRED)
SET(win_c tools/compat_win32/getopt.c)
ENDIF(WIN32)
I don't know if all of these solutions I found by trial and error are
good practice, but they seem to have worked. Suggestions for how to do
it better are welcome. All tools build now, except for PTBlender. This
gives an error that says:
pano13.lib(ColourBrightness.obj) : error LNK2019: unresolved external
symbol _ht...@4 referenced in function _OutputPhotoshopCurve
_htons is network. It transforms local (short) data to network order.
On OpenSuSE it is in library /usr/lib/libc.a, which is part of package
glibc-devel.
Any idea what could cause that?
Allard
Please try and report here.
Kornel
--
Kornel Benko
kornel.be...@berlin.de
signature.asc
Description: This is a digitally signed message part.
[hugin-ptx] Re: what is hugin doing to the exposure?
Thanks for your rather elaborate answer, Yuv. Of course you're completely right (and I'm dead serious too, sorry that I misunderstood). You can never really trust anything you download, or rely blindly on what a program says to be. What about a new command line argument --version which gives detailed version information, like: version number, build state (alpha/ beta/rc/release etc), which branch (can this even be done automatically?) you're trying to solve the wrong problem with the wrong tool. I wasn't trying to really *solve* this problem with the --version idea. I was only mentioning it because it *might* help making different versions / builds *better* distinguishable than they are now. Of course anyone can still tamper with it. But at least with versions downloaded from sf.net, it may become easier to point a finger correctly. As long as people download their builds (or, albeit a little less reliable, unaltered source code) from sf.net and find problems, they can tell with a higher accuracy which version is to blame. By the way I'm just copying the --version idea from lots of other tools available everywhere. If so many tools are using it, I reckon it can't be that bad an idea... Sounds like a nice job for a fresh Hugin programmer (including myself, but I currently should really be doing other things). yeah, right. there are always other things to do. I really *want* to dive into the hugin source code, but I know it will take more time than I should currently spend. It's a matter of priority, and there are only so many hours in a week/day etc. In time, I will... -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Hugin patches tracker
Christian, Last week a new Bug Reporting policy was announced: http://groups.google.com/group/hugin-ptx/browse_thread/thread/122034ab50b95685?hl=en-GB# It was in response to there being too many anonymous bug reports that were incomplete/inconclusive and impossible to follow-up. I don't know for certain ... but I would guess that submitting a patch falls within the scope of the new policy. all the best George On 14 Oct, 11:52, cri cri.pe...@gmail.com wrote: I've just tried to submit a patch for the italian translation of Hugin from this pagehttp://sourceforge.net/tracker/?group_id=77506atid=550443 and I've received an error saying that I need to be registered to sourceforge to submit it. When is this changed? I'm doing something wrong or do I really need to be registered to send only some translation patch? Thanks Cristian --~--~-~--~~~---~--~~ 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: possible memory leak in enblend enfuse?
Hi Chris,
On Wed, Oct 14, 2009 at 12:55:23AM -0700, cspiel wrote:
Oh, I just wanted to follow the DRY principle and to heed Roger's
concerns about the runtime penalty of an if-clause inside the loop
of all snake segments. Nothing fancy, really.
I wasn't concerned about the runtime impications of the if. I simply
dislike a special case for a situation that should be possible to
handle in the main loop.
so strcmp is defined to be implemented as:
while (*a (*a == *b)) {
a++; b++
}
return *a-*b;
No speclial cases, quickly handle end-of-string etc etc. Nice and
neat.
Similarly, the case of rotating a list that has only one element on
one of the ends should not need special casing.
I was more concerned with the neatness of the code, and the size of
the code base. If the program grows and grows, it will too quickly
become unmaintainable.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--~--~-~--~~~---~--~~
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: Hugin patches tracker
On Wed 14-Oct-2009 at 03:52 -0700, cri wrote: I've just tried to submit a patch for the italian translation of Hugin from this page http://sourceforge.net/tracker/?group_id=77506atid=550443 and I've received an error saying that I need to be registered to sourceforge to submit it. When is this changed? I'm doing something wrong or do I really need to be registered to send only some translation patch? We have far too many anonymous bug reports in the tracker where we really need to contact the submitter for more information. Sorry, this restriction isn't fine grained enough to only apply to 'bugs' and not 'patches'. You can send me translations directly and I promise to make sure they get integrated (email bruno at postle dot net). -- Bruno --~--~-~--~~~---~--~~ 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: possible memory leak in enblend enfuse?
Hi,
A correct fix will require determining the cause of the two-point
snake. A two-point polygon has zero area, so it is unclear what region
of the mask this is outlining. Perhaps the mask has isolated
single-pixel spots of black and white? E.g. if the user set the input
alpha masks with spots like this. Maybe the contour iterator does not
handle this case gracefully.
Andrew
On Wed, Oct 14, 2009 at 6:51 AM, Rogier Wolff
rew-googlegro...@bitwizard.nl wrote:
Hi Chris,
On Wed, Oct 14, 2009 at 12:55:23AM -0700, cspiel wrote:
Oh, I just wanted to follow the DRY principle and to heed Roger's
concerns about the runtime penalty of an if-clause inside the loop
of all snake segments. Nothing fancy, really.
I wasn't concerned about the runtime impications of the if. I simply
dislike a special case for a situation that should be possible to
handle in the main loop.
so strcmp is defined to be implemented as:
while (*a (*a == *b)) {
a++; b++
}
return *a-*b;
No speclial cases, quickly handle end-of-string etc etc. Nice and
neat.
Similarly, the case of rotating a list that has only one element on
one of the ends should not need special casing.
I was more concerned with the neatness of the code, and the size of
the code base. If the program grows and grows, it will too quickly
become unmaintainable.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--~--~-~--~~~---~--~~
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] Message for Chris Spiel.
Hi Chris, I found why you didn't get my mail message: Your mail server refuses my messages: Your problem! We get a fixed IP address (always the same) from our provider, so it's wrong to call this a dynamic IP. And even if it is a dynamic IP, it is wrong to refuse Email from those IP addresses. Roger. -- Hi. This is the qmail-send program at abra2.bitwizard.nl. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. csp...@freenet.de: 195.4.92.9 does not like recipient. Remote host said: 550 Submission from dynamic IP 80.101.171.8 requires authentication Giving up on 195.4.92.9. --- Below this line is a copy of the message. Return-Path: r.e.wo...@bitwizard.nl Received: (qmail 6647 invoked by uid 1000); 14 Oct 2009 16:25:41 +0200 Date: Wed, 14 Oct 2009 16:25:41 +0200 From: Rogier Wolff r.e.wo...@bitwizard.nl To: csp...@freenet.de Subject: Fwd: [hugin-ptx] Re: possible memory leak in enblend enfuse? Message-ID: 20091014142540.ga6...@bitwizard.nl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: BitWizard.nl User-Agent: Mutt/1.5.13 (2006-08-11) - Forwarded message from cspiel csp...@freenet.de - 2. An Enblend version called 3.22 never has existed. I found why I said 3.22 : I'm also patching procmail which /is/ at 3.22 ! Sorry for confusing the two. Roger. -- -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ 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: Hugin patches tracker
Bruno Postle wrote: We have far too many anonymous bug reports in the tracker where we really need to contact the submitter for more information. that's for the bug tracker. Sorry, this restriction isn't fine grained enough to only apply to 'bugs' and not 'patches'. You can send me translations directly and I promise to make sure they get integrated (email bruno at postle dot net). the restriction on the patch tracker is intended. accepting code contributions anonymously is a serious risk: you don't know who your donor is, and whether the code really belongs to him or it was borrowed somewhere else (with disregard for licensing terms). Granted: this should not affect translations (nor small patches / error fixes), but translations are like code for the patch. It is frustrating not to be able to follow up with the donor and get some sort of origin certification. Other than private mailing Bruno, you can add your translation as a file to this GoogleGroup and let us know. Both private mail and access to the GoogleGroup are non-anonymous - an email address is enough of a contact to verify the source. Apology for the inconvenience. An SF account is very easy to open, they never spam, and you can log on with OpenID from one of your other online accounts. Yuv --~--~-~--~~~---~--~~ 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: Next GUI - take 2
On Wed 14-Oct-2009 at 10:29 -0400, Nicolas Pelletier wrote: This is currently set up as a one to one match, but should be a one to many I think: The first part could be done with (one per project): - Many images with control points and aligned with nona - A single equirectangular - 6 cube faces And the second one could be a series of output (many per project): - A low rez stereographic projection centered at X - A higher rez stereographic projection centered at Y and with a smaller FOV - A HDR equirectangular for postprocess elsewhere (with an alignment different from the other ones) The problem with stitching one-to-many is that you really don't want to repeat the stitch for each of your output 'views' - Not only will this take forever, but your seam lines will be in different places each time. The right way to do this is to stitch a 'base' equirectangular of the scene, then generate different projections/views from this. You can do this in Hugin, just import the equirectangular into a new project and use the various output projections, or use Tom's Panini tool which is specifically designed for extracting different views. What I'm trying to say is that the 'many' part is necessarily a post-processing step, and doesn't really benefit from being integrated into Hugin. -- Bruno --~--~-~--~~~---~--~~ 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: what is hugin doing to the exposure?
On Wed 14-Oct-2009 at 05:14 -0700, Bart van Andel wrote: By the way I'm just copying the --version idea from lots of other tools available everywhere. If so many tools are using it, I reckon it can't be that bad an idea... With the current Hugin trunk the command-line tools -h option does tell you the exact current version: nona -h nona: stitch a panorama image nona version 2009.5.0.4622 The next enblend release will have a --version string that includes all sorts of information including the name of the person who built the binary. -- Bruno --~--~-~--~~~---~--~~ 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: Next GUI - take 2
On Tue 13-Oct-2009 at 01:41 -0700, grow wrote: My experience of the current model is that it is a pipe-line with only one possible input opening. One variation that I have wished for when problems arise is provoked by the fact that in the current model Hugin will give me some of the intermediate files as well as the final result allowing me to use them in post-Hugin-processing in Photoshop or Gimp etc. What I have often itched for, is for Hugin to let me intervene on some of those intermediate files and then restart the Hugin process at a mid-point. The Makefile stitching process allows exactly this, unfortunately it is only currently available on the command-line. i.e. save the project in Hugin but stitch using the shell: make -f project.pto.mk Edit an intermediate file and repeat the command-line, only relevant processing will be redone. It would be really nice for the Batch Processor to support this kind of workflow. -- Bruno --~--~-~--~~~---~--~~ 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: Flipping Photos Review
It already exists. http://search.cpan.org/~bpostle/Panotools-Script-0.23/bin/panostart I believe I used Alexandre Jenny's Autopano on the command line for this purpose. And generally it worked quite well, as long as panoramas didn't contain too similar photos. Anyway I would like to try those Panotools-Scripts. But to me it looks like they are not ready to run on Windows (with perl installed) right out of the box. Could someone give me a hint about what to do to make them usable on Windows? regards Joachim --~--~-~--~~~---~--~~ 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: Flipping Photos Review
AKS-Gmail-IMAP schrieb: ... It is not necessary to wait for the process to compare all 25 images in a project to the 26th image when you know only the Xth image has points in common with the 26th. If you are using OS X, it is the Command key that allows one to select multiple images in the list that are non-consecutive. This is more of a workaround than a workflow for everyday use. Choosing consecutive images to get cps generated is generally OK but tedious if you have a simple one-row panorama. But in a (maybe hand-held) mosaic you don't want to spend your time on deciding which images might overlap a bit and which don't. When I have problems like this (quite often) I try to find the wrong cps by sorting the cp table by e.g. left image number and then have a look which images are listed in the right image column. This way pairs that don't belong together are often quite easy to identify. But now this should be even easier with the new feature of showing cp pairs as lines in the fast preview. regards Joachim --~--~-~--~~~---~--~~ 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: Next GUI - take 2
I'm not convinced it is a post processing step. I think it depends on where we draw the what should hugin do boundary. I'm currently working with the exact workflow you mentioned, create a 360 180 equi and then use this as the first element in the chain. But if the other steps were only post processing, then why should we have other projections and other import method? Also, from this equirectangular, if we had many output, we could have a nice workflow that generate all 6 faces of the cubes for some VR interface without needing another tool, or swapping around with the same project or 6 projects. only my 2 cents... nick On Wed, Oct 14, 2009 at 2:00 PM, Bruno Postle br...@postle.net wrote: On Wed 14-Oct-2009 at 10:29 -0400, Nicolas Pelletier wrote: This is currently set up as a one to one match, but should be a one to many I think: The first part could be done with (one per project): - Many images with control points and aligned with nona - A single equirectangular - 6 cube faces And the second one could be a series of output (many per project): - A low rez stereographic projection centered at X - A higher rez stereographic projection centered at Y and with a smaller FOV - A HDR equirectangular for postprocess elsewhere (with an alignment different from the other ones) The problem with stitching one-to-many is that you really don't want to repeat the stitch for each of your output 'views' - Not only will this take forever, but your seam lines will be in different places each time. The right way to do this is to stitch a 'base' equirectangular of the scene, then generate different projections/views from this. You can do this in Hugin, just import the equirectangular into a new project and use the various output projections, or use Tom's Panini tool which is specifically designed for extracting different views. What I'm trying to say is that the 'many' part is necessarily a post-processing step, and doesn't really benefit from being integrated into Hugin. -- Bruno --~--~-~--~~~---~--~~ 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: Next GUI - take 2
On Wed 14-Oct-2009 at 16:09 -0400, Nicolas Pelletier wrote: I'm not convinced it is a post processing step. I think it depends on where we draw the what should hugin do boundary. I guess that where I'm coming from is that Hugin and the Stitcher tab are complex enough as it is. I'm currently working with the exact workflow you mentioned, create a 360 180 equi and then use this as the first element in the chain. But if the other steps were only post processing, then why should we have other projections and other import method? Mainly because we can, but also because partial panoramas are legitimate targets, and because people have a use for stitching partial equirectangular and cylindrical input. Also, from this equirectangular, if we had many output, we could have a nice workflow that generate all 6 faces of the cubes for some VR interface without needing another tool, or swapping around with the same project or 6 projects. We do actually have much of this (cubic, little-planet, thumbnails, QTVR, PanoSalado etc...) as targets in the Makefile.equirect.mk plugin - It would be trivially easy to enable this stuff in the Stitcher tab or the Batch Processor, but it adds a bunch of dependencies (ImageMagick, perl(Panotools::Script)). You can do this in Hugin, just import the equirectangular into a new project and use the various output projections, or use Tom's Panini tool which is specifically designed for extracting different views. What I'm trying to say is that the 'many' part is necessarily a post-processing step, and doesn't really benefit from being integrated into Hugin. -- Bruno --~--~-~--~~~---~--~~ 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: Next GUI - take 2
I have been using hugin for about 3 years and follow the development with a lot of interest. It would be good if one were to be able to select and move individual and groups of images in the fast preview window. This would be useful in the case of sky images with no coherent set of control points. It may prove useful to implement something like skeleton deformation as it is used in animation to warp the images, perhaps a fine tuning the deformation to accommodate panoramas photographed without rotation about the correct axes. --~--~-~--~~~---~--~~ 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: Hugin-2009.4.0_rc1 source code released
do you get more information when running it with -v 1 ? I'm getting more information with -v 1. It mainly the steps processed and some statitistics. But it does not help to identify the parameters: /snip Levenberg-Marquardt returned in 45 iterations reason 2 - stopped by small Dp start ||e||_2 : 0.00279322 final ||e||_2 : 0.00123469 ||J^T e||_inf : 3.72358e-007 ||Dp||_2 : 8.32767e-041 mu/max[J^T...]: 2.25079e+014 iterations: 45 stop reason : 2 function evals: 51 Fitted parameters... Radial mean sq. dev. 0.0015 factors: 0. 0. 0. -0.0040 0. 0. 0. Line 1 rms: 0.000450873 Line 2 rms: 0.00029709 Line 3 rms: 0.000381106 Line 4 rms: 0.000715746 Line 5 rms: 0.000638243 Line 6 rms: 0.000317868 Line 7 rms: 0.000411951 Line 8 rms: 0.00020453 Line 9 rms: 0.000166703 Line 10 rms:0.000311561 Line 11 rms:0.00025 Line 12 rms:0.000841143 Line 13 rms:5.1749e-006 Line 14 rms:0.000188674 Some idea I had: Maybe calibrate_lens could write a file with the lens information file, so this file could read inside hugin with Load lens. Thomas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
