Re: [hugin-ptx] FORK HUGIN
On 21/11/11 14:14, mark skama wrote: who wanna build a new software for normal lenses? hugin is good program is open source and i love it but has a lot of errors during the creation of the panorama i think with a new approch and new focus only for the normal lenses it possibile create a good automatic panorama program; i find some common error with stitching softwares so if we start to build an intelligent software its possible find the solution for all panorama the program most be freeware but source closed write in c++ and wxwidgets the budget start from 100 € Hi Mark obviously, you're free to create a fork from the hugin sources (it's free software, that's the idea!), however AFAICS the usual reasons to fork don't really apply for hugin; it's maintained, it's openly developed and regularly new features are added and bugs are fixed. If you want to make a specific panorama tool with a completely different UI, I think there were already some attempts which you may find in the archives of this list. If you have a problem which is specific (I don't know what you mean by normal lenses, but it seems rather within the scope of hugin), you could try to report a bug or feature request. And, if you're willing and able to fork, perhaps you can try fixing the problem yourself, within hugin. (Forking a complete project is a big thing, perhaps it will take too much of your time to fix a specific issue?) Cheers Simon -- 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: FORK HUGIN
On 21/11/11 18:39, mark skama wrote: On 21 Nov, 14:14, mark skama melonefre...@libero.it wrote: who wanna build a new software for normal lenses? hugin is good program is open source and i love it but has a lot of errors during the creation of the panorama i think with a new approch and new focus only for the normal lenses it possibile create a good automatic panorama program; i find some common error with stitching softwares so if we start to build an intelligent software its possible find the solution for all panorama the program most be freeware but source closed write in c++ and wxwidgets the budget start from 100 € ok sorry to everybody and for opensource projects/licenses the program that i want to buil is freeware and not anymore a fork of hugin but a new onesorry Well, you'd have to build it from scratch if you want to make it closed source (I completely missed that the first time ;-) But, I guess you're just frustrated with some bad panorama attempts and somehow you think it's the program's fault? If all software, which is intended to do what you want (hugin can work with normal lenses quite well) doesn't work well for you, but most users of that software seem happy, there is a possibility that you may not be using it correctly to produce the correct results... Cheers Simon -- 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] Strange control point detection problem
On 26/08/11 02:16, Greg 'groggy' Lehey wrote: A couple of days ago I took some photos in the Ballarat Botanical Gardens and stitched them together. Most worked well, but in one case it went completely off the rails. I wasn't able to align the images even with a manual choice of control points. There was nothing obvious wrong with the images themselves, and I was later able to create a good panorama by starting with only two images and adding them one at a time. I get the feeling that this is some kind of bug in hugin, but I'd appreciate other opinions. There's a writeup, including full description and images, at http://www.lemis.com/grog/diary-aug2011.php#stitch-failure Details: Hugin Pre-relase 2011.3.0 Panomatic FreeBSD 8.2 I'll try some other combinations (in particular the control point detector), and if I have any enlightenment I'll report back. Hi Greg, I did a quick check and I get perfect results without any manual work with my version of hugin on kubuntu 11.04 (with kde 4.7) hugin says it's version: Operating System: Linux 2.6.38-11-generic x86_64 Architecture: 64 bit Free memory: 2510756 kiB Hugin Version: 2011.0.0.0f9fdaf56720 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Cheers Simon -- 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: how many man-years to reboot Hugin?
Hi All As a sideline spectator, I've been half-reading this thread, but I still have a few ideas that may be rubbish, or perhaps ground some of you, while you can have a snort about my ignorance ;-) As I understand hugin, quite a few scripting interfaces have already been created around the pano libraries and the fusing/blending engine. I was actually under the impression that what I see of hugin is mostly user interface code and glue, while the real work is done in the commandline code and libs. (I deduce this from having the make file system to do the stitching.) So the gui gathers the images, feeds them to cpfind, provides some interaction for the user to fix the robotic output and then to set some parameters for the final stitch. Some of the interface is plain and some is really fancy with the GL preview. In the end, all is put into a makefile and/or PTO file (I think) and the gui is done, onto batch-a-stitch (or whatever). So, writing a different gui in a different language is probably quite a bit of work, but by no means a rewrite of hugin. I like the idea of using a scripting language for the gui, because of the reasons Yuval gave (no need to re-iterate). Python seems quite a good choice, and there are even alternative (perhaps faster) interpreters in e.g. pypy Tnx for reading (if you got this far) Cheers Simon -- 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] Design Question
On 24/06/11 01:21, Bruno Postle wrote: snip The development branch Mask tab will show the area excluded by the overall crop, plus it shows the areas in one photo that have been excluded by masks in other photos. thanks for the informative answer, It's great to know the next version will be even more quick to use :-) Cheers /Simon -- 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: hugin plugins - paradigm shift needed
On 23/06/11 09:57, kfj wrote: On 23 Jun., 05:09, Yuval Levy goo...@levy.ch wrote: exactly. check the 2007 GSoC project to see where this ends: wxWidget has improved enough to make us forget that we wanted to move to Qt. I'm glad you didn't. I have a funny feeling with Qt. They might decide suddenly they aren't licensing this or the other component to the free world anymore or putting restrictions on what Qt-based code can be used for. I feel much more comfortable with wxWidgets, never mind it's probably not (yet) as evolved and polished. It's a shame that the old reason that spawned GNOME (Qt wasn't Free at that time) is still causing FUD (no doubt unintentional FUD) like this. Qt is currently completely free software to the point that RMS endorses it (article from sept. 2000, a still somewhat sceptical RMS: http://www.linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE). The KDE community has been constantly working to ensure that the basis of their software is and will remain free software ever since. I'm not familiar with the quality of wxWidgets, but it wasn't that long ago that it was the cause of hugin's less than modern looks. I agree that this has improved to the point of being moot, but with Qt, I think it could have happened sooner and better (regarding portability). Also note that Qt has had Python binding for a long time, as well as bindings to other scripting languages. Anyway, regardless of which toolkit is used for the UI, I think hugin's last release, which I used to stitch together some recent handheld wider angle holiday snapshots, is really great, so I'm not complaining! please keep on making hugin better, I think Qt would be a better toolkit for the GUI, but since I'm not in a position to prove it, do it the way you prefer! Cheers Simon -- 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] No Control Points?
On 18/04/11 08:02, Calvin McDonald wrote: I need someone experienced to check my expectations. If I ... ) Carefully and robustly (as per these instructions http://hugin.sourceforge.net/tutorials/calibration/en.shtml) obtain distortion parameters a, b and c for my lens. ) Provide these distortion parameters to Hugin (Load Lens). ) Set my camera/lens/head to the exact nodal point calibration. ) Use a high precision pano head with very accurate detents both vertically and horizontally (w/ proper overlap). ) Apply image yaw/pitch/roll consistent with above and load into Hugin as a template. Can I expect to get successful stitches from Hugin without any control points? In the most optimal case, you need at least 3 control points with a neighbour on each image you want to include in the stitched result. And you should be able to travel from each image to every other image using control points as bridges. Cheers Simon -- 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] No Control Points?
On 18/04/11 12:59, Christopher Allen wrote: On 18 April 2011 11:11, Simon Oosthoek soml...@xs4all.nl wrote: On 18/04/11 08:02, Calvin McDonald wrote: If I ... [ Do everything perfectly ] Can I expect to get successful stitches from Hugin without any control points? In the most optimal case, you need at least 3 control points with a neighbour on each image you want to include in the stitched result. And you should be able to travel from each image to every other image using control points as bridges. This is false. Hugin stitches without reference to control points. (Try it some time: remove all the control points, then re-stitch. Works great.) The control points are only used to adjust the position (+ size + distortion + exposure etc.) of the images, and the the optimal case (absolutely correct parameters entered manually) perfect results can (in principle) be achieved without any control points. Wow, thanks for correcting me! I learn something new everyday. But it seems like a lot of work to enter everything manually, compared to having the control points being generated automatically. What would be the advantage of not having control points (given a set of images that, in theory, doesn't need them)? Cheers Simon -- 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] hugin-2010.2.0_rc2 released
On 02/10/10 00:21, Bruno Postle wrote: On Thu 30-Sep-2010 at 12:09 +0200, Simon Oosthoek wrote: I also have a question: what is the default optimisation that hugin does when you first load images, generate CPs and then presto it presents the first preview. I was unable to improve on that (apart from adding a mask), so I'm wondering what it is that makes this a good optimisation? A lot of this could be made into user preferences, not because users should be continually tinkering with these settings, but there is no other way I can think of of determining a good set of defaults. Ok, the defaults seem to work rather well for me, but I suppose they can be tuned even further... AFAIK there's no way for me to choose this optimisation from the GUI in this release, is there? Cheers Simon -- 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] hugin-2010.2.0_rc2 released
On 29/09/10 00:37, Bruno Postle wrote: Hugin is a Panorama stitcher and more. A powerful software package for creating and processing panoramic images. A hugin-2010.2.0_rc2 (release candidate 2) tarball is available here: https://sourceforge.net/projects/hugin/files/hugin-2010.2_beta/ This is a release candidate, i.e. The final release may be identical. More information about this release can be found in the full ChangeLog below and the final release notes: http://hugin.sourceforge.net/releases/2010.2.0/ I just tried it, it seems to work really well for me (kubuntu 10.04.1), the only things I noticed were: - I had an older enblend (compiled with older library), failing to run it hung the stitch-now window completely (that's ugly from a user's perspective) - the GLpreview window's photometrics looks a lot darker than in the final output. That should be more calibrated IMO. I also have a question: what is the default optimisation that hugin does when you first load images, generate CPs and then presto it presents the first preview. I was unable to improve on that (apart from adding a mask), so I'm wondering what it is that makes this a good optimisation? Anyway, good work! Cheers Simon -- 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: Manually rotate a picture
Bob Campbell wrote: On Apr 13, 3:23 pm, Martin Lukeš martin.merid...@gmail.com wrote: And if I want to keep already marked points, but since those two pictures in Control Points tab are rotated differently to each other (say 90 degrees), I want MANUALLY rotate one of those pictures. I've seen this as well (more with autopano-sift-c, iirc). What I've noticed is that two completely unrelated images will have a common control point. Running Celeste manually has helped with this, and also going through the control points tab and looking for images that are not neighbors but have a single control point anyway. Deleting such control points and rerunning the optimization almost always works. So I don't think what we'd want is a way to manually force the rotation of the images, but rather a smarter weeding out of erroneous control points. So maybe a final pass in the CP generators that weeds out control point matches for two images under a minimum (configurable) threshold (like, 1-5?). It would be nice to have a threshold value above which the CPs are not used, but they should remain defined, because they may actually be correct. /Simon -- 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 To unsubscribe, reply using remove me as the subject.
Re: [hugin-ptx] Re: Repository
Hi Yuv Yuval Levy wrote: I think it should be the other way around. The choice of DVCS is more critical than the choice of code hosting provider; and it is also more critical than the choice of bug tracker and other tools which can also be hosted at different providers. Hosting is an interchangeable commodity. That said, the devil lies in the detail and I don't think we have the capacity at this time to acquaint ourself in detail with other code hosting than SourceForge. Hence my proposal is to implement Hg on SF. Of course everybody is free to implement another DVCS at any other hosting provider any time, to publish their results here, and to see that everybody else learn to use that alternate hosting provider. I suppose you have a point, at least do one thing at a time, also below I have some comments which may indicate that once the conversion is done to a DVCS, switching to another system can be much easier if that turns out to be necessary. Also, regarding the tracker, that may cause a bit of lock-in to sf.net for now ;-) And the DVCS should be acceptable to use on all platforms that hugin developers use. Yes, which is one of the main reason to choose Hg. Windows support for Hg is still not perfect, but last time I checked it was more mature than Bzr or Git. I think this may not be much of an issue if these DVCSes can easily interoperate, see below. Thanks also for all the links about repository conversion. The more I think of it, the more I feel that it is better to leave the past enshrined in SVN (read-only) and move on to a better future. I see no reasonable use case to make the effort and add the whole luggage of historic commits to a Hg repository. But maybe somebody has a case to justify the effort? Since Pablo had some success converting subversion history to mercurial, I agree with him that it would be worthwhile to retain at least some (recent) history. But perhaps more is not too hard and with some specific dropping of parts of the history not even very large. I'm keeping my eye open for similar conversions, of which there are many! KDE is one huge project which has had quite a bit of experience with conversion from subversion to git, so there may be some way to harness that experience... http://blog.hartwork.org/?p=763 http://gitorious.org/svn2git/svn2git Also conversion/cooperation between mercurial and git is easy to do and lossless, so using tools made for git (I think this may be more mature than for mercurial, but I'm not in a position to judge that) can be used as intermediary step towards a mercurial repository and if people would prefer git for their personal repository, that's possible even if others use mercurial. http://mercurial.selenic.com/wiki/HgGit If I can find some time for this, I will see what I can come up with, but it may take a while for me to find time ;-) /Simon PS, sorry if you get this twice, I didn't see this arrive on the list, so I'm sending again... -- 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 To unsubscribe, reply using remove me as the subject.
Re: [hugin-ptx] Re: Repository
Hi Yuv Yuval Levy wrote: I think it should be the other way around. The choice of DVCS is more critical than the choice of code hosting provider; and it is also more critical than the choice of bug tracker and other tools which can also be hosted at different providers. Hosting is an interchangeable commodity. That said, the devil lies in the detail and I don't think we have the capacity at this time to acquaint ourself in detail with other code hosting than SourceForge. Hence my proposal is to implement Hg on SF. Of course everybody is free to implement another DVCS at any other hosting provider any time, to publish their results here, and to see that everybody else learn to use that alternate hosting provider. I suppose you have a point, at least do one thing at a time, also below I have some comments which may indicate that once the conversion is done to a DVCS, switching to another system can be much easier if that turns out to be necessary. Also, regarding the tracker, that may cause a bit of lock-in to sf.net for now ;-) And the DVCS should be acceptable to use on all platforms that hugin developers use. Yes, which is one of the main reason to choose Hg. Windows support for Hg is still not perfect, but last time I checked it was more mature than Bzr or Git. I think this may not be much of an issue if these DVCSes can easily interoperate, see below. Thanks also for all the links about repository conversion. The more I think of it, the more I feel that it is better to leave the past enshrined in SVN (read-only) and move on to a better future. I see no reasonable use case to make the effort and add the whole luggage of historic commits to a Hg repository. But maybe somebody has a case to justify the effort? Since Pablo had some success converting subversion history to mercurial, I agree with him that it would be worthwhile to retain at least some (recent) history. But perhaps more is not too hard and with some specific dropping of parts of the history not even very large. I'm keeping my eye open for similar conversions, of which there are many! KDE is one huge project which has had quite a bit of experience with conversion from subversion to git, so there may be some way to harness that experience... http://blog.hartwork.org/?p=763 http://gitorious.org/svn2git/svn2git Also conversion/cooperation between mercurial and git is easy to do and lossless, so using tools made for git (I think this may be more mature than for mercurial, but I'm not in a position to judge that) can be used as intermediary step towards a mercurial repository and if people would prefer git for their personal repository, that's possible even if others use mercurial. http://mercurial.selenic.com/wiki/HgGit If I can find some time for this, I will see what I can come up with, but it may take a while for me to find time ;-) /Simon -- 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 To unsubscribe, reply using remove me as the subject.
Re: [hugin-ptx] Re: Repository
Yuval Levy wrote: most of the CVS history seems to be available in SVN, while in the migration from SVN to Hg so far I have three options: a) hugin/trunk only, with all revisions from about 24.. (when Ippei's GSoC 2007 branch became officially trunk): 162 MB b) hugin the whole story, that includes autopano-sift-c, panoglview, kimagefuser, etc.: 5.2 GB c) import trunk without history (top-skimming) and start from scratch: 1.1MB I suspect that hgsvn does not deal well with branches. Probably digging a bit further things could be improved, but what for? Given the choice I am inclined to leave pre-Hg history in SVN (properly set to read-only) and start from a clean import of trunk. What do others think? On the one hand I think that the project is moving mostly at the tips (or HEADs in git-speak) so top-skimming may not be that bad. However from a historical perspective it might be good to have everything in one repository. Is a mercurial repository of the whole story really 5.2GiB? Or is that the entire storage for subversion's repo? If top-skimming is chosen, at least all the branches that are under maintenance should be pulled from svn. /Simon -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [hugin-ptx] Re: Repository
Yili Zhao wrote: Pablo wrote: Another question is about the quality of service of the hg repos at sf net. I haven't tried them yet, but in the past, I was not really satisfied with the sf.net service. The most popular distributed version control systems (DVCS) are Git, Bazaar and Mercurial. If the quality of service of the hg repos at sf.net is not good, maybe we can consider to migrate to other open source hosting sites. Pablo has used Ubuntu's LaunchPad for the panomatic development, and LaunchPad uses Bazaar as the version control system. Another candicate is Google's code site (http://code.google.com), and it use Subversion and Mercurial as the version control system. If we want to use git, then we can choose Gitorious (http://gitorious.org) or GitHub (http://github.com) I think the choice of DVCS should be dependant on which open source repository provider is most suitable. An important part of a move would involve moving all the issues from the tracker to a new service provider, this is at least as important as the source code, I think. And the DVCS should be acceptable to use on all platforms that hugin developers use. /Simon -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [hugin-ptx] Repository
Yuval Levy wrote: Hi all. Thank you for the feedback. *Keep it coming*. I want to hear more opinions about Hg. In the meantime, a few notes, trying not to advocate the change, just addressing points raised and acknowledging that more discussion and experimentation are needed on both sides of the argument. Hi Yuv I have more experience with git, but hg is probably just as good, perhaps easier to use if I understand correctly. I think it will be great for hugin to use a distributed versioning system, centralised systems are much less suitable for open source projects I think. (And if you want centralised, it can be done using git/Hg as well). for git you can read a pretty good book online http://progit.org One thing that git can do much cheaper than subversion is to make branches. This does affect the workflow of the project and this is something you need to define before getting too deep into it. In the progit.org book (you can buy it on dead trees as well), a chapter is dedicated to the workflow possibilities, this is a good read to get started (doesn't matter if you choose Hg or git) Cheers Simon -- 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 To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [hugin-ptx] Re: GLpreview and projections
Rogier Wolff wrote: On Thu, Mar 11, 2010 at 09:20:47AM -0800, Bart van Andel wrote: Well, a rectangular projection can only display images with 180 degrees field of view (and 120 degrees for practical use), so for this projection, the FOV field needs to be modified. How about: Internally, the FOV is still set at say 300 degrees, however if you switch to rectangular, the FOV switches to 170 degrees. This value is displayed, but internally hugin holds on to that 300 degrees. When you continue switching, the fov is taken from the hidden value, and not from the displayed one. People expect the switching of projections to be nondestructive. So they want to be able to try all of them (and see their restrictions) without having to fiddle with anything else. How about: 1st time switch to a projection: assume nothing but the input images and the control points, store resulting FoV for this projection 2nd time you switch to a projections: use stored value for this projection, unless something changed in input images or control points. (then goto 1st, perhaps after asking the user, if he/she changed any values manually) I don't think the FoV calculation should take that long, so it shouldn't impact performance too much. /Simon -- 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] GLpreview and projections
Bruno Postle wrote: On Wed 10-Mar-2010 at 12:50 +0100, Simon Oosthoek wrote: When I changed the projection, some projections altered the FoV in such a way that the output got totally distorted. Switching back to something sensible didn't always reset the FoV to sensible values. Wouldn't it make sense to review these functions and prevent unsensible values to be set, unless confirmed by the user? There have been a few changes recently to make this better, but probably Hugin does the wrong thing in a number of situations. There are hundreds of combinations of projections, a bug report where people could add examples that don't work well would be useful. When I have some time, I'll see what I can do, (@anyone) feel free to start an issue on this, I may not have time soon... Meanwhile, wouldn't it be a good idea to put a prominent UNDO feature on the windows/tabs that allow you to change aspects that have effect on the FoV? cheers Simon -- 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] GLpreview and projections
Simon Oosthoek wrote: Bruno Postle wrote: On Wed 10-Mar-2010 at 12:50 +0100, Simon Oosthoek wrote: When I changed the projection, some projections altered the FoV in such a way that the output got totally distorted. Switching back to something sensible didn't always reset the FoV to sensible values. Wouldn't it make sense to review these functions and prevent unsensible values to be set, unless confirmed by the user? There have been a few changes recently to make this better, but probably Hugin does the wrong thing in a number of situations. There are hundreds of combinations of projections, a bug report where people could add examples that don't work well would be useful. When I have some time, I'll see what I can do, (@anyone) feel free to start an issue on this, I may not have time soon... I managed to do it now anyway ;-) https://sourceforge.net/tracker/?func=detailaid=2968662group_id=77506atid=550441 Meanwhile, wouldn't it be a good idea to put a prominent UNDO feature on the windows/tabs that allow you to change aspects that have effect on the FoV? the more I think about it, the more I think this is really a bug and UNDO is not the right way to fix it. The projections shouldn't fundamentally change properties like FoV, unless I don't understand something (I'm not into the mathematics of making panorama projections!) /Simon -- 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] GLpreview and projections
Bruno Postle wrote: On 11 March 2010 15:45, Simon Oosthoek soml...@xs4all.nl wrote: the more I think about it, the more I think this is really a bug and UNDO is not the right way to fix it. The projections shouldn't fundamentally change properties like FoV Some projections have limits on field of view, switching from a 360deg equirectangular to rectilinear has to reduce the field of view to less than 180deg, if you then immediately switch back then you end up with a 179deg equirectangular. The General Pannini projection has a variable maximum angle of view, so playing with pannini settings can (sometimes) result in the angle of view reducing. I suppose that from a mathematical perspective, you're correct and what is happening isn't a bug, but from a user's perspective the behaviour is seriously broken ;-) Is it possible to change the behaviour so that from a user's visual perspective the projections are still recognisable, but correct in terms of the projection chosen? Some projections may not work (well) with some sets of images (e.g. not 360x180), but whenever switching projections, the new projection should not set values for FOV that are visually not possible with the current image-set. Of course, I now understand, this is not the same problem as the fit/center/straighten options, because they really shouldn't have effect on the FoV so that the image becomes totally distorted. (or is this also explainable from the mathematical back-end?) Cheers Simon -- 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: segmentation fault in svn r3846 Re: [hugin-ptx] hugin-0.8.0_rc1 released
Bruno Postle wrote:
On Mon 11-May-2009 at 20:37 +0200, Simon Oosthoek wrote:
I've not had much time to keep up with the developments, but I
consistently get a segmentation fault when I try to load images into the
assistent panel. I'm running 64bit kubuntu intrepid 8.10.
This is quite possible as there has been a lot of bugfixing lately.
Can you identify which stage of the process is failing? i.e. Load
Images or Align. If it is when opening files then we need to have
one of these photos to try and reproduce the problem.
After I select a range of images in the file dialogue, hugin crashes
upun loading the first image. (See strace -f output below)
BTW, I installed hugin svn from the ubuntu instructions of the wiki on a
quite unspoiled ubuntu 8.04 LTS virtual machine (32bit) and there I
didn't have this problem at all.
If necessary I'll provide the images, but I don't think they're special,
as I've used them before in hugin (they're from 2004 I think, so they've
been through several versions of hugin ;-)
anyway, strace output
[pid 24423] select(6, [5], [5], NULL, NULL) = 1 (out [5])
[pid 24423] writev(5,
[{\2\2\0\227\5\200\3\235\4\5\0\230\5\200\3\226\5\200\3v..., 92},
{H\2\6\4\232\5\200\3\233\5\200\3 \0 \0\0\0\0\0\0 \200\3..., 4120}], 2)
= 4212
[pid 24423] select(6, [5], [5], NULL, NULL) = 1 (out [5])
[pid 24423] writev(5,
[{\2\2\0\233\5\200\3\235\4\5\0\234\5\200\3\232\5\200\3v..., 1004}],
1) = 1004
[pid 24423] select(6, [5], [], NULL, NULL) = 1 (in [5])
[pid 24423] read(5,
\1\1\205O\0\0\0\0\343\2\200\3\0\0\0\0P\350\266\5\0\0\0..., 4096) = 32
[pid 24423] read(5, 0x1cdeaf4, 4096)= -1 EAGAIN (Resource
temporarily unavailable)
[pid 24423]
open(/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG,
O_RDONLY) = 14
[pid 24423] read(14,
\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1..., 8191) = 8191
[pid 24423] close(14) = 0
[pid 24423]
open(/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG,
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1..., 4096) = 4096
[pid 24423] read(14,
\271m\3624\364-\363RiZ\325\300\332\244H\245\302\3\317..., 4096) = 4096
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open(/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG,
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1..., 4096) = 4096
[pid 24423] lseek(14, -4094, SEEK_CUR) = 2
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open(/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG,
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1..., 4096) = 4096
[pid 24423] lseek(14, -4094, SEEK_CUR) = 2
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open(/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG,
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1..., 4096) = 4096
[pid 24423] lseek(14, -4056, SEEK_CUR) = 40
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] read(14, \377\330\377\341\31\376Exif\0\0, 12) = 12
[pid 24423] read(14,
II*\0\10\0\0\0\t\0\17\1\2\0\6\0\0\0z\0\0\0\20\1\2\0\24..., 4096) = 4096
[pid 24423] read(14,
\300\332\244H\245\302\3\317\334\367\317\245t\376\r\267..., 4096) = 4096
[pid 24423] lseek(14, 8204, SEEK_SET) = 8204
[pid 24423] lseek(14, 8204, SEEK_SET) = 8204
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 24435] +++ killed by SIGSEGV +++
Process 24435 detached
Process 24423 detached
---
Cheers
Simon
--~--~-~--~~~---~--~~
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
