[hugin-ptx] Re: how I shot myself in the foot with panoramas from stacks
On Tuesday, June 25, 2013 3:31:09 PM UTC-5, kfj wrote: Hi group! Back from a few weeks of trekking in Italy I am processing the accumulated imagery. Anticipating need for HDR-able material (for a project of mine I've not published yet) I had taken most of the individual images for my panoramas as AEB brackets. But my own new project was nowhere near ready, so for now I was stuck with what I had, good old hugin. I set to work using a plugin to create the stacks of three images I usually take, using a Canon EOS450D. I tried to get the plugin to be distributed with hugin some time ago, but it wasn't compliant with the API and was therefore rejected - but it worked for me, so I kept it to myself and used it, nevermind it was doing what it was doing in a way which was somehow forbidden. All was well, and I managed to create a few halfway decent panoramas, but I ran into problems with the readymade package I was using: it had the hardcoded default of considering everything a stack which overlaps 70% or more (outputStacksMinOverlap) - the mechanism which is used to assemble the images for exposure fusion, instead of using the stacks which are defined in hugin (to use a two-step CPG on). I had previously modifies this value in my personal version of hugin, but with an OS update my edits had disappeared into digital nirvana. So I traced down the responsible bit in the sources again (the default value is in .../hugin.hg/src/hugin_base/panodata/PanoramaOptions.h), changed it from .7 to .85 (this works for me), and recompiled... ... ... Finally it was done and by that time I had also figured out that an extant panorama carries the threshold value in the pto file, where it will remain unimpressed by a change of the default (which makes sense) but short of changing the pto with a text editor I found no way to change it (which doesn't make sense). So anyway, the value is towards the end of the pto and looks something like this: #hugin_outputStacksMinOverlap 0.85 All on needs to do is change the value and restart hugin with the modified pto. Whichever way, I now had the overlap issue sorted, and the stacks hugin sent to enfuse for fusing were the same as the stacks I had defined using my plugin, nevermind they were made up by a different mechanism... I still feel there should be an option to use the stacks defined in the pto instead of the outputStacksMinOverlap mechanism - maybe there is one but I haven't found it. Now hugin (at least in a reasonably recent incarnation) has a nifty feature: one can select a bunch of images (not in the openGL preview - that selection is a different selection) but in the images tab in the main window - probably only in expert mode, I don't know the other ones - and then rightclick, go via stacks and enter a stack size. I entered three and lo and behold, there were now the stacks of three images, like what my plugin made. I thought, oh great, here I can even enter the number of images per stack (I had refrained from using a python-wx dialog in my plugin to inquire for the number of images per stack and instead hardcoded the value in the prototype, and then, when it was rejected, left it like that since I hardly ever use anything else) - so I decided to forget about my plugin and use the nice stacking feature instead. The next few panoramas were very frustrating. No matter what number of control points I had, where I placed or deleted them, I just couldn't get them right - the images would never quite fit, but instead be a few pixels off here and there. I though I'd just not worked properly - it was all freehand on top of a Leki stick, as I usually do, but I hadn't done any in the winter so I thought my skill had just atrophied for lack of exercise... I slept over it. I looked at the faulty panoramas again. Finally I had the good idea to look at the image positions. And there I saw that I had shot myself in the foot: by abandoning my plugin for hugin's more convenient stacking feature I had created different stacks: the stacks I now had were position-linked, and I had plain forgotten that this happens when assigning stacks with hugin, while my plugin creates stacks which are not position-linked! Somewhere in the old interface there was a way to position-unlink stacks. Of course noone would guess that stacks which are deliberately fed to the CPG to create CPs to position the images properly would be position-linked by default... maybe I should have read the manual... but there once was a way to unlink the positions in the GUI, I'm quite sure. Try as I might, though, I just couldn't find it now. Is it still there? I's quite possible to do it by manipulating the pto, again, but that's fiddly. Nevermind that, I found a simple way of working around the issue: Since the stacks, produced by my plugin or by hugin's stacking feature, are totally irrelevant
Re: [hugin-ptx] Why is the Hugin manual being rewritten . . .
It's great that it's running well on Linux. but I'm not a Linux user and don't plan to use Linux. The last thing I plan to do is run Linux on my Mac. Just because it's possible to do that does not mean it's desirable. It's great there is work being done on improving the interface, but from what I can see, the new interface is not an improvement. But since there is no plan to see, I guess it's hard to say for sure. In any case these two issues (1. doesn't run, and no articulated plan) tell me that this version has been prematurely made the default branch, (if I understand the term correctly.) Quite simply, a climbing expedition should not be mounted until the peak that is to be climbed has been identified. Otherwise it's an exploration, not an expedition. On Sunday, April 14, 2013 9:03:18 PM UTC-5, Tduell wrote: Hello John, On Mon, 15 Apr 2013 09:21:57 +1000, JohnPW johnpw...@gmail.comjavascript: wrote: Why is the Hugin Manual http://wiki.panotools.org/Hugin being replaced with one for the new GUI in the 2013 version of hugin when: 1.) As far as I can tell, Hugin2013 is a *beta* version, 2.) it presently doesn't work (at least not on my computer) and, 3.) not wanting to offend, but frankly it looks like a troubled interface in many ways? This version is the default branch in the source repository, and hence will be the next release. The release cycle has already started. There may be problems with it on your system, and that is why we go through a release cycle. It does seem to be pretty stable on Linux. Wouldn't it make more sense to preserve a functional manual for each version in it's mature state so that people can get good documentation for working versions of Hugin? This question was raised in this discussion ... https://groups.google.com/forum/?fromgroups=#!searchin/hugin-ptx/wiki/hugin-ptx/rWHYkF-6i6g/5UTySJjC9M8J if that is any help. As far as the 2013 version, Apparently there is enthusiasm for it, and that's great, but as little as I have seen of it (since it doesn't seem to work on the Mac platform,) I find the concept and usability of the new GUI (in all of it's user modes) rather questionable (so far as I can parse it.) I'm sorry if I'm off base or ill informed. All I can go by is what I have seen and tried of the software on my machine. Perhaps it's fabulous on other platforms, but it doesn't run on my Mac One approach you might be able to use, in order to test this new version, is to install Virtualbox on your Mac, install a version of Linux in VirtualBox (preferably one for which there is a pre-built binary of Hugin-2013), and then istall Hugin-2013. That may be a lot of work, but would give you access to a working version now. Had I seen any discussion about the GUI, I'd have gladly given feedback on it along the way, but I've never really seen any plan for it or discussion about it (I'm assuming it's a bit of a skunk works operation?) I'd be interested in seeing where the 2013 version of the GUI is going, if someone could communicate it. I don't think there was a 'plan', so to speak, but there has been quite a bit of discussion about the need for improvements to the GUI, and then quite a bit following Thomas's work on the new GUI. I think all that was over quite a period, but I haven't tracked down all the various threads in hugin-ptx. In any case, until it's finished and running well and on all platforms, shouldn't the documentation for the version that presently works on all platforms be preserved? Indeed, shouldn't the documentation for each mature version be preserved so people can use it? (I can't see moving to Hugin2013 anytime soon.) I think it is at a suitable stage for release, and hopefully any outstanding problems will be resolved soon. Just my two bobs worth, and hope it helps. Cheers, -- Regards, Terry Duell -- -- 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] Why is the Hugin manual being rewritten . . .
Harry, If you point me to a compiled binary you recommend for OS X 10.8.3 I will give you exhaustive feedback. John On Monday, April 15, 2013 1:54:40 AM UTC-5, Harry van der Wolf wrote: Hi John, I have been using the new Gui on my old mac for more then a year. Apart from a few glitches it has worked for me very well. So please share what doesn't work. W.r.t. the troubled inteface: It has changed completely and sometimes programs do (Office on windows going from 2003 to 2007/2010/2011), and it might not always be an improvement, but that's also personal taste and experience to the older program. I use myself for 80% the simple interface and I really think (my personal view) that it is a big improvement. Harry 2013/4/15 JohnPW johnpw...@gmail.com javascript: Why is the Hugin Manual http://wiki.panotools.org/Hugin being replaced with one for the new GUI in the 2013 version of hugin when: 1.) As far as I can tell, Hugin2013 is a *beta* version, 2.) it presently doesn't work (at least not on my computer) and, 3.) not wanting to offend, but frankly it looks like a troubled interface in many ways? Wouldn't it make more sense to preserve a functional manual for each version in it's mature state so that people can get good documentation for working versions of Hugin? As far as the 2013 version, Apparently there is enthusiasm for it, and that's great, but as little as I have seen of it (since it doesn't seem to work on the Mac platform,) I find the concept and usability of the new GUI (in all of it's user modes) rather questionable (so far as I can parse it.) I'm sorry if I'm off base or ill informed. All I can go by is what I have seen and tried of the software on my machine. Perhaps it's fabulous on other platforms, but it doesn't run on my Mac and from what I can see, the HCI approach seems confused in terms of usability, clarity, and the model of operation. Had I seen any discussion about the GUI, I'd have gladly given feedback on it along the way, but I've never really seen any plan for it or discussion about it (I'm assuming it's a bit of a skunk works operation?) I'd be interested in seeing where the 2013 version of the GUI is going, if someone could communicate it. In any case, until it's finished and running well and on all platforms, shouldn't the documentation for the version that presently works on all platforms be preserved? Indeed, shouldn't the documentation for each mature version be preserved so people can use it? (I can't see moving to Hugin2013 anytime soon.) 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 hugi...@googlegroups.comjavascript: To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com javascript: 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+...@googlegroups.com javascript:. 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.
[hugin-ptx] Re: Why is the Hugin manual being rewritten . . .
Thanks. I'll take a look. On Monday, April 15, 2013 2:26:14 AM UTC-5, Erik Krause wrote: Am 15.04.2013 01:21, schrieb JohnPW: Why is the Hugin Manualhttp://wiki.panotools.org/Hugin being replaced with one for the new GUI in the 2013 version of hugin when: The wiki doesn't forget. You can view any older revision following the View history link. I suggest to insert a link pointing to the last relevant revision. -- Erik Krause http://www.erik-krause.de -- -- 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] Why is the Hugin manual being rewritten . . .
By the way Terry, I don't mean to sound whiny. I appreciate everyone's work, work which I am incapable of doing. My concern is that the approach may be counterproductive for many current users. In my experience, it is much more effective to create and share plans for software changes before making changes. It gives people something to discuss. Having discussions without written plans or mockups leads to a rather more vague goal and result. I apologize if this sort of interaction occurred and I missed it. John On Wednesday, April 17, 2013 3:14:45 PM UTC-5, JohnPW wrote: It's great that it's running well on Linux. but I'm not a Linux user and don't plan to use Linux. The last thing I plan to do is run Linux on my Mac. Just because it's possible to do that does not mean it's desirable. It's great there is work being done on improving the interface, but from what I can see, the new interface is not an improvement. But since there is no plan to see, I guess it's hard to say for sure. In any case these two issues (1. doesn't run, and no articulated plan) tell me that this version has been prematurely made the default branch, (if I understand the term correctly.) Quite simply, a climbing expedition should not be mounted until the peak that is to be climbed has been identified. Otherwise it's an exploration, not an expedition. -- -- 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] Re: Why is the Hugin manual being rewritten . . .
Thanks. I'll check it out. On Monday, April 15, 2013 4:36:10 AM UTC-5, Harry van der Wolf wrote: I will update it to make it more clear but in the User Interface section is a link to the complete 2012 version manual. Like: *(Go to Version 2012 and older Guihttp://wiki.panotools.org/Hugin_Main_window_old_guito read about the old gui which is being used in the current stable release. Note that all Hugin 2012 and older versions come with the help screens installed. You can read the same texts as in this wiki by simply opening Hugin and clicking the Help option from the Help menu)* Harry 2013/4/15 Erik Krause erik@gmx.de javascript: Am 15.04.2013 01:21, schrieb JohnPW: Why is the Hugin Manualhttp://wiki.panotools.**org/Huginhttp://wiki.panotools.org/Hugin being replaced with one for the new GUI in the 2013 version of hugin when: The wiki doesn't forget. You can view any older revision following the View history link. I suggest to insert a link pointing to the last relevant revision. -- Erik Krause http://www.erik-krause.de -- -- 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_FAQhttp://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugi...@googlegroups.comjavascript: To unsubscribe from this group, send email to hugin-ptx+...@** googlegroups.com javascript: For more options, visit this group at http://groups.google.com/** group/hugin-ptx 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+...@**googlegroups.com javascript:. For more options, visit https://groups.google.com/**groups/opt_outhttps://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] Why is the Hugin manual being rewritten . . .
Yes, I never got that working correctly and settled on the last 2012 version. I have had the same problem with newer 2013 versions I have found (and could not fix them.) The version you link to is newer than the last one I tried. I'll give it a try. Thanks, John On Wednesday, April 17, 2013 3:37:57 PM UTC-5, Harry van der Wolf wrote: 2013/4/17 JohnPW johnpw...@gmail.com javascript: Harry, If you point me to a compiled binary you recommend for OS X 10.8.3 I will give you exhaustive feedback. John Some time ago I built the 2013beta1 which you downloaded and where you had issues with ptbatcherGui (1). That issue is related to library versions and not the gui modifications. We had the same questions from users going from 2011.04 to 2012.0. Lately Furai (Mathieu) also built a hugin for mac (2) which does run on 10.8.3 as I tested it on a 10.8.3 mac of a friend. Take the build from his last post (I haven tested that one yet as I didn have the possibility to test on that friends mac). Harry (1): https://groups.google.com/forum/?fromgroups=#!topic/hugin-ptx/ODEnrEwdn8U (2): https://groups.google.com/forum/?fromgroups=#!searchin/hugin-ptx/furai$20hugin$20bundle/hugin-ptx/L4HJkEakJ3A/pY2iuhzj7zoJ -- -- 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] Why is the Hugin manual being rewritten . . .
I guess I should say *similar* rather than *the same* problems. I thought it was resolved and didn't realize it was the same problem as previously. Thanks again. PS, I also know there are inevitable problems in transitioning to a new person who does the Mac release work. It's great that Furai is doing it. I wish I could help in some way. My expertise though is more in the way of UI, UX, and IxD. John On Wednesday, April 17, 2013 3:50:12 PM UTC-5, JohnPW wrote: Yes, I never got that working correctly and settled on the last 2012 version. I have had the same problem with newer 2013 versions I have found (and could not fix them.) The version you link to is newer than the last one I tried. I'll give it a try. Thanks, John On Wednesday, April 17, 2013 3:37:57 PM UTC-5, Harry van der Wolf wrote: 2013/4/17 JohnPW johnpw...@gmail.com Harry, If you point me to a compiled binary you recommend for OS X 10.8.3 I will give you exhaustive feedback. John Some time ago I built the 2013beta1 which you downloaded and where you had issues with ptbatcherGui (1). That issue is related to library versions and not the gui modifications. We had the same questions from users going from 2011.04 to 2012.0. Lately Furai (Mathieu) also built a hugin for mac (2) which does run on 10.8.3 as I tested it on a 10.8.3 mac of a friend. Take the build from his last post (I haven tested that one yet as I didn have the possibility to test on that friends mac). Harry (1): https://groups.google.com/forum/?fromgroups=#!topic/hugin-ptx/ODEnrEwdn8U (2): https://groups.google.com/forum/?fromgroups=#!searchin/hugin-ptx/furai$20hugin$20bundle/hugin-ptx/L4HJkEakJ3A/pY2iuhzj7zoJ -- -- 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] Why is the Hugin manual being rewritten . . .
Clearly I've offended you. Very sorry. Appreciate your efforts and everyone's. My not wanting to run Linux in emulation on my Mac was not meant to discount Linux. I simply am not capable of learning and running multiple OSs, much less flavors of Linus that (like it or not) are really not very usable for everyday, non technical, users. Unix on my Mac is about as far as I can go, and believe me, I can't even go very far into it either! On Wednesday, April 17, 2013 4:27:54 PM UTC-5, Stefan wrote: Hi JohnPW On 17.04.2013 22:14, JohnPW wrote: It's great that it's running well on Linux. but I'm not a Linux user and don't plan to use Linux. The last thing I plan to do is run Linux on my Mac. Just because it's possible to do that does not mean it's desirable. So, please do as being told by Terry: Let us know _why_ exactly you can't run 2013.0-beta1 on your mac. Remember, This possibly will not only help you, but all these other mac users that may have the same problem. An, no _I_ can not help you here: I can not afford (and I don't want) to use a mac. So, all the help you will get has to come from other mac users. If you mac users don't unite and make yourselves heard here, you will be left in the cold. The term It works here on linux was not meant to fend of your complaint or make you change your OS. It just means that Terry does not have a mac and can not help you therefore. But he can tell you that there is no fundamental problem with 2013.0 because he has it running on a *nix system without issues. And because macos is unix based, too, this is relevant. Sure I get that. As I said though, even if I'm testing it on my my Mac in a Linus emulator/interface (or whatever) that does not move the software forward since nobody in their right mind sees that as a working option. I think Terry meant it more so that I could see how the interface is supposed to work (in any case, it's not an option I can do.) It's great there is work being done on improving the interface, but from what I can see, the new interface is not an improvement. But since there is no plan to see, I guess it's hard to say for sure. In any case these two issues (1. doesn't run, and no articulated plan) tell me that this version has been prematurely made the default branch, (if I understand the term correctly.) The it does not run part possibly affects only you. I know for sure that there are mac users running 2013.0-beta1. For fixing this, please speak up and let us know _why_ exactly you can not use it and _how_ this manifests on your mac. With other words, the other mac users on this list need facts in order to be able to help you. Yes Harry was very helpful. I have downloaded a version Harry recommended that works enough so I can see how the interface is supposed to work. So, please let us know o what you have downloaded o where you did get it from o how did you install it o what has happened upon execution o what did you expect to happen so the sparely few mac packagers and 0users may help you. The there is no plan issue is harder to explain, but I try anyhow. You are right, there is not _one plan_ for developing hugin. There are a gazillion plans because hugin is an open source project with _no_ marketing department, _no_ CEO, _no_ budget and _no_ central guru with a divine inspiration but plenty of users and some developers that all have their own itches to scratch. Accordingly, they will try to steer the project in the direction they feel it ought to go. The new interface was discussed on this mailing list for the last 8 months at least and if you did not speak up then, you missed your opportunity to influence the new interface. Of course, you are free to criticize the result of this development step, but after the work put into it by all participants, you really will need some stronger arguments than your climbing expeditions analogies. Actually I did take part in discussions (as much as I could when I found them.) But text discussions without visual mockups are not very accessible to most people since it is an inefficient way to discuss visual phenomena and interaction. I saw this UI as more of an experiment than a next course of action and I did raise objections at the time. Frankly I was hoping the next step would reveal more of a plan that could be discussed before implementation. My expedition analogy is more to the point I think than you realize. If there is no plan, nobody can comment on it. If there is no plan, there is no goal. There's nothing wrong with that, but it is experimentation, not implementation. Now that I have seen the UI as it is intended, I am happy to comment and give my best possible feedback, opinions, advice, etc. With kind regards Stefan Peter I take your post in the best spirit, as I am sure you intended. And thanks for our efforts. John
Re: [hugin-ptx] Why is the Hugin manual being rewritten . . .
Yes, Terry no problem. Sorry my response wasn't clear. You are correct, it is not a religious thing on my part, I just don't think I can do Linux on Mac on Unix etc. ;-) I'm just not technically savvy enough. As you may have read (by now) in the message I was posting to Stephan (as you were posting this one) Harry pointed me to a reasonably working 2013 version so I now have seen the interface. Many of the things I was concerned about with the original beta I tried late last year and earlier this year have been implemented. They work better now, but I still am concerned about them. I'll try to articulate useful feedback on it as I can. Thanks again, John On Wednesday, April 17, 2013 6:20:21 PM UTC-5, Tduell wrote: Hello John, On Thu, 18 Apr 2013 06:14:45 +1000, JohnPW johnpw...@gmail.comjavascript: wrote: It's great that it's running well on Linux. but I'm not a Linux user and don't plan to use Linux. The last thing I plan to do is run Linux on my Mac. Just because it's possible to do that does not mean it's desirable. Well, the 'desirability', is that it is a way for you to experience the new gui, rather than have to wait on a mac version that works for you, but if that is not an option, that's OK. It's great there is work being done on improving the interface, but from what I can see, the new interface is not an improvement. But since there is no plan to see, I guess it's hard to say for sure. In any case these two issues (1. doesn't run, and no articulated plan) tell me that this version has been prematurely made the default branch, (if I understand the term correctly.) The new gui simply does the same things with the controls laid out a bit differently. Whether all aspects of it are an improvement is probably an individual point of view. I think putting the assistant controls in the fast preview window is good for new users. It took me a while to come to grips with the previous interface when I first started using Hugin, and in that respect the new gui is no different . Once you become familiar with the new interface you just 'use it'. Hopefully you will have a working version real soon. Cheers, -- Regards, Terry Duell -- -- 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.
[hugin-ptx] Why is the Hugin manual being rewritten . . .
Why is the Hugin Manual http://wiki.panotools.org/Hugin being replaced with one for the new GUI in the 2013 version of hugin when: 1.) As far as I can tell, Hugin2013 is a *beta* version, 2.) it presently doesn't work (at least not on my computer) and, 3.) not wanting to offend, but frankly it looks like a troubled interface in many ways? Wouldn't it make more sense to preserve a functional manual for each version in it's mature state so that people can get good documentation for working versions of Hugin? As far as the 2013 version, Apparently there is enthusiasm for it, and that's great, but as little as I have seen of it (since it doesn't seem to work on the Mac platform,) I find the concept and usability of the new GUI (in all of it's user modes) rather questionable (so far as I can parse it.) I'm sorry if I'm off base or ill informed. All I can go by is what I have seen and tried of the software on my machine. Perhaps it's fabulous on other platforms, but it doesn't run on my Mac and from what I can see, the HCI approach seems confused in terms of usability, clarity, and the model of operation. Had I seen any discussion about the GUI, I'd have gladly given feedback on it along the way, but I've never really seen any plan for it or discussion about it (I'm assuming it's a bit of a skunk works operation?) I'd be interested in seeing where the 2013 version of the GUI is going, if someone could communicate it. In any case, until it's finished and running well and on all platforms, shouldn't the documentation for the version that presently works on all platforms be preserved? Indeed, shouldn't the documentation for each mature version be preserved so people can use it? (I can't see moving to Hugin2013 anytime soon.) 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.
Re: [hugin-ptx] Re: Architectural plans alignment
That makes sense, Terry. I need to think about the variables and only enable the relevant ones instead of over enabling them and assuming they will sort themselves out during optimization. There are definitely problems with the roof drawing though. One is inaccuracy (from distortion in the base images used to make them?) and the other is that the two drawings don't match (dormers are different.) I think the basic idea should work though. On Tuesday, April 9, 2013 12:26:36 AM UTC-5, Tduell wrote: On Tue, 09 Apr 2013 15:09:23 +1000, Terry Duell tdu...@iinet.net.aujavascript: wrote: On Tue, 09 Apr 2013 15:07:21 +1000, Terry Duell tdu...@iinet.net.aujavascript: wrote: and optimise y, Trx, Try, Trz,. Ooops, sorry, that was meant to be r,Trx, Try, Trz. Here is the .pto resulting from optimising r, Trx, Try, Trz, and using a different lens for each image. It optimised with a pretty small error, and the remapped images look like they should line up OK, but I really haven't checked. One image needs to be given some transparency and then overlaid on the other...not sure how to that. Cheers, -- Regards, Terry Duell -- -- 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.
[hugin-ptx] Re: Architectural plans alignment
Hi, It seems to me that any wonky-ness must be with the roof drawing. The plan, being a measured drawing and directly scanned should be nearly perfect. I have to admit, I don't follow how one would get a roof drawing from GIS, but I assume it was originally from an arial photo? Anyway, It seems to me, that the roof image should be stretched to fit the plan (which theoretically would be easiest to do manually. Set some identifiable key anchor points on the line drawing that correspond to points on the plan and stretch (perhaps the ridge-line or probable locations of the corners of the underlying building?) But if this hasn't worked for you, pserhaps you should show us your result and the problems you encountered? John On Monday, April 8, 2013 4:37:44 AM UTC-5, Martin Isak Jansen wrote: Dear group! Ingredients: I have a bunch of architectural floor plans that is old (1918) and hand drawn. They are big scans. https://lh5.googleusercontent.com/-mc-OUm2w6Ns/UWKPt2LjpxI/CpA/fP2eVQt_gRc/s1600/163_532+163_533+163_534+163_535Tegning+10.05.jpg I also have a new line drawing of the roofs that is in correct scale (from a GIS program). https://lh4.googleusercontent.com/-BBRu7Ha8qUk/UWKP0BmZXeI/CpI/IRbG7YCKvFA/s1600/Screen+Shot+2013-04-08+at+11.36.18.png What I want: What I would like to achieve is to align all floor plans with the new roof line drawing so it all matches on top of each other and are in scale. I have tried manually stretch and rotate the drawings to match etch other, but the result is a bit wonky. So I thought that this might be done better with some hugin magic. The resulting file could be separated files or one file with layes. How: I have a little experience with using hugin for panoramas, but this is way beyond my hugin experience. Any suggestions? -- -- 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.
[hugin-ptx] Re: Architectural plans alignment
On looking at your example images carefully, they don't seems to be from the same building (the dormers do not appear to be arranged in the same way on the two plans, no matter how the images are oriented.) Do these two images go together, or are they just examples? John On Monday, April 8, 2013 12:59:37 PM UTC-5, JohnPW wrote: Hi, It seems to me that any wonky-ness must be with the roof drawing. The plan, being a measured drawing and directly scanned should be nearly perfect. I have to admit, I don't follow how one would get a roof drawing from GIS, but I assume it was originally from an arial photo? Anyway, It seems to me, that the roof image should be stretched to fit the plan (which theoretically would be easiest to do manually. Set some identifiable key anchor points on the line drawing that correspond to points on the plan and stretch (perhaps the ridge-line or probable locations of the corners of the underlying building?) But if this hasn't worked for you, pserhaps you should show us your result and the problems you encountered? John On Monday, April 8, 2013 4:37:44 AM UTC-5, Martin Isak Jansen wrote: Dear group! Ingredients: I have a bunch of architectural floor plans that is old (1918) and hand drawn. They are big scans. https://lh5.googleusercontent.com/-mc-OUm2w6Ns/UWKPt2LjpxI/CpA/fP2eVQt_gRc/s1600/163_532+163_533+163_534+163_535Tegning+10.05.jpg I also have a new line drawing of the roofs that is in correct scale (from a GIS program). https://lh4.googleusercontent.com/-BBRu7Ha8qUk/UWKP0BmZXeI/CpI/IRbG7YCKvFA/s1600/Screen+Shot+2013-04-08+at+11.36.18.png What I want: What I would like to achieve is to align all floor plans with the new roof line drawing so it all matches on top of each other and are in scale. I have tried manually stretch and rotate the drawings to match etch other, but the result is a bit wonky. So I thought that this might be done better with some hugin magic. The resulting file could be separated files or one file with layes. How: I have a little experience with using hugin for panoramas, but this is way beyond my hugin experience. Any suggestions? -- -- 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] Re: Hugin 2013.0beta1 released
Thanks, Harry, After my last difficulties with using multiple versions on the same machine, I have to admit that I'm a bit scared to run this version. We'll see . . . Sorry I'm clever enough to help out on the Mac distros. If there is anything I can do that's helpful but hard to screw up, I'd be glad to help. John On Wednesday, March 6, 2013 2:32:21 PM UTC-6, Harry van der Wolf wrote: Hi users, I built a bundle (again) for the 2013.0beta1. You can download it from SourceForge via the following link: http://sourceforge.net/projects/hugin/files/hugin/hugin-2013.0/hugin-mac-2013.0.0_beta1.dmg/download The coming 2-3 days I will rewrite the wiki page at (1)http://wiki.panotools.org/Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode . After that I will send out a new invitation to become a Mac OS X builder and I hope the new OS X builders will massively step forward. I wanted to do that much earlier but that obviously didn't take place. Hoi, Harry (1): http://wiki.panotools.org/Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode -- -- 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] Abridged summary of hug...@googlegroups.com - 10 Messages in 6 Topics
Hey GN, Saw this and thought of our conversation. http://tirania.org/blog/archive/2013/Mar-05.html Miguel has discovered that he's switched to OS X! The next thing you know I'll be going to Linux! (actually, I wouldn't even know how, if I wanted!) Anyway, it surprised me. Just goes to show that all platforms have their tradeoffs, depending on what you want to do and how you want to do it. To wit, our Harry (v. d. W.) moved from the Mac to (Gnome?) on Linux last year. -- -- 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] Google Summer of Code 2013
I'm not following this idea. Can you elaborate a bit? How would a control dowel work and what would it do? On Wednesday, February 27, 2013 9:48:52 PM UTC-6, Bob Campbell wrote: On Feb 21, 2013, at 7:09 PM, Jim Watters wrote: Hugin and Panotools community, What new ideas do you have that a student could implement? I'm the type to make panos while holding my p-n-s Canon S95. I've tried doing some bracketed shots and create HDR from that, but I've had limited success. Mainly due to hand movement and images in one stack overlapping another stack too much. Understandable, really. But the thought occurred to me that maybe instead of control points, what we really need are control dowels - sort of like forensic police dowels used to plot the trajectory of a bullet**. I would think it would allow connecting different exposure levels of the pano together easily, as well as through each stack? Maybe a little ambitious? I don't know of any other software using that type of system, so it might be a good opportunity at breaking new ground for some aspiring student. ** - https://www.ridgidforum.com/forum/attachments/4791d1225679629-texas-traffic-stop-3.jpg I freely admit that I'm not sure the ROI on this would justify the effort. Just throwing it out there. Bob Campbell -- -- 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] Abridged summary of hug...@googlegroups.com - 10 Messages in 6 Topics
On Thursday, February 21, 2013 1:01:17 AM UTC-6, GnomeNomad wrote: I did. I never said OS X was never OSS. I said it had moved so far beyond its OSS foundation (Darwin) that in my opinion it's no longer OSS. No, it was *I* who was saying that OS X was never OSS, (because it never was.) I was simply pointing out it's standard OSS underpinnings (perfectly good for running OSS, even if it's not the most popular platform for doing so.) But forget it, as this is getting silly. In a strict interpretation of some OSS licenses, some might say that *OS X would be in violation of those licenses*. Some might might say that the earth is flat and the moon is made of green cheese, but so what.? Strict or lax, interpretation of some OSS licensing schemes is irrelevant, since Apple and OS X don't violate the licenses that apply to the code they use. But this isn't making Hugin any better, regardless of platform it happens to run on. Now Hugin on a Google Nexus 10 - that would be interesting! Go for it! And could you also maintain an iOS compatible version? Or is that too much to ask? ;-)** I truly wish I has some coding talent so I could help out. But as I've said elsewhere, I'm an UI/UX guy! John **[actually have you checked out the panorama feature on the iPhone? I didn't expect much from it but it's actually pretty darn good (for partial panoramas.) I've only tried similar panorama features on PS cameras before, but the Apple SW does a better job than I've seen there. I wonder how they have optimized the software and what, if any, OSS libraries it uses. I'll have to take a look at the credits.] On 02/20/2013 09:24 AM, JohnPW wrote: Me, I'm sure you know that *Darwin is an OSS OS* You, *OS X* has moved so far beyond its Darwin roots that in my opinion it *is no longer open source* Me, [my point being OS X *was **never* open source] . . . you're misinformed about Darwin and OS X. After all, *Darwin is an Apple led OSS effort* and OS X (Apple's complete *commercial OS, which is not OSS*) consists of a number of other software parts (some proprietary, and some not) . . . *all running atop Darwin*. You, Sounds like *OS X is proprietary*, to me*- not OSS*. It may have a slab of Darwin OSS beneath it, but *OS X is not Darwin*. Did you read anything I wrote before you commented on it? :-) John On Wednesday, February 20, 2013 2:30:17 AM UTC-6, GnomeNomad wrote: So to turn Darwin into OS X, we only need to add a number of other items, particularly key Apple-proprietary (non-OSS) pieces. Sounds like OS X is proprietary, to me - not OSS. It may have a slab of Darwin OSS beneath it, but OS X is not Darwin. So OS X is no longer OSS. Doesn't sound strange to me at all! Anyway, I've used OS X (and Windows and OS/2 and Linux), too. Glad you enjoy it! On 02/19/2013 01:14 PM, JohnPW wrote: I'm sure your an expert in your bailiwick, but I think you're misinformed about Darwin and OS X. After all, Darwin is an Apple led OSS effort and OS X (Apple's complete commercial OS, which is not OSS) consists of a number of other software parts (some proprietary, and some not) such as OpenGL QuickTime, Quartz, Cocoa, and the Aqua UI, all running atop Darwin. So to say OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. is a strange thing to say in any of a number of ways. In any case, I applaud efforts, of all kinds, to create good software for people to use. And I love my Mac that's running OS X (which stands on the shoulders of OSS just as Linux does.) If you think Linux is the best thing since sliced bread, then more power to you. Because I think people deserve to use whatever OS they decide they like (with all the good and bad trade-offs entailed in their choice.) :-) On Monday, February 18, 2013 1:17:07 PM UTC-6, GnomeNomad wrote: OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. You can't get yourself a full copy of Mac OS X by simply downloading the Darwin source and compiling it ... -- Gnome Nomad -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- -- 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
[hugin-ptx] Re: Can't make a HDR Panoramic for use in Autodesk Maya.
I don't use Maya, but have use environmental maps and light probes with
other SW in the past. Cylindrical can work as long as the Zenith hole
doesn't show up (non reflective subject.) But I assume Maya allows you to
use a spherical panorama (equirectangular projection,) which is much easier.
John
On Thursday, February 21, 2013 10:06:48 AM UTC-6, rhys...@gmail.com wrote:
hi,
I've managed to make a .tif panoramic but I need a HDR for use as an
environment map within Maya.
What type of Projection should i use for an environment map? I'm currently
using Cylindrical.
this is the log from last attempt:
Disc usage
Filesystem Size Used Avail Capacity iused ifree %iused
Mounted on
/dev/disk2 2.8Ti 106Gi 2.7Ti 4% 27932446 7304151044% /
devfs 195Ki 195Ki0Bi 100% 676 0 100% /dev
map -hosts0Bi0Bi0Bi 100%0 0 100% /net
map auto_home 0Bi0Bi0Bi 100%0 0 100% /home
/dev/disk3s1s2 248Mi 248Mi0Bi 100%63517 0 100%
/Volumes/VFF1067
/dev/disk5s2 60Mi 48Mi 13Mi79%12163 3252 79%
/Volumes/hugin-mac-2012.0.0-installer
===
Output options
===
Hugin Version: 2012.0.0 built by Harry van der Wolf
Project file:
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
Output prefix: 1-5
Projection: Cylindrical (1)
Field of view: 360 x 72
Canvas dimensions: 11804 x 2754
Crop area: (1718,320) - (11297,2754)
Output exposure value: 7.23
Selected outputs
Normal panorama
* Blended panorama
HDR merging
* Merged and blended panorama
===
Input images
===
Number of images in project file: 5
Number of active images: 5
Image 0: /Users/rhys/Desktop/cemp/hdr2/1.tif
Image 0: Size 4605x3452, Exposure: 8.52
Image 1: /Users/rhys/Desktop/cemp/hdr2/2.tif
Image 1: Size 4607x3454, Exposure: 8.82
Image 2: /Users/rhys/Desktop/cemp/hdr2/3.tif
Image 2: Size 4605x3452, Exposure: 5.91
Image 3: /Users/rhys/Desktop/cemp/hdr2/4.tif
Image 3: Size 4604x3453, Exposure: 6.09
Image 4: /Users/rhys/Desktop/cemp/hdr2/5.tif
Image 4: Size 4605x3452, Exposure: 6.81
===
Testing programs
===
Checking nona...[OK]
Checking enblend...[OK]
Checking enfuse...[OK]
Checking hugin_hdrmerge...[OK]
Checking exiftool...[OK]
===
Stitching panorama
===
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -z LZW -r ldr -m
TIFF_m -o 1-5 -i 0
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -z LZW -r ldr -m
TIFF_m -o 1-5 -i 1
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -z LZW -r ldr -m
TIFF_m -o 1-5 -i 2
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -z LZW -r ldr -m
TIFF_m -o 1-5 -i 3
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -z LZW -r ldr -m
TIFF_m -o 1-5 -i 4
/var/folders/69/gmd6v3mx3l3d3r6qwgvdl33hgn/T/huginpto_AMPq3a
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/enblend
--compression=LZW -w -f9579x2434+1718+320 -o 1-5.tif -- 1-5.tif
1-50001.tif 1-50002.tif 1-50003.tif 1-50004.tif
enblend: info: loading next image: 1-5.tif 1/1
enblend: info: loading next image: 1-50001.tif 1/1
enblend: info: loading next image: 1-50002.tif 1/1
enblend: info: loading next image: 1-50003.tif 1/1
enblend: info: loading next image: 1-50004.tif 1/1
enblend: info: writing final output
enblend: error: OJPEG encoding not supported; use new-style JPEG
compression instead
/Applications/Hugin/PTBatcherGUI.app/Contents/Resources/ExifTool/exiftool
-E -overwrite_original_in_place -TagsFromFile
/Users/rhys/Desktop/cemp/hdr2/1.tif -ImageDescription -Make -Model -Artist
-WhitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate -UserComment
-ColorSpace -OwnerName -SerialNumber '-Software=Hugin 2012.0.0 built by
Harry van der Wolf' '-UserComment${UserComment}#xa;Projection:
Cylindrical (1)#xa;FOV: 360 x 72#xa;Ev: 7.23' -f 1-5.tif
1 image files updated
/Applications/Hugin/PTBatcherGUI.app/Contents/MacOS/nona -r hdr -m EXR_m
-o 1-5_hdr_ -i 0
Re: [hugin-ptx] Abridged summary of hug...@googlegroups.com - 10 Messages in 6 Topics
Me, I'm sure you know that *Darwin is an OSS OS* You, *OS X* has moved so far beyond its Darwin roots that in my opinion it *is no longer open source* Me, [my point being OS X *was **never* open source] . . . you're misinformed about Darwin and OS X. After all, *Darwin is an Apple led OSS effort* and OS X (Apple's complete *commercial OS, which is not OSS*) consists of a number of other software parts (some proprietary, and some not) . . . *all running atop Darwin*. You, Sounds like *OS X is proprietary*, to me* - not OSS*. It may have a slab of Darwin OSS beneath it, but *OS X is not Darwin*. Did you read anything I wrote before you commented on it? :-) John On Wednesday, February 20, 2013 2:30:17 AM UTC-6, GnomeNomad wrote: So to turn Darwin into OS X, we only need to add a number of other items, particularly key Apple-proprietary (non-OSS) pieces. Sounds like OS X is proprietary, to me - not OSS. It may have a slab of Darwin OSS beneath it, but OS X is not Darwin. So OS X is no longer OSS. Doesn't sound strange to me at all! Anyway, I've used OS X (and Windows and OS/2 and Linux), too. Glad you enjoy it! On 02/19/2013 01:14 PM, JohnPW wrote: I'm sure your an expert in your bailiwick, but I think you're misinformed about Darwin and OS X. After all, Darwin is an Apple led OSS effort and OS X (Apple's complete commercial OS, which is not OSS) consists of a number of other software parts (some proprietary, and some not) such as OpenGL QuickTime, Quartz, Cocoa, and the Aqua UI, all running atop Darwin. So to say OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. is a strange thing to say in any of a number of ways. In any case, I applaud efforts, of all kinds, to create good software for people to use. And I love my Mac that's running OS X (which stands on the shoulders of OSS just as Linux does.) If you think Linux is the best thing since sliced bread, then more power to you. Because I think people deserve to use whatever OS they decide they like (with all the good and bad trade-offs entailed in their choice.) :-) On Monday, February 18, 2013 1:17:07 PM UTC-6, GnomeNomad wrote: OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. You can't get yourself a full copy of Mac OS X by simply downloading the Darwin source and compiling it ... -- Gnome Nomad gnome...@gmail.com wandering the landscape of god http://www.clanjones.org/david/ http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ http://www.cafepress.com/otherend/ -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- -- 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] Re: The viewable sphere
Thanks, I missed that the second reference was the second part. -- -- 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] Abridged summary of hugi...@googlegroups.com - 10 Messages in 6 Topics
I'm sure your an expert in your bailiwick, but I think you're misinformed about Darwin and OS X. After all, Darwin is an Apple led OSS effort and OS X (Apple's complete commercial OS, which is not OSS) consists of a number of other software parts (some proprietary, and some not) such as OpenGL QuickTime, Quartz, Cocoa, and the Aqua UI, all running atop Darwin. So to say OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. is a strange thing to say in any of a number of ways. In any case, I applaud efforts, of all kinds, to create good software for people to use. And I love my Mac that's running OS X (which stands on the shoulders of OSS just as Linux does.) If you think Linux is the best thing since sliced bread, then more power to you. Because I think people deserve to use whatever OS they decide they like (with all the good and bad trade-offs entailed in their choice.) :-) On Monday, February 18, 2013 1:17:07 PM UTC-6, GnomeNomad wrote: OS X has moved so far beyond its Darwin roots that in my opinion it is no longer open source. You can't get yourself a full copy of Mac OS X by simply downloading the Darwin source and compiling it ... -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- -- 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.
[hugin-ptx] Re: The viewable sphere
Good article. Very approachable and clear. I didn't expect that from a maths journal. I especially like the description of the stereographic projection. The images in figs. 1 4 were especially useful. I hope the second part of the article is also easily available. Let us know when it comes out. Also the link it gave for the projections website is also very good (once I caught and removed the extra space in the address.) http://www.progonos.com/furuti/MapProj/Normal/TOC/cartTOC.html Thanks again, John On Monday, February 18, 2013 8:47:10 PM UTC-6, Tduell wrote: Hello All, For anyone interested there is a good article on the subject (Mathematics Meets Photography by David Swart and Bruce Torrence), which includes discussion on the related projections and transformations, in The Best Writing on Mathematics 2012 published by Princeton University Press. The original articles were published in Maths Horizons 19.1 (2011): 14-17 and Maths Horizons 19.2 (2011): 24-27. Cheers, -- Regards, Terry Duell -- -- 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.
[hugin-ptx] Re: The viewable sphere
Thanks, BTW, Googled it and found this link, which is offered as a sample article: http://www.maa.org/mathhorizons/MH-Sept2011_MathPhotography.pdf 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.
Re: [hugin-ptx] (Not a Hugin topic, but related) — De-blurring images
As so often happens to me, the install (using MacPorts) of wine failed because of some underlying library it depends on isn't quite right and will not install. I think this is the sort of thing that keeps most ordinary folks from using OSS. Perhaps I'll try again later. :-) On Saturday, February 16, 2013 4:56:34 PM UTC-6, JohnPW wrote: I think I'll venture to download wine to try this out. Thanks Harry -- -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx --- 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] (Not a Hugin topic, but related) — De-blurring images
I'm sure you know that Darwin is an OSS OS and I do see your winking smilie. I appreciate OSS greatly. But getting, compiling, installing, and using it can be a PITA, with or without a porting tool. Even precompiled binaries have their problems. If I have difficulty, I know 90% of people will have the similar or worse problems. And most certainly, other than the most stable of precompiled binaries, it isn't suitable for my Mom. She's not into tracking down incompatibilities or compilation bugs. I suppose as with most things, OSS's strength is also it's weakness. Constant change and improvement inevitably also leads to churn and breakage. On Sunday, February 17, 2013 9:37:57 PM UTC-6, GnomeNomad wrote: Hmmm, WINE installs just fine on my systems. Oh, sorry, I'm using Linux, not Mac. Don't blame OSS for problems when running a non-OSS OS. ;-) On 02/17/2013 04:08 PM, JohnPW wrote: As so often happens to me, the install (using MacPorts) of wine failed because of some underlying library it depends on isn't quite right and will not install. I think this is the sort of thing that keeps most ordinary folks from using OSS. Perhaps I'll try again later. :-) On Saturday, February 16, 2013 4:56:34 PM UTC-6, JohnPW wrote: I think I'll venture to download wine to try this out. Thanks Harry -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- -- 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] (Not a Hugin topic, but related) — De-blurring images
I think I'll venture to download wine to try this out. Thanks Harry On Saturday, February 16, 2013 2:09:09 AM UTC-6, Harry van der Wolf wrote: Hi John, 2013/2/15 JohnPW johnpw...@gmail.com javascript: Is there any linux (OS X) compatible implementation out there? I was immediately interested but it came without source. However, it runs fine in wine. I tried on both OS X and Ubuntu 12.10. Harry -- -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx --- 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.
[hugin-ptx] (Not a Hugin topic, but related) — De-blurring images
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 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.
[hugin-ptx] Re: (Not a Hugin topic, but related) — De-blurring images
Here's a link to a related video. http://tv.adobe.com/watch/max-2011-sneak-peeks/max-2011-sneak-peek-image-deblurring/ -- -- 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] (Not a Hugin topic, but related) — De-blurring images
Thanks Terry, As always, a well exposed image taken from a tripod mounted camera is the best way to get a sharp image. It appears that the technique can produce some artifacts, but it also appears to improve blurry images to an amazing degree. Frankly it's amazing to me, as it seems to go against the Garbage in, Garbage out maxim. On the other hand, I suppose no information is being created, the existing information is just simply being clarified and distilled. Still it's like magic. The math looks complicated though! John On Friday, February 15, 2013 4:31:56 PM UTC-6, Tduell wrote: Hello John, On Sat, 16 Feb 2013 08:56:37 +1100, JohnPW johnpw...@gmail.comjavascript: 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 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. I spent what seemed like quite a large bit of my life, a couple of years ago, attempting to get a decent method of de-blurring an image that was part of a pano set. There was quite a bit of discussion on the group at the time. I don't recall trying this code, and probably didn't because the source wasn't available. I worked with various methods (Oliver Whyte, Krishnan, Fergus and others) and in the end came to the conclusion that the state of the art wasn't good enough to be able to de-blur an image so that it could fit amongst sharp images in a pano. Most of the methods are probably reasonable at de-blurring a single image. It is when the de-blurred image is next to a sharp in a pano that the techniques come up a bit short. Cheers, -- Regards, Terry Duell -- -- 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.
[hugin-ptx] Re: no output photo created
Ah the eternal complaint of technicians about users — blame the user isn't the answer. ;-) (I know we all know now that he has indeed read the FAQ, and that you misunderstood, but I'm responding anyway because addressing the assumed problem is important too.) It's hard for the people who know Hugin and PanoTools inside out and can read and write code fluently to see, but using Hugin is not all that easy or intuitive. And as much work that is put into tutorials and FAQs, the authors often assume the reader possesses a ton of obscure or invisible knowledge. Then there are the tutorials that after hours of study, a user discovers that they inapplicable to to current versions, out of date, or obsolete (even if interesting none the less.) This is not at all uncommon with OSSW, but it is especially hard on users who do not have extensive knowledge of computing/math/programing/optics/digital imaging minutia. Then there is the fact that despite everyones's best efforts, there is little holistic organization to the educational information and very little big picture explanation to boot. In the end it's not that people don't read them (although some don't.) It's more that it's pretty hard to read and understand them, and to know what to read and what not to read, and where the stuff one should read really is. It's hard for everybody on all sides, as evidenced by your frustration above. I'm just glad and very thankful that you, Thomas, and all the other contributors, have put so much effort into Hugin. I know it's a lot of work, but Hugin is a great project that keeps getting better because of the efforts of so many people. Thanks, John On Thursday, February 7, 2013 10:27:21 AM UTC-6, T. Modes wrote: Hi Don, On 7 Feb., 09:31, Don eaglet...@ozemail.com.au wrote: Im sure the problem relates to the set-up of the user accounts. Although I have created a new user called DonandSue, when I, for example, perform Start, then enter CMD, I get the old DOS prompt, but the path is C:\Users\DonSue, i.e. there is still some residuals of the old user and I'm not sure how to fix this. I used Profile Wizard to copy the profile from the old user to the new one originally, but I know there are still files under C:\Users\DonSue. I'm struggling with what I need to do to remove all mention of the old user and have everything referencing the new user. Again, have you read the mentioned FAQ?? The problem is the ampersand in the directory of your temp path. So create a directory c:\temp. Then StartControl PanelUser AccountChange my environment variables Search for TEMP and TMP: it should be something like %USERPROFILE% \AppData\Local\Temp or c:\Users\DonSue\AppData\Local\Temp. Change these 2 variables to c:\temp. Why do we write the FAQ or docs, if nobody reads them?? 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 --- 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] Vignetting in output
I suggest comparing apples to apples. Use all the same parameters for camera, lens, and image on both trials. It appears the output images were not remapped in the same way before they ever got to the blending and sticking steps. On Saturday, February 2, 2013 4:24:25 PM UTC-6, Andrew Baddeley wrote: I tried setting the Enblend options to -l 29 and that didn't have any noticeable effect. AB -- -- 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.
[hugin-ptx] Re: [remote sensing] Use of Hugin to stitch thermal imagery (methods + results)
On Tuesday, January 29, 2013 1:52:26 PM UTC-6, Julien Schroder wrote: Well our work was exploratory, we are in a really windy area and the overlap wasn't calculated right that is why it is full of gap. It's pretty hard ot fly totally straight with a plane in this area so that is the best we were able to do. Didn't realize it was new data. As I have said, I know little of aerial photography. I suppose the camera can't be stabilized or gimbaled in any way? Presumably, each thermal image has no real time data associated with it (i.e. location, heading, altitude, and attitude of the camera, distance to ground, etc.?) I have no idea if this is normally done, but it seems like it would be an obvious thing to do if the images were taken within the last 10 years or so. If this data were available (and machine readable) one could easily create a script that would calculate a very good initial arrangement of the images before even using nona (especially since this appears to be a very flat landscape [the meandering streams.]) This would take care of 90% of the work without even having to open the images. Clearly this makes too much sense to actually happen in our imperfect world! :-) John Actually it could have time, I have full GPS and time data for those flight but I wasn't able to use them in any way. If it was RGB I would have used photoscan to create a georeferenced mosaic but since our data were 32 bits we had to find another way. I didn't find any usable script to align all those TIFF, the feature detection algorithm were always too long and complicated to apply, so hugin ended up being the fastest and best looking solution. What kind of script do you have in mind, something which would align the pictures? Thanks I'm not a script type of guy, so I can't say exactly how it could be done. In any case it depends on exactly what data you have and how accurate it is. But even a little accurate data might help you. My thought was that if you had camera location and orientation data, you could combine that with GIS data to calculate good initial YPR and XYZ data for each individual image before you even use Hugin. With this initial data plugged into Hugin, you could use the pre aligned panorama settings for control point detection. I'm guessing this setting will limit the area it looks for CPs to the overlap area of relevant images. Perhaps it would also allow you to decrease the amount of rotational search as well. Together, this might be faster and help you avoid the bending of the strips. Again, this is all theoretical. I don't know what gains it might have for you, if any. With such a big project it makes sense to explore any options that might increase quality, speed, efficiency, etc. at the beginning as it may have a big positive impact in the meat of the project. Is this helpful? 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.
[hugin-ptx] Re: [remote sensing] Use of Hugin to stitch thermal imagery (methods + results)
I see in your script stuff (which as I have said, I don't completely understand,) that you are using the --multirow switch. So maybe you are already getting the best performance you can and my suggestion is redundant. 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.
[hugin-ptx] Re: [remote sensing] Use of Hugin to stitch thermal imagery (methods + results)
Oh so that first (cyan tinted) image is a gap between two individual images? I thought it was on a larger scale gap on a multi image mosaic. I was thinking it might be from an errant mask, Hugin bug, or some other esoteric problem. What scale is this thing at? How large an area does each image and the finished mosaic cover? Is there a curved surface to flat surface mapping problem that is cropping up because of the scale of the mosaic? Please excuse me if this is stupid. Just offering my thoughts. :-) Can 2 points on each image be tied to a specific latitude (or any theoretical straight line on the base map) if so they could be designated as line control points. Obviously you want a line that is along the axis of the plane track (it goes through all the images in a row or strip.) Even better if that line lies within the overlap with the next line of images. Perhaps this is the same thought Terry suggested earlier with the GIS software which you abandoned? Sorry if this is useless or redundant. John On Friday, January 25, 2013 10:58:40 AM UTC-6, Julien Schroder wrote: It could be perfect indeed, but I have no idea how to do that with Hugin. It might as well fix the first problem which appear I suspect when I try to straight the stripes. I have the Gps tracks but I don't know how to use them in Hugin Thanks for your comment -- -- 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: [remote sensing] Use of Hugin to stitch thermal imagery (methods + results)
How are the full transparency and temperature images related. [Sorry if this is obvious from the nona script, but I don's speak nona :-) ] It appears the full transparency shows a conventional image mosaic with the temperature image (presumably your temperature mosaic image?) as a semi-transparent layer over it. Is this to check alignment? Then the temperature image (the second image) is the same, but with the temperature layer fully opaque? It looks like the lines of images are rather erratic. Because of this I assume the airplane was rolling along it's axis as it flew, and in some cases was directed slightly off it's axis because of sidewinds (or possibly the camera was not aligned with the aircraft.) Is this typical with arial imagry? [Sorry no remote sensing experience] Also there are lots of gaps between each strip (actually it looks like groups of 2 or sometimes 3 strips overlap, then there's a gap between it and the next set of overlapping strips.) Is it common that the coverage would be so erratic? Presumably, each thermal image has no real time data associated with it (i.e. location, heading, altitude, and attitude of the camera, distance to ground, etc.?) I have no idea if this is normally done, but it seems like it would be an obvious thing to do if the images were taken within the last 10 years or so. If this data were available (and machine readable) one could easily create a script that would calculate a very good initial arrangement of the images before even using nona (especially since this appears to be a very flat landscape [the meandering streams.]) This would take care of 90% of the work without even having to open the images. Clearly this makes too much sense to actually happen in our imperfect world! :-) 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
[hugin-ptx] Re: How to calibrate fisheye lens image effectively?
I guess you mean this page: http://wiki.panotools.org/Lens_correction_model I'm not so good with all the formulas etc., so I can's really help you there. But I can tell you that you don't really need to know the formulas to get your lens calibrated. Most of lens calibration in Hugin is pretty automatic now. I suggest you look particularly at these sections on the page above: Determine lens correction and Optimize for lens correction no formulae involved. ;-) Also be aware that once you get a result that you are satisfied with, you can save the lens parameters to a folder (keep a file for every lens you have so you can start with that the next time.) Seeing your images might help to know what is happening. On Wednesday, January 23, 2013 1:47:27 PM UTC-6, Linda Li wrote: Tutorial Lens correction model gives out a model: r_src = a * r_dest^4 + b * r_dest ^3 + c * r_dest ^2 + d * r_dest The tutorial writes: The radial lens distortion parameters are used the same way for rectilinear lenses and fisheye lenses, but they should never be used to attempt to remap a fisheye to a rectinlinear image. this is done by selecting the proper source an destination projection. Fisheye geometry follows a rapidly-changing trigonometirc function which can hardly be approximated by a third degree polynomial. (1) If I use straight line control points, in the Optimizer tab, what parameters should I choose? I do not think a, b, c, with the meaning in the formula above, should be used. I guess Hugin uses a, b, c for different meaning, since For fisheyes, the lens correction parameters correct for the deviation between a real lens and the ideal fisheye geometry. What parameters are used then? (2) I assume I need to use the parameter in the Optimizer: a, b, c, d, e Since the control points are straight lines, not horizontal and vertical ones, I do not think I need image orientation parameters (y, p, r, X, Y, Z) The result is copied below: Optimizer run finished. Results: average control point distance: 5.195259 standard deviation: 4.647658 maximum: 14.533787 I output it as Equirectangular, and view it in PanoramaViewer; the result is much worse than the result I directly guess the horizontal FOV and output it as Equirectangular. I think just stitching two photos together like this: http://hugin.sourceforge.net/tutorials/two-photos/en.shtml will give you a decent calibration for your purposes. Why stitched photos are better for calibration? I think it induces extra errors from stitching. Especially for fisheye lens, it is hard to stitch two photos very well. My impression was that it was a full frame fisheye lens (which isn't that hard to stitch) but you can use any of the techniques suggested in the Determine Lens Correction section. I like it because you don't have to use any line control points. You can also use the calibrate_lens_gui application to get a very quick result (it should be in your Hugin download file.) Really, it's all good. :-) John On Monday, January 21, 2013 7:32:30 PM UTC-6, JohnPW wrote: I'm answering things I don't really know about for sure, but . . . I think your best bet is method 2. When you use the lens, take some extra images (from the same position) to the left and right (or up and down) so that you calibrate the lens for each use. You'll get a better and more accurate calibration this way and it should be good for any pictures you take in that session (as long as the lens isn't moved along the way.) When you have done this once or twice, you will have a good idea of the lens parameters, and you can try just plugging those in. If just plugging in a guess (or a lens file you have saved for that lens) doesn't give you results you like, you may want to *always* do the extra shots. depends on your results and standards. I think just stitching two photos together like this: http://hugin.sourceforge.net/tutorials/two-photos/en.shtml will give you a decent calibration for your purposes. John On Monday, January 21, 2013 6:23:51 PM UTC-6, Linda Li wrote: I have cellphone fisheye lens. There are no focal length or other parameters available on the lable. The horizontal and vertical FOV can only be estimated, since a truncated view (like a barrel) is presented on the camera preview. Now I want to convert the fisheye image to a rectilinear image. I tried two ways: (Method a) First way: estimate the HFOV, and see the converted rectilinear image is desired or not. If not, try another HFOV. (Method b) Second way: use control points to label the straight lines, horizontal lines and vertical lines. In the Optimizer tab, I am not sure which option to choose. I tried several (including Custom parameters option), the optimization results in terms of average control point distance were all not good (I guess that is due to great distortion
[hugin-ptx] Re: Should we optimize the parameter view (v) in the persepctive correction?
It probably just derives v from the EXIF data. BTW, I suspect that these methods don't do much to correct b anyway (but I could be wrong.) John On Wednesday, January 23, 2013 1:38:15 PM UTC-6, Linda Li wrote: The tutoiral Hugin tutorial — Simulating an architectural projection does not include v in the optimization. http://hugin.sourceforge.net/tutorials/architectural/en.shtml While the tutoiral Hugin tutorial — Perspective correction includes v in the optmization. http://hugin.sourceforge.net/tutorials/perspective/en.shtml But in my opinion (it might be wrong), the two tutorials have the same goal. Why is there difference in inclusion of optimization parameters? -- 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: Enfuse: Trying to use input masks to increase DR (with test files)
Ken, I guess I'm not clear on this. There are many things that seems strange about your experiment and the results, but I'm not sure which one is the one that is bothering you. For instance, There is the way masks behave in your experiment (personally this is the what surprises me.) The fact that some areas of your image are not active in either mask. The way the weighting behaves. Your basic thought that no matter what I do, the shadows are always slightly darker than the lighter scan, and the highlights always slightly lighter than the darker scan. (Why does this seem odd to you? Is it that the difference is so slight and should be more?) For clarity, exactly what result did you expect, and exactly what result do you feel you got? -- 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: How do they stitch this pano video from 3 cameras?
There are folks who have been working on video stitching SW for a while. Basically panotools for video. More than one active project out there. Sorry I don't have a link, but I'm sure these projects have been mentioned in this forum somewhere before. On Tuesday, January 22, 2013 2:41:48 PM UTC-6, Jan Martin wrote: Hi all, I am wondering how they stitch this? Rig with 3 cameras: http://www.geonaute360.com Panoramic Video: http://www.wesphere.com/swf/embed.php?id=video_007 Anyone got a clue? 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
[hugin-ptx] Re: Understanding Hugin circular fisheye's FOV value.
I imagine that the HFOV is probably larger than you expect because it represents (I think) the theoretical HFOV of the whole image area (frame to frame) not just the FOV of the image circle. I think this is done because it's more about the input image file than the lens that was used. In other words, these numbers are more about telling hugin/panoTools how to handle the imput image file rather than to tell anyone about the lens. John On Monday, January 21, 2013 5:07:13 PM UTC-6, Erik Krause wrote: Am 21.01.2013 11:38, schrieb PrunkDump: On the Hugin tab if I set focal length = 8.0; multiplier = 1.0; Hugin give me a*FOV* = 257.83101. So a half FOV of*HFOV* = 128.915505. This seems wrong. A 8mm circular fisheye never has 257� FoV. The widest fisheye has 220� FoV. The Sigma 8mm has more or less 180�. Hugin doesn't seem to get this right, since all but rectilinear input lens type give the same result... -- Erik Krause http://www.erik-krause.de -- 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: Enfuse: Trying to use input masks to increase DR (with test files)
I can't specifically help you because I'm a moron when it comes to CLI and scripting (so I can't really tell what you are telling enfuse to do.) I am following you theoretically though. Test 1a-b is to test how the masking works (all as expected.) Test 1c-d trying to see how it handles the 1/2 1/2 masks (should make an image darker on one side and lighter on the other, but doesn't.) Test 2 more like previous, but similarly confusing results. Test 3 like previous, but more realistic masks (results finally look more like you expect, but still disappointed with results.) So the basic question is why doesn't it work like you think it should (this is where I can't help you because I'm ignorant of the CLI and scripting stuff.) Here I'm assuming that it probably should work for you, since the first (most simple) and last (most realistic tests seemed to work for you.) All, I can tell you (from my ignorance :-) ) is that there are lots of flags, options, etc. that are faily esoteric, and this may be the reason things aren't working. Also yo say, the shadows are still darker than the lighter scan. The highlights are still lighter than the darker scan. I'm not sure this is surprising because: Although the enfuse default weightings will favor well exposed pixels, I think it will also tend to keep blackest blacks, black and whitest whites, white. So although information will be added to the highlights, they will still be highlights (and visa versa.) In other words, many of the highlights are underexposed in the darker scan, and many of the shadows are overexposed in the lighter scan (assuming chrome slides.) The fused image should look better overall though because it will have greater DR from blackest black to whitest white, and enhanced contrast (even if these areas *seem* less contrasty. If you don't like the effect after fusion you should fiddle with the weighting and other options. PS I have found that few flatbed scanners have the capability with their exposure settings to enable you to really pull the detail out of the dense parts of film, chrome or negative (but mane the new scanners are better?) On Monday, January 21, 2013 3:10:44 PM UTC-6, KenC wrote: Files available on dropbox: https://www.dropbox.com/sh/s919l1up6evu7p6/Ky28yJXGOJ?lst I've been using enfuse for a while trying to maximise dynamic range from 35mm slide scans. I usually do an exposure weighted fusion of 2 scans from the same slide, one exposed for shadows, and the other for highlights. I'm always trying to improve my results, and have noticed that, no matter what I do, the shadows are always slightly darker than the lighter scan, and the highlights always slightly lighter than the darker scan. I always put this down to having to use the Gaussian distributon to describe the exposure weighting. With the recent introduction of the option to use input masks, I had another go at looking a this. Test 1a: (lighter scan + white mask) fused with (darker scan + black mask) = lighter scan Test 1b: (lighter scan + black mask) fused with (darker scan + white mask) = darker scan Both as expected Test 1c: (lighter scan + half white/half black mask) fused with (darker scan + half black/half white mask) = lighter scan Test 1d: (lighter scan + half black/half white mask) fused with (darker scan + half white/half black mask) = darker scan Expected there to be some combination of the lighter and darker scans here. Confused. Test 2: (lighter scan + mostly black with white box mask) fused with (darker scan + inverse mask) = Mostly darker scan with complete area to the right of the box in the mask from the lighter scan Expected mostly darker scan with lighter scan area confined to mask box. See test2_fused_result.tif Test 3; (lighter scan + custom mask1) fused with (darker scan + custom mask2) = Attempt to more seriously combine best of both scans. Does produce a reasonable fused result, but the shadows are still darker than the lighter scan. The highlights are still lighter than the darker scan. See test3_fused_result.tif Can anyone provide any insight into why the simpler tests produce these results? With test 3, even with custom selection of the required parts of the input scans, it still doesn't seem possible to improve on the results produced using the gaussian exposure weighting function. Is there an inherent reason in the algorithm for this. My understanding of what happens after the weight assignment is minimal. Thanks Ken -- 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
[hugin-ptx] Re: How to calibrate fisheye lens image effectively?
I'm answering things I don't really know about for sure, but . . . I think your best bet is method 2. When you use the lens, take some extra images (from the same position) to the left and right (or up and down) so that you calibrate the lens for each use. You'll get a better and more accurate calibration this way and it should be good for any pictures you take in that session (as long as the lens isn't moved along the way.) When you have done this once or twice, you will have a good idea of the lens parameters, and you can try just plugging those in. If just plugging in a guess (or a lens file you have saved for that lens) doesn't give you results you like, you may want to *always* do the extra shots. depends on your results and standards. I think just stitching two photos together like this: http://hugin.sourceforge.net/tutorials/two-photos/en.shtml will give you a decent calibration for your purposes. John On Monday, January 21, 2013 6:23:51 PM UTC-6, Linda Li wrote: I have cellphone fisheye lens. There are no focal length or other parameters available on the lable. The horizontal and vertical FOV can only be estimated, since a truncated view (like a barrel) is presented on the camera preview. Now I want to convert the fisheye image to a rectilinear image. I tried two ways: (Method a) First way: estimate the HFOV, and see the converted rectilinear image is desired or not. If not, try another HFOV. (Method b) Second way: use control points to label the straight lines, horizontal lines and vertical lines. In the Optimizer tab, I am not sure which option to choose. I tried several (including Custom parameters option), the optimization results in terms of average control point distance were all not good (I guess that is due to great distortion especially at the borders). And the transformed images are not good. Maybe the transformation is over-fitting. Is there any suggestion about it? Plus, I think I also need to consider translation parameters in it, since the interface of the fisheye lens is not exactly the centre to the cellphone camera circle. Thanks in advance. -- 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: How to calibrate fisheye lens image effectively?
PS I don't think that's so much image translation as image center shift (d e.) On Monday, January 21, 2013 6:23:51 PM UTC-6, Linda Li wrote: Plus, I think I also need to consider translation parameters in it, since the interface of the fisheye lens is not exactly the centre to the cellphone camera circle. Thanks in advance. -- 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: Enfuse: Trying to use input masks to increase DR (with test files)
That is *maybe* the new scanners are better? On Monday, January 21, 2013 7:17:14 PM UTC-6, JohnPW wrote: PS I have found that few flatbed scanners have the capability with their exposure settings to enable you to really pull the detail out of the dense parts of film, chrome or negative (but mane the new scanners are better?) -- 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: Enfuse: Trying to use input masks to increase DR (with test files)
Yeah, I've messed around with your scan files a bit and (aside from the issue of how infuse works with masks) I think it's a pretty darn well exposed chrome. You had to expose for the highlights and did a darn good job of it. Given that you're at in thin air, shooting into shadow and sun, and using chrome, aside from using more filtration to help you compress the DR of the scene, I'm not sure you could have done better. It seems to me you are just running into the limitations of the chrome film and the scanner. Scanning RAW and multisampling might help (if you didn't do that, ViewScan is nice Software.) Nice image! Where is it? -- 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 stacks pictures to one stack, not 360 degrees as I want
How do the control points look? Look in the quick preview window and check show control points. It's hard to know what's happening without more information. You should probably post the PTO file. John On Saturday, January 19, 2013 4:18:42 AM UTC-6, moonki...@hotmail.com wrote: So, my problem is kinda weird. It doesn't do it on all panoramas I try to make.. Only to those, that have large room or space to stitch up. Getting smaller (more detail-rich) panoramas is kinda child's play but I cannot stitch big rooms together at all. Here is one example: http://filesmelt.com/dl/panorama4.jpg This panorama is made out of 6 pictures. Four that circle the room, floor and ceiling pictures. Room itself is shaped as half-circle. Problems come with floor and ceiling pictures. Here is one that I made with 4 pictures, leaving ceiling and floor pictures away: http://filesmelt.com/dl/panorama12.jpg It looks nice, but there is huge blank spaces at ceiling and floor when we try to make it a ball for viewing. So the panorama is cylindrical. What to do to fix this problem? -- 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: Enfuse: Trying to use input masks to increase DR
Try to get those files up so we have something to comment on :-) -- 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: Fisheye lens do not present circular projection on my cellphone
I have no experience with fisheye lenses, but . . . A) Indeed, they *are* designed this way. Fisheye lenses are either circular (a full 180º circular projection) or full frame (where the image circle is enlarged [and effectively cropped] to fill the full image area.) This is generally what most people want [except for us Hugin users, who pursue that very wide angle!]) B) I don't know for certain, but I highly doubt there is any way to make a full frame lens produce a circular effect (although going the other way is easy—just crop.) C) Not familiar with your lenses, but if they are cellphone add ons, you will probably have to use different de-skewing calculations each time you use them (I doubt they fit on the phone in a consistently reproducible way.) D) If I'm wrong on any of this, I'm sure someone will soon correct me very soon. ;-) John On Thursday, January 17, 2013 6:33:34 PM UTC-6, Linda Li wrote: I have three fisheye lens (two from SKINA digital technology Co., one from pixeet). After anyone of them is attached to my phone (sprint HTC), I am disappointed to find that it presents a fullframe projection, rather than circular projection. Apparently fullframe projection has a less wide angle view than circular projection. First I thought the lens are for fullframe projections. But after observation, I find the circle of the fisheeye lens is larger than the circle of the camera hole. How can I get a circular projection using these fisheye lens? Or are they designed this way? -- 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: Show and Tell - Operation StratoSphere
BTW, I like the smoke ring that is produced when the balloon explodes. -- 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: Show and Tell - Operation StratoSphere
Cool! Very nice! This sort of thing really was hard to imagine only a few years ago (few for someone of my age anyway.) Even a large government organization in an affluent world power would have been boggled. Now, a few decades later, with some amazing technological advances, an individual with know how, ambition, sweat, and the cumulative work product of many OSSW authors can harness these tools to do such amazing things. And many things like this are happening. Give me a long enough lever and a place to stand . . . On Thursday, January 17, 2013 2:18:24 PM UTC-6, Caleb Anderson wrote: I just finished my project that I was calling Operation StratoSphere. The goal was to get 360x180 degree images and video from ~100,000 feet. I'm happy to report that I was successful and would love to share the results with this group. http://robotrising.org/2013/01/operation-stratosphere-conclusion/ Thanks for checking it out! Caleb -- 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] CHDK
Bugbear, So you're a nerd in multiple realms! ;-)It seems that there are are certain subjects that universally inspire fascination by people of a nerdish predilection. I too have been fascinated by tool sharpening. Nice results on the focus stacking. I just discovered that the old Cannon PS S400, which I got for free, cannot be hacked by DHDK. Bummer. But now I can maintain a clear conscience when I buy a new (used) Cannon PS to play with :-) John PS Magic Lantern does some great tricks for the Cannon DSLRs. Check out this focus stack: http://www.flickr.com/photos/davedehetre/6493895227/ On Monday, January 14, 2013 4:39:39 AM UTC-6, bugbear wrote: JohnPW wrote: It sounds like it works as advertised, but doesn't alleviate the usability curse of PS's � the lack of physical controls makes the UI a deep nest of menus and a bottle neck for changing things. Still, the features you point out, plus being able to use a script to bracket and, most of all, getting RAW file output from a camera that doesn't (normally) have RAW file capability, that sounds pretty good. I used a CHDK script to implement *focus* bracketing (eat your heart out, DSLR users) and got this proof of concept shot: http://www.photomacrography.net/forum/viewtopic.php?t=9473highlight= BugBear -- 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] CHDK
RAW is essentially unprocessed sensor data, right? And DNG is Adobe's all purpose, standard file format designed to convey raw data for any camera. Isn't that so? It seems like any SW written to read a DNG should be able to open any DNG without a problem. Why then, do they always distribute RAW updates for image SW? It seems like the file should be able to convey whatever needs to be known about it's unique sensor information without intervention. -- 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] CHDK
Anybody use CHDK? How do you like it? What is your experience with it? I was thinking of buying a little used Cannon ELPH and loading this on it to use as an inexpensive pocketable camera that can be used for snapshots or bracketed images enfused images and/or panos. From my search, it seems there is little mention of it here, which surprised me. Thanks, 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
Re: [hugin-ptx] CHDK
It sounds like it works as advertised, but doesn't alleviate the usability curse of PS's — the lack of physical controls makes the UI a deep nest of menus and a bottle neck for changing things. Still, the features you point out, plus being able to use a script to bracket and, most of all, getting RAW file output from a camera that doesn't (normally) have RAW file capability, that sounds pretty good. On Saturday, January 12, 2013 6:23:03 PM UTC-6, Frederic Da Vitoria wrote: I use it on my S5IS. I have a feeling that it reduces battery life, although they swear it doesn't and it is true I don't really see why it would. It is also so rich that I refrain from using the possibilities because it takes so much time exploring the menus to find what is there. But there are a few features which I really like so that I keep it, especially the zebra mode, and the ability to chose what information is displayed on the screen. Also, it is easy to revert back to the Canon standard ROM : just switch the SD lock and voilà! I don't use it for bracketing simply because my S5IS already has it in the standard menus, but there are special bracketing modes which I never use: focus bracketing and ISO bracketing. Now that I think of it, I should use ISO bracketing sometimes... This is just an illustration of the main problem with CHDK: so many features that you easily miss interesting ones. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] CHDK
I suppose for not much more money, I could get a used S5IS instead of a used 1200 IS giving up the pocketability for a nicer little camera. On Saturday, January 12, 2013 7:23:36 PM UTC-6, Frederic Da Vitoria wrote: Ah, yes raw. Don't expect too much of it. First of all, at least last time I checked, it's raw raw, I mean raw without any iptc data, which limits usage a lot. Also, raw saving is slwww. It is often slower than jpg, but I had a S30 which offered raw natively, and I don't remember it being so much slower. But I tested raw only a few years back, and of course on my S5IS, things could be better for you. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org/ Le 13 janv. 2013 01:42, JohnPW johnpw...@gmail.com javascript: a écrit : It sounds like it works as advertised, but doesn't alleviate the usability curse of PS's — the lack of physical controls makes the UI a deep nest of menus and a bottle neck for changing things. Still, the features you point out, plus being able to use a script to bracket and, most of all, getting RAW file output from a camera that doesn't (normally) have RAW file capability, that sounds pretty good. On Saturday, January 12, 2013 6:23:03 PM UTC-6, Frederic Da Vitoria wrote: I use it on my S5IS. I have a feeling that it reduces battery life, although they swear it doesn't and it is true I don't really see why it would. It is also so rich that I refrain from using the possibilities because it takes so much time exploring the menus to find what is there. But there are a few features which I really like so that I keep it, especially the zebra mode, and the ability to chose what information is displayed on the screen. Also, it is easy to revert back to the Canon standard ROM : just switch the SD lock and voilà! I don't use it for bracketing simply because my S5IS already has it in the standard menus, but there are special bracketing modes which I never use: focus bracketing and ISO bracketing. Now that I think of it, I should use ISO bracketing sometimes... This is just an illustration of the main problem with CHDK: so many features that you easily miss interesting ones. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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 hugi...@googlegroups.comjavascript: To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com javascript: 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] Adobe Photoshop CS2 download for free
Well that makes sense. Tempts me build a Windows computer! John On Friday, January 11, 2013 1:44:33 AM UTC-6, David Haberthür wrote: On 10.01.2013, at 02:03, Greg 'groggy' Lehey groo...@gmail.comjavascript: wrote: On Wednesday, 9 January 2013 at 9:15:21 -1000, Gnome Nomad wrote: A friend mentioned this. Perhaps of interest to people who're interested in a very capable tool that has possibly some limited usage in making panoramas. For PowerPC Mac or Windows 2000 and XP. http://www.adobe.com/downloads/cs2_downloads/index.html There's been some discussion about whether this is legal or not. One Adobe employee says it's only for existing customers. But there's nothing on that page to say so. I've discussed this in my diary at http://www.lemis.com/grog/diary-jan2013.php#D-20130109-003648 Comments welcome. Here's a bit of background: http://arstechnica.com/information-technology/2013/01/adobe-almost-does-something-amazing-by-accident/ Habi -- 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] Adobe Photoshop CS2 download for free
I'm sure it's legal. Why else would they offer it? I see no context for the page, so I don't know what they intend. But let's face it, it's CS2 which is so long in the tooth it's nearly dead. And on the Mac, it's PPC only. (Hard to remember, but I think I had it working on my intel MBP for a time, but I'm pretty sure it was DOA by Snow Leopard. Although I did a lot of good work on it, CS2 wasn't even that great when it was new (at least on the Mac.) It had a number of persistent bugs. CS 2 is from the time when Adobe was not just dragging their feet on Mac software, they were positively hostile toward the Mac. People with an old computer can download CS2 and get hooked. Then when they upgrade their computer, Adobe can get their taste ;-) Seriously though, if you have a computer that runs it, it's pretty good software. ohn On Wednesday, January 9, 2013 7:03:52 PM UTC-6, Groogle wrote: On Wednesday, 9 January 2013 at 9:15:21 -1000, Gnome Nomad wrote: A friend mentioned this. Perhaps of interest to people who're interested in a very capable tool that has possibly some limited usage in making panoramas. For PowerPC Mac or Windows 2000 and XP. http://www.adobe.com/downloads/cs2_downloads/index.html There's been some discussion about whether this is legal or not. One Adobe employee says it's only for existing customers. But there's nothing on that page to say so. I've discussed this in my diary at http://www.lemis.com/grog/diary-jan2013.php#D-20130109-003648 Comments welcome. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -- 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: rapperry pi and hugin possible ?
Cool! I didn't know about Raspberry Pi. I am reeling with ideas of cool things that could be done with it. Seems like it would have plenty of power for Hugin. The CPU has about the same power as a 300Mhz Pentium II. It may not handle big projects and it'll run slow, but it should work fine. -- 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 - Faux Exposure Brackets - enfuse
Sorry, I forgot to remove the first 2 pages before posting. -- 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 - Faux Exposure Brackets - enfuse
And always more information shows up after I post. It looks like this formula improvement may have been made some years ago. I'm not sure what improvement it is they have planned for v7. I suppose the documentation where they use the faulty formula as an example could be updated ;-) -- 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: Mapping camera parameters to hugin - pto files
That sounds like an excellent approach — like substituting for 'x' in algebra! What limits it to being useful only to the one photo? (I'm unable follow the formulas in memec's link without explanation, but maybe with a hint I can figure it out.) John On Wednesday, December 19, 2012 5:12:13 PM UTC-6, Bruno Postle wrote: On Tue 18-Dec-2012 at 17:25 -0800, memecs wrote: I am referring to the parameters listed here: http://docs.opencv.org/modules/calib3d/doc/camera_calibration_and_3d_reconstruction.html does anyone know how to map the camera parameters K: [f 0 px; 0 f py; 0 0 1] to a hugin pto file? If you only need to do this once, then you can cheat by loading a before and after photo mapped with the opencv parameters. Then in Hugin set control points, and optimise a,b,c parameters for just the remapped photo. -- 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: Questions re calibrating lens for Lensfun
I found the lensfun explanation and documentation regarding use and contribution to the database insufficient to do either (but I'm a failed geek.) As far as the data, the procedure they lay out is very thorough an much better explained. Presumably more samples lead to a better result (if the technique of the measurer is sound.) How much better? I have no idea. The variety of results people get (as you found) makes me wonder if the variance is in the lenses, the procedure, the skills of the contributors, the motivation of the contributors, or something else I haven't considered. :-) On Wednesday, December 19, 2012 9:48:27 PM UTC-6, Tduell wrote: Hello All, I have a new camera and lens (Pentax K30-Sigma 18-200), and have been testing a few things. I find that Lensfun has two entries for this lens, I guess from different contributors. If I do a stitch without using lensfun calibration, I get a max. error of 2.8 pix. If I stitch using lensfun lens A, I get a max. error of 2.6 pix. With lensfun lens B, I get a max. error of 3.75 pix. I guess the errors are reasonable in all cases, but would one expect that sort of variation between lenses, assuming the calibration has been done properly? Following on the above results, I thought it might be enlightening to do my my own lensfun calibration for this lens. Reading the tutorial, the vignetting calibration looks a bit 'serious'... for each focal length for each aperture for each distance As I probably have about 7 focal lengths for this lens, and ?? apertures, the cases start to mount up. Is it really necessary to cover so many cases, or can hugin get by with a smaller sample? Finally, what units is 'distance' in the lensfun database...I can't find a definition anywhere. I assume it is metres, but that could be wrong. Cheers, -- Regards, Terry Duell -- 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: Visualize seam
Can anyone tell me if doing as I described below (entering --visualize in the Enblend options box in Hugin) *should* make this option work properly? Thanks John On Monday, December 17, 2012 2:43:11 PM UTC-6, JohnPW wrote: I was interested to see the visualize output, but it didn't quite work for me. I put --visualize in the Enblend options box in Hugin (shouldn't that work?) I always get this error: enblend: info: loading next image: Antietam House 5Z.tif 1/1 enblend: info: loading next image: Antietam House 5Z0001.tif 1/1 enblend: error: OJPEG encoding not supported; use new-style JPEG compression instead terminate called after throwing an instance of 'vigra::Encoder::TIFFCompressionException' gnumake: *** [Antietam House 5Z.tif] Abort trap: 6 gnumake: *** Deleting file `Antietam House 5Z.tif' All images are tiffs and I have no idea what OJPEG or JPEG might refer to. Is this the result of some now deprecated default setting in enblend? John On Saturday, December 15, 2012 8:43:56 AM UTC-6, cspiel wrote: Edo, Am Samstag, 15. Dezember 2012 10:53:24 UTC+1 schrieb Edo: After stitching It is not easy to find them without knowing where the seams are. How do you solve this issue? Read the Enblend manual about the following options: `--fine-mask', `--optimize', and in particular `--visualize'. Together they might take you close to where you want to get. /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
Re: [hugin-ptx] Re: Hugin - Faux Exposure Brackets - enfuse
I'm glad this is stimulating discussion. This is the kind of thing I enjoy reading here (especially when somebody can explain things they know.) Anyway, I'd like to figure out some things about sigmoidal contrast. Is a sigmoidal contrast simply an approach to setting the contrast curve we all know from photography and digital imaging? In other words, is it a subset of possible contrast curves that could be uses which follow a sigmoidal shape as described in the formula? From what I can understand, this means it is a typical contrast curve but: • with the endpoints locked down at blackest black and and whitest white • with a single inflection point somewhere in the middle • and a sigmoidal (s) shape between perfectly straight and infinitely steep (essentially a step function) • presumably this function always has a positive slope and the 's' shape is never inverted into a backward 's' shape. Are my assumptions correct? On Wednesday, December 19, 2012 5:09:02 PM UTC-6, Bruno Postle wrote: On Wed 19-Dec-2012 at 12:13 +0100, Frederic Da Vitoria wrote: But now that I think of it more closely, I understand that JohnPW's question is still unanswered and that my answers completely missed the point. I expect the faux-bracketing to keep the lightest parts of the darkest exposure and the darkest parts of the lightest exposure. I'm not entirely sure what you are trying to do, but Hugin will extract 'bracketed' exposures from any photo. By default it uses a 'sigmoidal' camera response curve to map the data to linear space, multiply and then map back again - This curve will be quite accurate if you have calibrated your camera photometric parameters. All you have to do is load your photo and increment Eev for the input or output. You can then enfuse these brackets, but this process only really makes sense if you start with 16bit per channel data created from RAW. -- 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
Re: [hugin-ptx] Re: Hugin - Faux Exposure Brackets - enfuse
Exactly! On Wednesday, December 19, 2012 5:13:57 AM UTC-6, Frederic Da Vitoria wrote: I expect the faux-bracketing to keep the lightest parts of the darkest exposure and the darkest parts of the lightest exposure. If this were true, there should not be any loss in the highlights. Obviously enfuse decided otherwise, but why did he do so and is there any way to make him behave as I expect? I'm expecting this script to increase the amount of information in the image (but really, that seems counter to basic laws of thermodynamics.) It does seem to do that generally, but clearly information is lost in the highlights. Although I don't perceive it, I imagine that information is also lost at the dark extremes as well. My suspicion is that it has to do with the fact that the tips of the sigmoidal curve are locked down on the white and black points and somehow the curve is not acting the way we expect at these extremes. With a real bracketed shot (and with a brackets made from a RAW image) the least exposed image will give you the most usable detail in the highlights. In both cases the curve still has a long tail with a gradual slope that spreads the highlights out. With this script, the end points remain at exactly the same point on every intermediate image (there's nowhere else for them to go.) This forces the extreme tip of the curve to compress severely and the points on the curve nearest the endpoint must necessarily change radically. I'm not sure what the shape of the curve at these extremes would be, but I'm thinking it must have the effect of clipping the highlights instead of spreading them out. If so the same thing happens at the low end. So my guess is, contrary to what I expected, that the extremes get slightly clipped, rather than enhanced, to the benefit of the main part of the image. That's not to say it's bad though. Obviously it the fat part of the image benefits. The same is true when you adjust the contrast curves in the normal way. Effectively you sacrifice less important information at the extremes (or wherever) to emphasize more important information in the middle (or wherever.) -- 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] 2010.0.0 on OSX 10.6.8?
Nice image Carl, On Tuesday, December 18, 2012 1:55:17 AM UTC-6, zarl wrote: Dr. Kurt schrieb am 18.12.12 04:01: I stitched this panorama http://worldwidepanorama.org/wwp_rss/go/n7775 I see you wide angle lens. Were you able to capture the whole boat and occupants in one nadir shot (and no horizon?) Just curious how you approached the problem. In a boat it can be so hard to get a good stitch since the boat is constantly moving relative to everything else. -- 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: Is this just a hopeless scene or can adjusting
That's pretty funny. :-) But it will probably help a great deal! On Tuesday, December 18, 2012 3:08:52 PM UTC-6, Matias Tukiainen wrote: Shooting again tomorrow, fabricated the world's laziest pano head for my tripod from a CD case, two erasers and a lot of duct tape :'D maybe it'll hold out for one use? Should get rid of the distortion problems with that! http://i.imgur.com/daeoH.jpg On Wednesday, December 12, 2012 2:58:29 PM UTC+2, rew wrote: Hi, I have the impression that the table is the most problematic. i.e. when a bad seam might happen on the floorbords it doesn't matter as much. Maybe it's possible to force hugin to use only one (or a select few) image(s) for the table. I have the impresion that it's using too many different table-shots. Roger. On Wed, Dec 12, 2012 at 10:24:04AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: You can also post edit with some advanced image editor to correct them but it can take many hours. Some scenes mainly those without many human lines are easier to stitch and less sensible to parallax. The main reason for that is that in fact the parallax errors are there but you cant see them. Nature sky water sand forests and other things can be easily shoot without a tripod head. The shorter distance also increase the problem. Cheers Carlos E G Carvalho (Cartola) http://cartola.org/360 http://www.panoforum.com.br/ 2012/12/12 Matias Tukiainen matias.t...@gmail.com Thanks for the quick response! Since every other scene besides that one seems to have gone just fine without a proper panoramic head, I guess I'll just have to reshoot that scene and maybe move the table a bit closer to the open cupboard or temporarily remove it from the room alltogether. -matias On Wednesday, December 12, 2012 1:33:54 PM UTC+2, markku...@iki.fiwrote: 12.12.2012 13:09, Matias Tukiainen kirjoitti: Here's the scene in question: http://i.imgur.com/nwM8v.jpg It was shot with a Canon 5DMKIII and a 20-35mm lens using the 20mm focal length and just a regular stative head. Is it possible to somehow make the table and the sheets look nice by control point adjustment or should I go and shoot the scene again, perhaps slightly further from the table so lens distortion doesn't affect it so much? -- ** 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! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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 - Faux Exposure Brackets - enfuse
Are you sure you didn't mix the two up? o1 is the original and o2 is the output. In my opinion the shirt detail in o2 is very clearly blown out compared to o1. BTW, I agree that it's best to compare o1 and o2. I included c100 to show that at least one of the intermediate image isn't blown out at Bugbear wondered. On Tuesday, December 18, 2012 3:37:17 PM UTC-6, Frederic Da Vitoria wrote: Hello JohnPW IMO, you shouldn't compare the highlights between any image and c100: since c100 is the darkest, it will always show more details in the highlights than any other picture. You should always compare with the original. Does o2 do better than à1 in the T shirt? I believe so. -- 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 - Faux Exposure Brackets - enfuse
Sure, in fact I have the camera default set to underexpose by .75 stop (which is probably the only thing you can do if you can't shoot RAW.) But the fact that the detail exist in o1 shows that the detail is lost in the transformation, not because of the camera. On Tuesday, December 18, 2012 4:34:30 PM UTC-6, Frederic Da Vitoria wrote: Yes, you are right, I didn't look closely enough. The details in the T shirt are more immediately visible, but the textures in the lightest zones now seem uniformly white. In my experience, PS cameras have a tendency to over-expose pictures. Maybe choosing picture with a better exposition (that is under-exposed by the camera's standards) would give better results. 2012/12/18 JohnPW johnpw...@gmail.com javascript: Are you sure you didn't mix the two up? o1 is the original and o2 is the output. In my opinion the shirt detail in o2 is very clearly blown out compared to o1. BTW, I agree that it's best to compare o1 and o2. I included c100 to show that at least one of the intermediate image isn't blown out at Bugbear wondered. On Tuesday, December 18, 2012 3:37:17 PM UTC-6, Frederic Da Vitoria wrote: Hello JohnPW IMO, you shouldn't compare the highlights between any image and c100: since c100 is the darkest, it will always show more details in the highlights than any other picture. You should always compare with the original. Does o2 do better than à1 in the T shirt? I believe so. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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 - Faux Exposure Brackets - enfuse
Actually, I was curious how using this script on a high bit depth tiff extracted from a good RAW file would compare with: enfusing 6 tiffs extracted from the same RAW file at 6 different exposure levels. In other words, given RAW and tiff files with similar depth of information how does the sigmoidal contrast setting compare to RAW conversion? Clearly RAW conversion isn't even an option on jpegs. But I'm curious about how similar these two approaches are both theoretically and in actual practice. My understanding of basic concepts of image manipulation is not great, and my initial thought is that the approaches are totally different. (the intermediate files don't look like different exposures in the way actual bracketed shots do.) But after reading what little I found on sigmoidal contrast and considering what little I (think) I know about RAW files, I start to think that the manipulation may not be so different as I initially thought. Perhaps the destinations these two winding roads lead to, are nearer each other than I thought! The main thing I notice with this process is that the highest of the highlights seems to get slightly blown. But is this a result of the strategy itself or just the finer points of it? Perhaps some adjustments might make a difference, say the sigmoidal contrast settings — perhaps the contrast factor needs to be edged down bait? Or maybe the weighting of the enfuse settings should be different from the defaults? Or is it inescapable with this process because of a simple principle of image manipulation theory? Or maybe it's inescapable even with full access to a RAW file? I don't know, I'm just curious. To me it's an ingenious process in any case. :-) If anyone can tell me, or point me to a good resource, I'd love to hear about it. John On Monday, December 17, 2012 4:51:50 AM UTC-6, bugbear wrote: JohnPW wrote: This is very cool (and, amazingly, I've gotten it to work form me.) I'm still trying to figure out how to run the perl script, but I'm happy I at least have the commands working on the command line! Any way, I'm curious, does this script produce essentially the same results as if you output differently exposed tiffs converted from a RAW file, or would that technique offer a slightly better result? I ask out of curiosity (I don't normally have access to a camera that shoots RAW.) RAW should (potentially) have a little more data available than a JPEG, so the results from that should be (slightly) better. BugBear -- 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: 360 video camera on kickstarter
That's pretty cool! Nice job. On Monday, December 17, 2012 2:23:54 AM UTC-6, Naked Robot wrote: maybe this is interesting for the group www.kickstarter.com/projects/1996234044/sphericam-the-easy-360o-video-camera -- 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: Visualize seam
I was interested to see the visualize output, but it didn't quite work for me. I put --visualize in the Enblend options box in Hugin (shouldn't that work?) I always get this error: enblend: info: loading next image: Antietam House 5Z.tif 1/1 enblend: info: loading next image: Antietam House 5Z0001.tif 1/1 enblend: error: OJPEG encoding not supported; use new-style JPEG compression instead terminate called after throwing an instance of 'vigra::Encoder::TIFFCompressionException' gnumake: *** [Antietam House 5Z.tif] Abort trap: 6 gnumake: *** Deleting file `Antietam House 5Z.tif' All images are tiffs and I have no idea what OJPEG or JPEG might refer to. Is this the result of some now deprecated default setting in enblend? John On Saturday, December 15, 2012 8:43:56 AM UTC-6, cspiel wrote: Edo, Am Samstag, 15. Dezember 2012 10:53:24 UTC+1 schrieb Edo: After stitching It is not easy to find them without knowing where the seams are. How do you solve this issue? Read the Enblend manual about the following options: `--fine-mask', `--optimize', and in particular `--visualize'. Together they might take you close to where you want to get. /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] Re: Visualize seam
Hmm . . . Google tells me that this is a problem that some of you (Gnome Nomad, kfj, et al.) have seen and fixed before. A bug that sets the compression incorrectly: As seen Here: http://markmail.org . . .http://markmail.org/message/lrk7pha6grcacjsa#query:+page:1+mid:vnoyw7h5vzkoelu2+state:results Perhaps calling --visualize (Im using 2012.0.0 built by Harry van der Wolf on OS X 1..8.2) brings up a similar coding problem from a similar but different place? John On Monday, December 17, 2012 2:43:11 PM UTC-6, JohnPW wrote: I was interested to see the visualize output, but it didn't quite work for me. I put --visualize in the Enblend options box in Hugin (shouldn't that work?) I always get this error: enblend: info: loading next image: Antietam House 5Z.tif 1/1 enblend: info: loading next image: Antietam House 5Z0001.tif 1/1 enblend: error: OJPEG encoding not supported; use new-style JPEG compression instead terminate called after throwing an instance of 'vigra::Encoder::TIFFCompressionException' gnumake: *** [Antietam House 5Z.tif] Abort trap: 6 gnumake: *** Deleting file `Antietam House 5Z.tif' All images are tiffs and I have no idea what OJPEG or JPEG might refer to. Is this the result of some now deprecated default setting in enblend? John On Saturday, December 15, 2012 8:43:56 AM UTC-6, cspiel wrote: Edo, Am Samstag, 15. Dezember 2012 10:53:24 UTC+1 schrieb Edo: After stitching It is not easy to find them without knowing where the seams are. How do you solve this issue? Read the Enblend manual about the following options: `--fine-mask', `--optimize', and in particular `--visualize'. Together they might take you close to where you want to get. /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
Re: [hugin-ptx] Re: Visualize seam
It looks like Stephan Peter made the fix. But I guess it was a functional error rather than a fatal one as described in that thread. In this case it appears to be the cause of the stoppage. But perhaps there's more behind the stoppage than just this bug. On Monday, December 17, 2012 10:30:44 PM UTC-6, GnomeNomad wrote: My experience with the bug never kept it from finishing a stitch. I didn't fix anything. On 12/17/2012 02:47 PM, JohnPW wrote: Hmm . . . Google tells me that this is a problem that some of you (Gnome Nomad, kfj, et al.) have seen and fixed before. A bug that sets the compression incorrectly: As seen Here: http://markmail.org . . . http://markmail.org/message/lrk7pha6grcacjsa#query:+page:1+mid:vnoyw7h5vzkoelu2+state:results Perhaps calling --visualize (Im using 2012.0.0 built by Harry van der Wolf on OS X 1..8.2) brings up a similar coding problem from a similar but different place? John On Monday, December 17, 2012 2:43:11 PM UTC-6, JohnPW wrote: I was interested to see the visualize output, but it didn't quite work for me. I put --visualize in the Enblend options box in Hugin (shouldn't that work?) I always get this error: enblend: info: loading next image: Antietam House 5Z.tif 1/1 enblend: info: loading next image: Antietam House 5Z0001.tif 1/1 enblend: error: OJPEG encoding not supported; use new-style JPEG compression instead terminate called after throwing an instance of 'vigra::Encoder::TIFFCompressionException' gnumake: *** [Antietam House 5Z.tif] Abort trap: 6 gnumake: *** Deleting file `Antietam House 5Z.tif' All images are tiffs and I have no idea what OJPEG or JPEG might refer to. Is this the result of some now deprecated default setting in enblend? John On Saturday, December 15, 2012 8:43:56 AM UTC-6, cspiel wrote: Edo, Am Samstag, 15. Dezember 2012 10:53:24 UTC+1 schrieb Edo: After stitching It is not easy to find them without knowing where the seams are. How do you solve this issue? Read the Enblend manual about the following options: `--fine-mask', `--optimize', and in particular `--visualize'. Together they might take you close to where you want to get. /Chris -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Yup, I do that too. But again, the bracketing will not work in a burst. I have to press the shutter 3 (or 5) times when auto-bracketing. I mostly bracket only in very static situations. On Wednesday, December 12, 2012 2:31:59 AM UTC-6, GnomeNomad wrote: If you can set your camera to automatically bracket using JPGs, I'd think you'd get good dynamic range results. Or you can do it manually (adjusting the shutter speed). Then you're getting into the area of shooting high-dynamic range images. On 12/11/2012 09:23 AM, JohnPW wrote: Actually, for static situations, I have found that taking 3 or 4 jpeg exposures (maximum quality) and stacking them gives a surprisingly decent result and (with my camera) is quicker and better than a single TIFF. My PS camera takes forever to process a TIFF and they gobble up card space like crazy. Converting the JPEGS to 16b and stacking allows produces an image with higher resolution more dynamic range (obviously nowhere near as good as RAW, but if the camera could shoot RAW, I'd do that instead.) John On Monday, December 10, 2012 10:10:00 PM UTC-6, GnomeNomad wrote: That's how I've done it. Works quite successfully. If you're shooting JPGs, I wouldn't worry about converting them to 16-bit TIFF - JPG doesn't have the color depth for that. Hmm, I think using TIFF isn't onerous at all! On 12/10/2012 01:04 PM, JohnPW wrote: Why not faux-bracket the source images first, then stack and enfuse them before stitching? This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.) I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.) John On Tuesday, November 27, 2012 12:13:21 AM UTC-6, Michael Witten wrote: I've achieved some pleasing results by using `Hugin' to stitch a panorama several times with various Exposure Values, and then passing this faux-bracketed stack through `enfuse' to yield the final, exposure-fused result; this usually pulls out more details, especially in places like a sky that might otherwise be blown out and clipped. Unfortunately for this technique, the choice of seams made by `enblend' occasionally depends on the Exposure Value setting; consequently, various features in the images of the faux-bracketed stack don't align, and thus the final exposure-fused panorama exhibits ghosting and the like. Is there a way to keep `enblend' from choosing alternate seams? Are there better ways to achieve this faux-bracketing? -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Yep, old. It's a Nikon Coolpix 4500. It must be over 12 years old by now. I got it when I did for quick digital images for my work, but I didn't want to spend on a DSLR at the time because they were so expensive and not very mature. I've been slow to get a DSLR,waiting for larger sensors, which are not getting more common. The Cannon 5D Mark II is getting me interested. I set the camera to do no sharpening, saturation, or contrast adjustments and to use minimal compression when processing the jpeg. I have looked at a hack to make the camera put out RAW, but it looked iffy, and Nikon seems to actively block such efforts (hence my interest in Cannon and Magic Lantern software.) John On Wednesday, December 12, 2012 2:29:04 AM UTC-6, GnomeNomad wrote: You have a camera that shoots TIFF? Old camera. My Maxum 7D (several years old) shoots RAW or JPG. It shoots 3 frames per second, regardless of format. RAW is the raw data dump from the CCD and reflects the actual layout of the individual color sensors on the CCD. I think most DSLRs have a RAW format. The RAW format typically isn't processed by anything in camera (many cameras do some processing such as sharpening or noise reduction to the image when making a JPG out of a RAW file). On 12/11/2012 09:32 AM, JohnPW wrote: Just to clarify: The image capture is the onerous part. My old camera (Nikon CP4500) takes forever to capture a TIFF (10-15 seconds between shots) I can capture JPEGs, bracketed or not, in a burst and the resulting files are much smaller than a single TIFF. In post porcessing on the compute,r the TIFFS are not onerous. John On Monday, December 10, 2012 10:10:00 PM UTC-6, GnomeNomad wrote: Hmm, I think using TIFF isn't onerous at all! -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Thanks. I was thinking it might be Image Magic, but I haven't been able to get it to work for me and so am not familiar with it's commands. John On Wednesday, December 12, 2012 3:55:33 AM UTC-6, bugbear wrote: JohnPW wrote: What are you folks doing to faux-bracket your images? With RAW files, obviously you can do all sorts of non-destructive things, but I assume you aren't using RAW files though, or it wouldn't really be all that faux. If you are using conventional files, I assume you are adjusting the curves? Sorry BugBear, I'm not smart enough to be able to read your perl script (other than that you are using something to adjust something and then enfusing the resulting images!) I really need to lear scripting! OK - ignoring the script, here are the external commands issued by the script for a run: proc.pl o1.tif o2.tif convert o1.tif -sigmoidal-contrast 5x0% c000.tif convert o1.tif -sigmoidal-contrast 5x20% c020.tif convert o1.tif -sigmoidal-contrast 5x40% c040.tif convert o1.tif -sigmoidal-contrast 5x60% c060.tif convert o1.tif -sigmoidal-contrast 5x80% c080.tif convert o1.tif -sigmoidal-contrast 5x100% c100.tif enfuse --output=o2.tif c000.tif c020.tif c040.tif c060.tif c080.tif c100.tif I'm assuming people on this list know what enfuse does. I'm using ImageMagick (convert) to make derived files from the original image, with (severaly) skewed image curves, all the way from skewed to the dark (so most of the dynamic range in the output file is expanded from the shadows of the source) to skewed to the dark (ditto, sort of). http://www.imagemagick.org/script/command-line-options.php#sigmoidal-contrast http://en.wikipedia.org/wiki/Sigmoid_function The upshot is a range of image with enhanced contrast in the various intensity ranges of the original image. Enfuse then just picks and merges the best pixels in the usual way. BugBear -- 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: Is this just a hopeless scene or can adjusting
This looks like it was enfused. Enfusing stacks then stitching is helpful (rather than stitching before infusing. If you have abundance of overlapping images, picking the most compatible ones is helpful. Also using the mask feature to steer where the seam is placed or which image to use for an overlap is also very helpful. John On Wednesday, December 12, 2012 6:58:29 AM UTC-6, rew wrote: Hi, I have the impression that the table is the most problematic. i.e. when a bad seam might happen on the floorbords it doesn't matter as much. Maybe it's possible to force hugin to use only one (or a select few) image(s) for the table. I have the impresion that it's using too many different table-shots. Roger. On Wed, Dec 12, 2012 at 10:24:04AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: You can also post edit with some advanced image editor to correct them but it can take many hours. Some scenes mainly those without many human lines are easier to stitch and less sensible to parallax. The main reason for that is that in fact the parallax errors are there but you cant see them. Nature sky water sand forests and other things can be easily shoot without a tripod head. The shorter distance also increase the problem. Cheers Carlos E G Carvalho (Cartola) http://cartola.org/360 http://www.panoforum.com.br/ 2012/12/12 Matias Tukiainen matias.t...@gmail.com javascript: Thanks for the quick response! Since every other scene besides that one seems to have gone just fine without a proper panoramic head, I guess I'll just have to reshoot that scene and maybe move the table a bit closer to the open cupboard or temporarily remove it from the room alltogether. -matias On Wednesday, December 12, 2012 1:33:54 PM UTC+2, markku...@iki.fiwrote: 12.12.2012 13:09, Matias Tukiainen kirjoitti: Here's the scene in question: http://i.imgur.com/nwM8v.jpg It was shot with a Canon 5DMKIII and a 20-35mm lens using the 20mm focal length and just a regular stative head. Is it possible to somehow make the table and the sheets look nice by control point adjustment or should I go and shoot the scene again, perhaps slightly further from the table so lens distortion doesn't affect it so much? -- ** 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! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- 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: Is this just a hopeless scene or can adjusting
In the end though, even the simplest, home made, kludged, pano attachment to move the NPP over the tripod axis will make your life much easier and and give markedly nicer pano images. My photo professor always said that 99% of the time, it's easier to fix problems in the studio, than in the darkroom (or to have to go back and re-shoot.) With digital tools, perhaps it's down to 95% now? I suppose this is the photography equivalent to the Garbage in, garbage out axiom. -- 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 - Faux Exposure Brackets - enfuse
I should say I have not been able to get it to install. But the latest MacPort for it seems to have installed it without a hitch! Now that I have it installed, I can see you call IM with convert. Will be experimenting w/ IM, and your and some other scripts. John On Wednesday, December 12, 2012 11:54:22 AM UTC-6, JohnPW wrote: Thanks. I was thinking it might be Image Magic, but I haven't been able to get it to work for me and so am not familiar with it's commands. 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
Re: [hugin-ptx] Re: Hugin - Faux Exposure Brackets - enfuse
Bugbear, That's cool. Very fast and exiting. Unfortunately I get a warning with each execution. But it does produce the output files: watkins-mbp-admins-macbook-pro:Testy jpwmacbookpro$ convert o1.tif -sigmoidal-contrast 5x100% c100.tif *convert: o1.tif: wrong data type 3 for GainControl; tag ignored. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/824.* Then when it gets to the enfuse command, it can't find enfuse: watkins-mbp-admins-macbook-pro:Testy jpwmacbookpro$ enfuse --output=o2.tif c000.tif c020.tif c040.tif c060.tif c080.tif c100.tif *-bash: enfuse: command not found* I assume this is because there is a problem with my .profile. It looks like a mess to me (fricking MacPorts, I guess.) And yes, I have no real idea of what I'm doing or how to doit and have been unable to get usable help on what I'm doing wrong. I suspect the path to Hugin/Hugintools/ is incorrect. Help from any kind soul would be greatly appreciated. :-) John .profile (which is in ~) contains this text (my additions are in bold): # MacPorts Installer addition on 2012-08-12_at_18:57:16: adding an appropriate PATH variable for use with MacPorts. export PATH=/opt/local/bin:/opt/local/sbin:$PATH # Finished adapting your PATH environment variable for use with MacPorts. ## # Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-11_at_23:28:46 ## # MacPorts Installer addition on 2012-10-11_at_23:28:46: adding an appropriate PATH variable for use with MacPorts. export PATH=/opt/local/bin:/opt/local/sbin:$PATH # Finished adapting your PATH environment variable for use with MacPorts. ## # Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-15_at_13:53:25 ## # MacPorts Installer addition on 2012-10-15_at_13:53:25: adding an appropriate PATH variable for use with MacPorts. *export PATH=/opt/local/bin:/opt/local/sbin:$PATH:/Applications/Hugin/Hugintools* # Finished adapting your PATH environment variable for use with MacPorts. ## # Your previous /Users/jpwmacbookpro/.profile file was backed up as /Users/jpwmacbookpro/.profile.macports-saved_2012-10-15_at_14:33:27 ## # MacPorts Installer addition on 2012-10-15_at_14:33:27: adding an appropriate PATH variable for use with MacPorts. *export PATH=/opt/local/bin:/opt/local/sbin:/Applications/Hugin/HuginTools/:$PATH* # Finished adapting your PATH environment variable for use with MacPorts. On Wednesday, December 12, 2012 3:55:33 AM UTC-6, bugbear wrote: JohnPW wrote: What are you folks doing to faux-bracket your images? With RAW files, obviously you can do all sorts of non-destructive things, but I assume you aren't using RAW files though, or it wouldn't really be all that faux. If you are using conventional files, I assume you are adjusting the curves? Sorry BugBear, I'm not smart enough to be able to read your perl script (other than that you are using something to adjust something and then enfusing the resulting images!) I really need to lear scripting! OK - ignoring the script, here are the external commands issued by the script for a run: proc.pl o1.tif o2.tif convert o1.tif -sigmoidal-contrast 5x0% c000.tif convert o1.tif -sigmoidal-contrast 5x20% c020.tif convert o1.tif -sigmoidal-contrast 5x40% c040.tif convert o1.tif -sigmoidal-contrast 5x60% c060.tif convert o1.tif -sigmoidal-contrast 5x80% c080.tif convert o1.tif -sigmoidal-contrast 5x100% c100.tif enfuse --output=o2.tif c000.tif c020.tif c040.tif c060.tif c080.tif c100.tif I'm assuming people on this list know what enfuse does. I'm using ImageMagick (convert) to make derived files from the original image, with (severaly) skewed image curves, all the way from skewed to the dark (so most of the dynamic range in the output file is expanded from the shadows of the source) to skewed to the dark (ditto, sort of). http://www.imagemagick.org/script/command-line-options.php#sigmoidal-contrast http://en.wikipedia.org/wiki/Sigmoid_function The upshot is a range of image with enhanced contrast in the various intensity ranges of the original image. Enfuse then just picks and merges the best pixels in the usual way. BugBear -- 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 - Faux Exposure Brackets - enfuse
I added a slash and now it works. For any other poor noob, here is text that worked for me: export PATH=/opt/local/bin:/opt/local/sbin:$PATH:/Applications/Hugin/HuginTools/ -- 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 - Faux Exposure Brackets - enfuse
Actually it appears that it was this text that did it: export PATH=/opt/local/bin:/opt/local/sbin:/Applications/Hugin/HuginTools/:$PATH On Wednesday, December 12, 2012 10:21:48 PM UTC-6, JohnPW wrote: I added a slash and now it works. For any other poor noob, here is text that worked for me: export PATH=/opt/local/bin:/opt/local/sbin:$PATH:/Applications/Hugin/HuginTools/ -- 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: Off topic: pyExifToolGUI: a Linux/Mac OS X/Windows gui for exiftool
Thanks for the handy tool, Harry. Worked for me on Mountain Lion (but I didn't give it a real vigorous workout.) 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
Re: [hugin-ptx] Re: Might this idea work? scripting process
OK, I've done that as well with great results I asked because I got the idea you were using unconverted 48 bit files. John On Monday, December 10, 2012 10:20:32 PM UTC-6, GnomeNomad wrote: Yes. My DSLR shoots 48-bit RAW files. I convert them to 16-bit TIFF using RawTherapee. Hugin reads the resulting TIFFs just fine. TIFF is an interesting format, because it's designed to be very flexible. Everything from 2-bit (true BW) on up. A very large selection of compression algorithms (including JPG, IIRC). Layers. 256-bit alpha transparency. All capabilities that I think predate this thing called the Internet ... Anyway, I have no idea what Hugin can read and write. Maybe developers can clue us in? On 12/10/2012 12:40 PM, JohnPW wrote: So GN, (Sorry, I'm not sure I follow) You are using 48b tiffs as source images for Hugin to stitch panoramas? What are the specs for acceptable input and output files for Hugin? I just spent 40 minutes trying to find some kind of Hugin tech spec list and have now given up.( I do understand Hugin uses chain of underlying programs.) Just curious, John On Friday, November 9, 2012 9:26:09 PM UTC-6, GnomeNomad wrote: On 11/09/2012 01:52 AM, dex Otaku wrote: Salut alouest, On Thursday, 8 November 2012 14:01:32 UTC-6, alouest wrote: 'm using a sotware which can export RGB tiff and 32 bit tiff. I can produce panoramic with hugin of the RGB but not of the 32 bit tiff. If I extract both RGB and 32 bit tiff, then I create my panorama from the RGB pictures and save the project file. Would I be able to use all the settings (and control points, basically everything) used before and apply them to my 32 bit tiff that hugin see totally blank? I tried quickly with nona but it crashed. To summary could hugin or another tool could apply the settings from a working panoramic creation into empty tiff (they off course have the exact same extent). Is that crazy or that could work? To my knowledge, Hugin and its included tools only work with TIFF images that: * use 16 bits per colour channel or less [no 32bpc TIFF, no floating point TIFF], * are RGB or RGBA [no CMYK support], * use only a single image layer [no multi-layers TIFF support], * and must be 4GB in file size [a limitation of base-standard TIFF] Yes. I understand there's an effort to come up with a TIFF standard that allows larger sizes. What are you using that creates 32-bit [I assume that's per colour channel] output? HDR images from something? I don't know what the original poster means by it. Windows claims a 32-bit image format, but I think it's actually 8-bit RGB with 8-bit alpha-transparency. Is there a practical reason to maintain that bit depth as far in your processing chain as Hugin? Chances are, even if you're going to be post-processing the images after stitching, 16 bits per channel will be sufficient. I get better color when I stitch using 48-bit TIF (16-bit per channel). I convert them from my camera's 48-bit RAW files. 48-bit is minimal HDR, because 16-bits per channel gives a greater color gamut than can be displayed or printed with existing technology. My suggestion [which is probably your only option with Hugin, Nona, etc.]: reduce the bit depth of the images to 16bpc or less and use those with Hugin. If you require 16 bit per channel image support, you may need to find other tools to use. I know of one Hugin tool that doesn't work with 16-bit per channel images: linefind. Unless that's been fixed in the new release? Cheers, D -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Actually, for static situations, I have found that taking 3 or 4 jpeg exposures (maximum quality) and stacking them gives a surprisingly decent result and (with my camera) is quicker and better than a single TIFF. My PS camera takes forever to process a TIFF and they gobble up card space like crazy. Converting the JPEGS to 16b and stacking allows produces an image with higher resolution more dynamic range (obviously nowhere near as good as RAW, but if the camera could shoot RAW, I'd do that instead.) John On Monday, December 10, 2012 10:10:00 PM UTC-6, GnomeNomad wrote: That's how I've done it. Works quite successfully. If you're shooting JPGs, I wouldn't worry about converting them to 16-bit TIFF - JPG doesn't have the color depth for that. Hmm, I think using TIFF isn't onerous at all! On 12/10/2012 01:04 PM, JohnPW wrote: Why not faux-bracket the source images first, then stack and enfuse them before stitching? This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.) I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.) John On Tuesday, November 27, 2012 12:13:21 AM UTC-6, Michael Witten wrote: I've achieved some pleasing results by using `Hugin' to stitch a panorama several times with various Exposure Values, and then passing this faux-bracketed stack through `enfuse' to yield the final, exposure-fused result; this usually pulls out more details, especially in places like a sky that might otherwise be blown out and clipped. Unfortunately for this technique, the choice of seams made by `enblend' occasionally depends on the Exposure Value setting; consequently, various features in the images of the faux-bracketed stack don't align, and thus the final exposure-fused panorama exhibits ghosting and the like. Is there a way to keep `enblend' from choosing alternate seams? Are there better ways to achieve this faux-bracketing? -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Just to clarify: The image capture is the onerous part. My old camera (Nikon CP4500) takes forever to capture a TIFF (10-15 seconds between shots) I can capture JPEGs, bracketed or not, in a burst and the resulting files are much smaller than a single TIFF. In post porcessing on the compute,r the TIFFS are not onerous. John On Monday, December 10, 2012 10:10:00 PM UTC-6, GnomeNomad wrote: Hmm, I think using TIFF isn't onerous at all! -- 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 - Faux Exposure Brackets - enfuse
What are you folks doing to faux-bracket your images? With RAW files, obviously you can do all sorts of non-destructive things, but I assume you aren't using RAW files though, or it wouldn't really be all that faux. If you are using conventional files, I assume you are adjusting the curves? Sorry BugBear, I'm not smart enough to be able to read your perl script (other than that you are using something to adjust something and then enfusing the resulting images!) I really need to lear scripting! -- 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: Might this idea work? scripting process
So GN, (Sorry, I'm not sure I follow) You are using 48b tiffs as source images for Hugin to stitch panoramas? What are the specs for acceptable input and output files for Hugin? I just spent 40 minutes trying to find some kind of Hugin tech spec list and have now given up.( I do understand Hugin uses chain of underlying programs.) Just curious, John On Friday, November 9, 2012 9:26:09 PM UTC-6, GnomeNomad wrote: On 11/09/2012 01:52 AM, dex Otaku wrote: Salut alouest, On Thursday, 8 November 2012 14:01:32 UTC-6, alouest wrote: 'm using a sotware which can export RGB tiff and 32 bit tiff. I can produce panoramic with hugin of the RGB but not of the 32 bit tiff. If I extract both RGB and 32 bit tiff, then I create my panorama from the RGB pictures and save the project file. Would I be able to use all the settings (and control points, basically everything) used before and apply them to my 32 bit tiff that hugin see totally blank? I tried quickly with nona but it crashed. To summary could hugin or another tool could apply the settings from a working panoramic creation into empty tiff (they off course have the exact same extent). Is that crazy or that could work? To my knowledge, Hugin and its included tools only work with TIFF images that: * use 16 bits per colour channel or less [no 32bpc TIFF, no floating point TIFF], * are RGB or RGBA [no CMYK support], * use only a single image layer [no multi-layers TIFF support], * and must be 4GB in file size [a limitation of base-standard TIFF] Yes. I understand there's an effort to come up with a TIFF standard that allows larger sizes. What are you using that creates 32-bit [I assume that's per colour channel] output? HDR images from something? I don't know what the original poster means by it. Windows claims a 32-bit image format, but I think it's actually 8-bit RGB with 8-bit alpha-transparency. Is there a practical reason to maintain that bit depth as far in your processing chain as Hugin? Chances are, even if you're going to be post-processing the images after stitching, 16 bits per channel will be sufficient. I get better color when I stitch using 48-bit TIF (16-bit per channel). I convert them from my camera's 48-bit RAW files. 48-bit is minimal HDR, because 16-bits per channel gives a greater color gamut than can be displayed or printed with existing technology. My suggestion [which is probably your only option with Hugin, Nona, etc.]: reduce the bit depth of the images to 16bpc or less and use those with Hugin. If you require 16 bit per channel image support, you may need to find other tools to use. I know of one Hugin tool that doesn't work with 16-bit per channel images: linefind. Unless that's been fixed in the new release? Cheers, D -- Gnome Nomad gnome...@gmail.com javascript: wandering the landscape of god http://www.clanjones.org/david/ http://dancing-treefrog.deviantart.com/ http://www.cafepress.com/otherend/ -- 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 - Faux Exposure Brackets - enfuse
Why not faux-bracket the source images first, then stack and enfuse them before stitching? This is similar to making bracketed images from RAW files (eliminates alignment/movement difficulties common to conventional bracketing.) I have to admit, most of my panos are from jpegs shot with cheap point and shoots that don't do RAW (and using TIFF is too onerous.) John On Tuesday, November 27, 2012 12:13:21 AM UTC-6, Michael Witten wrote: I've achieved some pleasing results by using `Hugin' to stitch a panorama several times with various Exposure Values, and then passing this faux-bracketed stack through `enfuse' to yield the final, exposure-fused result; this usually pulls out more details, especially in places like a sky that might otherwise be blown out and clipped. Unfortunately for this technique, the choice of seams made by `enblend' occasionally depends on the Exposure Value setting; consequently, various features in the images of the faux-bracketed stack don't align, and thus the final exposure-fused panorama exhibits ghosting and the like. Is there a way to keep `enblend' from choosing alternate seams? Are there better ways to achieve this faux-bracketing? Thanks, Michael Witten -- 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] determine heading from sun position.
KFJ authored a post on using the sun and Wolfram Alpha to orient panoramas
about 6 months to a year ago. I wasn't able to find it, but I'm sure
someone who knows how to use the features of the site better than me can
find it.
On Monday, November 19, 2012 4:31:51 PM UTC-6, Cartola wrote:
Hmm, I don't know if I got it. Maybe is my bad English. It is able to know
where the north is? Is it? To give the correct direction of the picture?
Well, it is probably very simple to make the same line to linux and mac
(which is a BSD and can handle shell scripts), but the problem is that I
don't know BAT files very well :) so I also didn't get exactly what does
this line do:
for /f %%a in ('exiftool -m -c %%+.4f -d %%d.%%m.%%Y+%%H:%%M:%%S -p
http://www.wolframalpha.com/input/?i=sun+position+$DateTimeOriginal+at+$GPSLatitude+N+$GPSLongitude+E;
%1') do @start %%a
Anyway, nice job!
Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/
2012/11/19 Erik Krause erik@gmx.de javascript:
Hello,
ever had trouble to find correct heading for your panorama? If it is shot
outdoor the sun might give you an exact value.
One or the other might know of the possibility to use wolfram alpha to
calculate the sun position for given GPS coordinates and time. Since
entering all the values manually is too tedious I wrote a small windows
batch file that extracts the relevant data from an image using exiftool,
creates a suitable URL and calls wolfram alpha.
All you need is to install exiftool from
http://www.sno.phy.queensu.ca/**~phil/exiftool/http://www.sno.phy.queensu.ca/%7Ephil/exiftool/
(could well be you have this already, f.e. if you use geosetter)
and the little batch file from
http://erik-krause.de/ttt/#**wolfram%20alpha%20azimuthhttp://erik-krause.de/ttt/#wolfram%20alpha%20azimuth
The downloaded zip contains a readme (both in english and german) with
instructions how to install and use.
Your image must contain valid GPS data and shooting date and time. So you
need to geotag your images before you upload them to 360cities, which is
beneficial anyway, since 360cities will read and use those data. A good
program for that is geosetter.
Sorry, windows only for the time being. Perhaps someone can make a mac or
linux version, too. It's one simple command line for exiftool...
If you have problems, suggestions or bug reports, don't hesitate to
contact me. I'd be curious whether it works for the southern and western
hemisphere as well.
Sorry for crossposting.
--
Erik Krause
http://www.erik-krause.de
--
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_FAQhttp://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.comjavascript:
To unsubscribe from this group, send email to hugin-ptx+...@**
googlegroups.com javascript:
For more options, visit this group at http://groups.google.com/**
group/hugin-ptx 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] determine heading from sun position.
I guess I should have tried harder: https://groups.google.com/d/topic/hugin-ptx/vWRO7SxdFxQ/discussion On Monday, November 19, 2012 5:24:16 PM UTC-6, JohnPW wrote: KFJ authored a post on using the sun and Wolfram Alpha to orient panoramas about 6 months to a year ago. I wasn't able to find it, but I'm sure someone who knows how to use the features of the site better than me can find it. -- 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: determine heading from sun position.
And cool, BTW. If I were smart enough, I'd adapt it to the mac (or Unix. Either way, I'm too ignorant to do it :-) ) On Monday, November 19, 2012 5:33:29 PM UTC-6, Erik Krause wrote: Am 20.11.2012 00:24, schrieb JohnPW: KFJ authored a post on using the sun and Wolfram Alpha to orient panoramas about 6 months to a year ago. I wasn't able to find it, but I'm sure someone who knows how to use the features of the site better than me can find it. It was this one: https://groups.google.com/d/msg/hugin-ptx/vWRO7SxdFxQ/gCDdo3SL0hIJ and it actually led me to experiment with wolfram alpha. Many thanks KFJ! -- Erik Krause http://www.erik-krause.de -- 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] Use of Hugin in remote sensing
I'd be interested in seeing some of your work product when you finish. I'm just curious to see what some of the original temp mosaic image files and the stitched results look like. :-) John On Sunday, November 11, 2012 4:44:01 PM UTC-6, alouest wrote: Ok that works, thanks! I keep having some errors though. enblend : warning some images are redundant and will not be blended, I checked on arcgis, the information is still here so i don't know what wrong this time Le samedi 10 novembre 2012 08:55:33 UTC-9, Bruno Postle a écrit : On Nov 10, 2012 12:54 AM, alouest julien@gmail.com wrote: Almost done! i process this on about 5000 pictures, is there a way to do enblend -o temp.tif temp.tif temp0001.tif temp0002.tif without writing all the files one by one? Something like a mask would be great like enblend -o temp.tif temp000* This depends on your shell. You are on Windows, so you should be able to use globbing like this: enblend -o out.tif temp000*.tif -- 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: ANN: lens calibration tutorial
Nice, Torsten, I appreciate useful tutorials. I haven't thoroughly read it yet, but it looks good. It appears there are some informative links in it too. When I do read it properly, I'll pass any feedback I have on to you (to do with as you please, of course. :-) ) John PS typo: *transverse* chromatic aberration (tutorial says *transversal* chromatic aberration.) -- 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: control points as way of Hugin life?
I suppose you should use whatever works for you. It's good to experiment with anything that could get you what you want with less fuss. For me that might be a nice fisheye lens. I like the control and quality Hugin offers. I imagine most people in this forum are looking to get the maximum accuracy and quality from their panoramas. I've not been satisfied with the results of completely automated panoramic stitchers. Then there's the fact that Hugin does way more than just panoramas. And it's free. I was recently impressed with the panorama feature on an iPhone 5. It worked surprisingly well. Again, like using CS5, it could be a handy tool, depending on what you're doing and the results you want to achieve. On Tuesday, October 30, 2012 5:27:59 PM UTC-5, Rossik wrote: Hello all New to the group here but have been a user of Hugin for sometime. For my pano workflow I tend to use either Hugin or Photoshop CS5. Would like to use Hugin more/all the time but when I see that control points are involved with many images I tend to run my photos through Ps. I can appreciate the fine level of control but a lot of the time if I see that Ps can do it without making a mess then I tend to favour that. I particularly find when I have a lot of images (well maybe 10-12 plus) that Hugin always seems to want to add control points for all of them whereas Ps can usually deliver the goods. If not I tend to break them into smaller groups to stitch together and then put those results into a final stitch, using a mix of the two apps if need be. Any thoughts, comments or suggestions greatly appreciated. Ross -- 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: OffTopic - Color Film Development
Don't use anybody who won't return your film! Join a local photo group. They'll clue you in to the local resources. I develop BW 4x5 in my bathroom and then scan. A good printer with custom ink sets works well. For silver prints I use a darkroom at a local photography association. I've gone digital on color (and looking at how my old chromes have faded, this is a good thing.) John On Tuesday, October 30, 2012 9:23:33 PM UTC-5, Dale wrote: I am looking for film development in the US that allows color slide and black and white film negative. Many places are discontinuing the return of film and converting everything to digital. This is a problem for me. Suggestions? Dale -- 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: Digikam can stich panoramas using hugin
I suppose so (I use Aperture.) I'm probably an unusual Mac user in that I do try to use OSS, and of those that do, I'm probably even more unusual in that I really don't know what I'm doing! For example, I've tried Dark Table, but have never been able to get it to run correctly(font problems, boot problems, etc.) :-) But I'm getting better (and even starting to compile stuff myself, in some cases.) Anyway thanks for the heads up. John On Saturday, October 20, 2012 1:49:21 AM UTC-5, Harry van der Wolf wrote: Yes, you are right, but I still think that OS X users will use either iPhoto or Aperture and on Windows there are also a lot of options even though it's mostly camera software or windows own gallery (or what it's called now). Harry -- You received this message because you are subscribed to the Google Groups Hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Announce: jpeg2qtvr-0.04
I had never heard of CPAN. Very cool. CPAN worked like magic but I still haven't figured out how to use your scripts. I think it's just a matter of figurring out and learning some of the assumed knowledge of using perl scripts. I've been reading some stuff on perl, but almost everything assumes one is experienced with CLIs, scripting and Comp Sci. This seems to be the best thing I've found online: Perl 5 Unleashed http://ods.com.ua/win/eng/program/Perl5Unleashed/ If anyone has any other suggestions for a good introduction or quick start for beginners, let me know. I'll work on it for a while and get back to you if I can't figure it out in a week or so. Thanks Bruno. John On Thursday, October 18, 2012 11:23:22 PM UTC-5, JohnPW wrote: On Thursday, October 18, 2012 1:25:15 PM UTC-5, Bruno Postle wrote: . . . This means that it needs some more perl modules, and they may need other perl modules... However there is a simple tool called 'cpan' that will download and install all the modules in the right order from the cpan project. You should just be able to do this on the command-line: sudo cpan Image::ExifTool Image::Size LWP::UserAgent URI ..or even better, Panotools::Script is already on the cpan mirror servers, so you don't even need the above command, you can download and install everything in one go: sudo cpan Panotools::Script (the 'sudo' bit is needed to ensure that you are installing using root/administrator permissions) -- Bruno Well . . . that worked like magic! A heck of a lot easier than everything I had done so far. Thanks 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
