Re: [hugin-ptx] How to best shoot and stitch this?
Terry, Have you considered using a flash (or two) to lighten the south side panels? With a bright flash about 2 meters from the camera, you should get some good lighting. Just a thought. Roger On 3/3/2014 8:21 PM, Terry Duell wrote: Hello All, The attachment shows the Vietnam Veterans Commemorative Walk, in Seymour, Victoria. It is approx. 80-ish metres long, with about 52 glass panels on each side, each panel approx 2m high, 1.5m wide. The panels are etched with images from the war, and the names of all the Australian veterans. Shooting and stitching a pano of each side looks like a tricky project. The right side of the attached image is roughly north, so shooting the south side is always going to present a bit of a problem with the light, i.e. the sun is always to the north. On the north side the panels have much better light, but there is vegetation about 4 to 5m from the panels. Standing on the edge of the vegetation, a 24mm lens (36mm equiv) shooting approx normal to the panels gives about 2.5 panel wide coverage. Does anyone have any comments on whether a pano might be possible, and any ideas on how to tackle it? Cheers, -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/5315336C.7040701%40cox.net. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] hugin 2013.0 release notes: to be checked and translated
Harry, I would add a few commas, a hyphen, and a couple words, as shown below. (look for the arrows -) Roger Hugin-2013.0 RELEASE NOTES ABOUT .(several lines snipped) This is a source code release. For executables, see below. --- This tarball is equivalent to rev/changeset ## in our Mercurial repository, where it is also tagged 2013.0.0 Verify its SHA1SUM hugin-2013.0.0.tar.bz2 EXECUTABLES User communities produce executables for their respective platforms. These executables are then added to the download section on SourceForge at http://sourceforge.net/projects/hugin/files/hugin/ A number of users have built recent snapshots, and executables are likely to be --- announced within a few days of this tarball release. Watchhttp://groups.google.com/group/hugin-ptx for the announcements of binary releases. If you don't see a binary for your platform, it has most likely not -- been produced yet. Consider stepping up to the task. Instructions at http://wiki.panotools.org/Development_of_Open_Source_tools#Supported_Platforms Announce your build onhttp://groups.google.com/group/hugin-ptx CHANGES SINCE 2012.0.0 * The greatest change is the redesign of the (Graphical) User Interface (GUI). The user interface now consists of three modes: Simple, Advanced and Expert. The Simple interface is for the beginning panorama photographer, and offers all tools to - create your panorama. You can also use this mode if you have a simple, straightforward panorama. The Simple interface mode uses the Fast Preview window as its main workflow window. The Advanced interface mode offers you more options to improve your panorama. It uses the Panorama Editor as its main window. The Expert mode gives you access to all options and functions that Hugin has to offer. This is where you can optimize your complicated, multilayer, mosaic, multi-stack, you name it, panorama. It also uses the Panorama Editor as its main window. * The Hugin build for Mac OS X has switched from Carbon to Cocoa and is now fully 64bit. New tools added: * pto_var ( change image variables inside pto files) * pto_lensstack (modify assigned lenses and stack in pto files) * geocpset (set/add geometric constraints for multi-row panorama with featureless images) - Other Improvements * Many more improvements and bug fixes. UPGRADING Upgrading from previous versions of Hugin should be seamless. If you do have problems with old settings, these can be reset in the Preferences by clicking 'Load defaults'. It is strongly recommended to set the default control point detector to - Hugin's CPFind. This is the only control point generator endorsed by Hugin. - Third-party generators may be compatible with the plug-in architecture. COMPILING Users compiling from source should refer to the dependencies listed at - http://wiki.panotools.org/Development_of_Open_Source_tools#Dependencies and the build processes listed at http://wiki.panotools.org/Development_of_Open_Source_tools#Build_your_Own_Test_Builds More information is contained in the README and INSTALL_cmake files in the tarball. - KNOWN ISSUES AND WORKAROUNDS . (several lines snipped) On 7/3/2013 2:57 PM, Harry van der Wolf wrote: All, As already mentioned before in the 2013rc1 thread: I wrote the english release notes quite some time ago. 3 March to be exactly, but I stupidly forgot to post them with the beta1 at that time. You can find the release notes as hugin-2013.0.0.txt inside the tarballs and inside the 2013.0 branch, but I also attached it to this mail. Please first check whether the english is correct and whether the notes are complete with regard to things that should be mentioned. If we all agree I can update the notes in the 2013 branch and we can start to translate. best, Harry -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGARPpuQXC9z1uswRKTkJk7S8XZWFogi63%3Db_eahv-vdo8C%3D8w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/51D4D53E.2020909%40cox.net. For more options, visit
Re: [hugin-ptx] Re: (Not a Hugin topic, but related) — De-blurring images
Cartola (and all), I did try it, and it works fairly well, but leaves a lot of artifacts. I tried both the free version and the for-pay version; and found that the for-pay version is easier to use, and seemed a little cleaner (less artifacts), but still not good enough to convince me to part with my hard-earn $. Roger On 6/3/2013 10:00 AM, Cartola wrote: Hi, I have seen this SmartDeblur on portableapps.com http://portableapps.com/apps/graphics_pictures/smart-deblur-portable. From that page one can go to the official site and there we can find a link to the GPL sources of the previous versions. Unfortunately looks like it is available only for Windows, but the previous version is available for free. http://smartdeblur.net/ Didn't try it yet. Cheers. On Tuesday, May 7, 2013 10:04:46 AM UTC-3, Cartola wrote: Hi all, one more reference on the subject: http://intelligentimagingsolutions.com/index.php/en/ http://intelligentimagingsolutions.com/index.php/en/ Bests. On Friday, February 15, 2013 7:56:37 PM UTC-2, JohnPW wrote: I'd seen work on de-blurring where they used sensors to record camera movements to create a blur kernel for de-blurring, but had never seen this technique for deriving the de-blurring kernel directly from the photo. Has anyone here tried the executable linked here? (or similar?) http://www.cse.cuhk.edu.hk/~leojia/projects/motion_deblurring/index.html http://www.cse.cuhk.edu.hk/%7Eleojia/projects/motion_deblurring/index.html What's the state of the art these days? Any opinions about it? Is there any linux (OS X) compatible implementation out there? Just curious what you smarties know. john -- -- 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 --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [hugin-ptx] Hardware: Cost efficient cluster for stitching?
If your software supports batch processing, use Sun Grid Engine (available for Windows and Linux). For hardware, any P4 based set of systems, as long as they are all similar in capability (CPU type, memory available). Have one dual-homed system as your interface to the cluster, and as many cluster nodes as you can get, on a single LAN. Roger On 1/11/2012 8:13 PM, Jan Martin wrote: Hi all, I am looking for suggestions to build a cost-effective Linux cluster for stitching, blending and tiling. Data is 6 images of ca. 2.2 MB per pano. I have a real lot of them. Lots of relatively cheap comodity hardware should deliver best bang for the buck. Suggestions for hardware design please? Thanks, Jan -- 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 -- 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 plugin interface - developers please liaise
Kay, I have Windows XP, without Python installed, and would be willing to test what happens, but I would need a compiled Windows binary to get started. I don't have a compiler on my system, so I won't be building hugin from scratch. Roger On 3/20/2011 5:40 AM, kfj wrote: On 9 Mrz., 19:37, Bruno Postlebr...@postle.net wrote: On Tue 08-Mar-2011 at 01:41 -0800, kfj wrote: For me, the Python interface works, and I've hardly modified it in the last weeks even though I'm using it on a daily basis. I really would like to use it and see what I can do, but I'm aware that there are some deadlines approaching and that these have priority. I suspect that most 'development time' at the moment is working towards getting the 2011.0.0 release out. Well, Bruno, I suppose you're not the only one busier with something else. So, just to remind every one, nothing much is happening with the Python interface. Let me give you a brief status update on the current issues: - still nothing at all on Mac OS. Would a Mac programmer please come forward and help compile the Python module? - another issue that's been discussed but not solved is how Python plugins could be given GUI access. Using wxPython from plugins works on Linux with Python= 2.7 but not Python 3.X, and not at all on Windows, quite probably because wxWidgets is linked statically there. On the positive side, the Python scripting interface (hsi) seems to be running just fine on Linux and Windows. This means that Python programs can use pretty much all of hugin's backend functionality. I've writtten a very long involved Python program doing just that. It's great. And it can be called from hugin, it's only the GUI sharing that isn't yet happening. The GUI issue affects the hugin plugin interface (hpi). Nothing is wrong with the hugin scripting interface (hsi) apart from the missing Mac port. I wonder if it might not help progress on the Python front if binaries of the Python module were offered for download for Linux and Windows? I find the Python interface immensely useful, as it allows me to access most of hugin's functionality from Python. Being able to call Python plugins from hugin is a nice-to-have extra and mostly works, and GUI access from Python is another nice-to-have thing, but waiting for it to materialize before distributing the Python module seems silly. If interested parties could get easy access to the Python module, the body of hsi code might grow, at the same time uncovering issues that have not surfaced yet. On Linux, getting the module is reasonably straightforward, but requires compilation of a specific hugin branch. On Windows, this is probably more involved. Offering the binaries would lower the threshold. Is this feasible? Would it be necessary to offer a complete 'hugin with Python capability' bundle or would it be enough to merge the python_scripting branch into default and make BUILD_HSI = ON the default, so hugin and collateral software would be the same throughout - would the resulting binaries run on systems without Python? I've written hpi (the hugin plugin interface) so that embedded Python is only initialized if the interface is used. I'm not sure what happens on a system without Python, or with the wrong version, but when I wrote it I hoped that the code would simply produce an error if Python wasn't available, returning an error code. Has anyone tried? This would be easy on Windows, where Python is optional. The test would be to run hugin built from the python_scripting branch with Python uninstalled and see what happens when calling a plugin. If it merely says something like 'script return -X' this would mean it' safe. Maybe the presence of Python could be detected, and if it's missing the plugin call could be grayed out? I'd welcome your comments. Kay Kay -- 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 plugin interface - developers please liaise
Kay, I read all your posts, but can not help you, as I am not a programmer at all. From the outside, it looks like you are doing good work, and creating a useful interface. I say, keep up the good work! Thanks, Roger Goodman On 1/16/2011 12:32 PM, kfj wrote: Hi all! Continuing my work on interfacing hugin with Python, I have reached another of my goals: I have figured out how to use plugins written in Python from programs that use hugin's type corpus - or at least the subset that is wrapped in the hugin scripting interface. This means that there is now a possibility to call arbitrary Python code with objects like HuginBase::Panorama, do some processing on them in Python and return to the caller. Don't be fooled into thinking this is a mere 'execute a script file' approach: the interface maintains the object- oriented interface, but the Python code actually accesses and manipulates the binary data held in the C++ application. What I'd like to do now is link this code into hugin and test it at it's destined place. To do so, I need a good point to link it in, and some easy way of triggering the call to Python with data from hugin. The code to use Python is encapsulated in two C++ classes that could either be put straight into a cpp file somewhere or be included as a header. I'd welcome some support from the hugin developers here. Also, I don't intend to provide any GUI elements to deal with plugins (at least for now), mainly because I don't have wxWidgets experience and don't know the GUI code, but also because I feel that the GUI isn't really my domain, I'm more of a backend programmer. Never mind the GUI, having a breakout option to call Python for quick hacks or rapid prototyping might be a welcome facility for the developers even without any formal introduction of a plugin GUI. Since all the terminology for data types and methods is identical in Python to that in C++, switching to using Python on the data is easy. I also need information on what to do if the Python code has modified hugin's content. I am aware that there are mechanisms to notify the application of such changes, and I also know that a certain protocol has to be used to make sure all actions can be undone. What I don't know is the precise nature of these mechanisms and how to serve them with appropriate information. Again, help from the developers would be welcome. Once I've test-run the code from hugin I'll publish through the usual channel. So far there has been so little echo to my work that I am getting the feeling that hardly anyone actually reads my posts or is at all interested. This is regrettable, since I am certain that my path to Python integration is opening up very interesting new possibilities. Let me name but a few: - plugins can provide glue to closely cooperate with other applications - other code can be glued in without having to link it - code contribution from users is made much easier - optional functionality can be accessed on on demand - Python code can be used to do advanced maths (see numpy, SciPy) Kay -- 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] Product Vision
On 1/2/2011 9:37 AM, Yuval Levy wrote: On January 2, 2011 03:58:53 am Rogier Wolff wrote: On Sat, Jan 01, 2011 at 05:11:24PM -0500, Yuval Levy wrote: On December 30, 2010 10:38:36 am Rogier Wolff wrote: Disagree. That assistant tab assist is a nuisance to the power user and a deception to the occasional user - especially to that kind of occasional user who think of themselves as a power user and push all sorts of levers and buttons without understanding them. Maybe I'm just a power-user-wannabee, but I find the assistant useful. it's as useful as a thermostat: depend what you do with it. too many people just turn it up and down if they are cold or hot. When the assistant shows that the default stitch works, it's the user who did something wrong if his custom stitch doesn't work. Maybe it is a bit weak guiding by the GUI, but it is a start. it's actually *mis* guiding. I am not against having a good assistant. but the current assistant is nothing more than a blind run through the different tabs with no guidance but raising the expectation of guidance. the tune would be different if the assistant actually provided guidance, such as I have detected that you have too many CPs, would you like me to prune some? or I have detected that you are trying to optimize translation, position and lens distortion at the same time. May I suggest that you first calibrate your lens?. And as a follow-on to that question, how about Do you need help to calibrate your lens? Some of us less-technical users don't know how to do things of this nature. This should call another wizard (script), to walk the user through those steps, if (s)he decides to have the lens calibrated, IMHO. Roger -- 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: Windows 2009.2 installer package: please test
Yuval, In Linux (and UNIX), the which command will tell you the path to the executable. For example, which bash, without the quotes, should return something like /bin/bash. The returned string could be grabbed and stored in a variable, or used by Hugin. Of course, this probably isn't something that can be run from _within_ hugin. Can you shell out and run commands? Hope that helps. Roger Goodman Yuval Levy wrote: The optimal solution would be to check if the external binary exists, around line 502, using wxFileExists [0] If the preference has an absolute or relative path, it is relatively easy. But if it relies on the environment variable PATH (as it does in Linux) to tell where commands are stored, once would need to check in the PATH as well and I have not found a function that does this. --~--~-~--~~~---~--~~ 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: 2009.4.0 RC2 'clean control points' produces crook (bad) result
Yuval, If the 'clean control points' button _always_ causes problems if two (or more) lenses are selected, how about a small chunk of code that disables the button if two or more lenses are selected/entered? I'm not a coder, so I can't help with that, but it seems like it would be a simple change. Roger Goodman Yuval Levy wrote: Hi Terry, Tduell wrote: I did provide files showing the problem as I saw it I had to look for the files. It was not immediately obvious to me that they are in the GoogleGroup's files area. And when I opened them I saw what you saw, but I did not see what is needed to reproduce and understand the error. I really didn't know what info it was best to provide, and in those cases I try to report it as best I can and then respond to specific requests for files/data. When in doubt always post at least the PTO file. It's small and gives plenty of useful info. From my perspective there are a lot of things that need to be done on Hugin. More than anybody here has time to spare. When I engage in something Hugin, I have my list of priorities. To request extra information/files/data is usually very low on my priority list. Either it is something important to more than one users, and somebody at some point will provide them; or it is important enough for the only user concerned and he will provide them. For me it is extra work. I much rather get to the bug tracker, fetch a bug with all the required information and elements from there, and fix it. I am reluctant to post bug reports until I'm sure that it isn't really the result of the way I have done things or due to my system It's a tradeoff. I appreciate your consideration. On the other hand, if you want to be heard you need to come forward. [snip] even if it was, I would not call it a step backward but rather a step on the place. It would be a step backward if 'clean control points' was mandated. It is not. You can safely ignore the button and ont press it. To me it is helpful. I don't have cases at hand with different lenses. It may very well be that it is not helpful in cases where different lenses are used. But the button is there, and if the ordinary user selects it and the project goes haywire, I isn't very helpful. I disagree. An ordinary user can send the project haywire by pushing all sorts of buttons - e.g. by clicking randomly left and right on the CP tab (and creating wrong CPs). That's no reason to judge the button or to remove it. Turn it around: it isn't very helpful if a user hit a buttons without understanding the consequences; and it isn't very helpful to withhold a functionality from all users because of a few cases. I would think that it a definite backward step if an option that wasn't previously available causes a problem. *IF* the option was *always* causing a problem, I'd agree with you. This is not the case here. If the option is beneficial to some cases and detrimental to others (like it may be in this case where it is beneficial to single lens projects and detrimental to multiple lenses projects), we'd have to ponder. What is the relative importance of each use case? And what are the workarounds / alternatives? I dare to say that the vast majority of use cases are single lens project that do benefit from cpclean. And since cpclean is not hard coded in the workflow, it can be disabled for multiple lenses project with no consequences and with little effort (it's a preference, in case you use the assistant; and it's no extra effort at all in case you use the normal workflow). So I am pondering between: a material improvement for the vast majority of use cases and a minimum effort workaround to keep the current level of quality for the exceptional multi-lens case vs. no improvement for anybody. My decision here is clear: it can be released as-is with a release note stating that cpclean may be detrimental for a few use cases, notably multiple-lens projects. If the proportion of users and projects affected would be 10%, I would consider changing the default for cpclean after automatic alignment from ON to OFF. If the proportion of users and projects affected would be 50% I would start thinking about other things; but even then, just changing the default preferences would be enough IMO. At 75% I'd take the feature out from the release and wait for a bug fix. 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
