Re: [hugin-ptx] More image tabs in fast preview window
I am third for this request. I have to stitch 150-200 images in one panorama. When I have to use IDENTIFY button. I have to scroll many times to identify image. Wrapping it to rows is a very nice idea. At this moment On mouse over number on numbered bar is highlighted. is it possible that when I use IDENTIFY button and mouse over an image than numbered bar auto scrolls to desired number. On Thu, Jan 13, 2011 at 11:05 AM, Seb Perez-D > wrote: > On Thu, Jan 13, 2011 at 05:54, Sigma Relief wrote: > > Just a minor request for the GUI on the fast preview feature in > > windows; make the numbered tabs closer together when there are more > > images. [...] Wrapping to a 2nd or 3rd line > > would make identifying images easier as it eliminates having to > > continually scroll back and forth when using the identify feature. > > I second this request - it would be very helpful. > > Cheers, > > Seb > > -- > 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 > -- *Emaad* www.flickr.com/emaad -- 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] More image tabs in fast preview window
On Thu, Jan 13, 2011 at 05:54, Sigma Relief wrote: > Just a minor request for the GUI on the fast preview feature in > windows; make the numbered tabs closer together when there are more > images. [...] Wrapping to a 2nd or 3rd line > would make identifying images easier as it eliminates having to > continually scroll back and forth when using the identify feature. I second this request - it would be very helpful. Cheers, Seb -- 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] More image tabs in fast preview window
Just a minor request for the GUI on the fast preview feature in windows; make the numbered tabs closer together when there are more images. The old version could fit 50+ on a 1600 pixel wide screen while fast preview fits 40 with large spacing between tabs. Reducing spacing would be a good easy start. Wrapping to a 2nd or 3rd line would make identifying images easier as it eliminates having to continually scroll back and forth when using the identify feature. At least in Windows, there is plenty of room for 3 rows of numbers, 1 above the current row and 1 where the horizontal scroll bar is. A small vertical scroll bar could be used for more than 3 rows. Are there any simple variables a user could tweak to improve this? I'm not sure if there is an official feature request area so any pointers would be appreciated. -- 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: clustered hugin
On Wed 12-Jan-2011 at 13:28 -0800, michael.grant wrote: Bruno, when you talk about a makefile model, where can I see that? I see, on windows, there's a make.exe, and I'm familiar with make. Where/how are these makefiles generated that make is run on? There is some documentation here: http://wiki.panotools.org/Panorama_scripting_in_a_nutshell#Makefile_stitching_system Basically Hugin constructs a list of all the temporary files and the rules to assemble them, then writes it all to a Makefile. The stitching process is then managed by gnu make, you can close Hugin, or start a new project during stitching, or run stitching entirely on the command-line later or on another machine. Would the other machines need access to all the images in the pano? Could only the overlapping parts of the images be sent to the other server for stitching? The simplest way to do it is to use something like 'distmake', this would require that all the photos were on a shared filesystem -- 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: clustered hugin
I used to work for Sun (but not on SGE). I had a quick look at it. We could create our own grid. There's also things like BOINC, but BOINC is a research grid. BOINC is something you download and install on your machine and it allows people to run stuff on your machine. There's a control panel and you decide which projects to donate your spare computrons to. For example, you could say 50% to einst...@home and 50% to s...@home. Then, you ignore it. When you're computer's screenlock comes on, your computer starts working on these tasks. It sits there, gets a new task, and when it's done, it returns the results. As soon as you come back to your computer, it stops the grid task. You never know it's there. I've been running it for years on my computers and never had a problem with it. I don't know if BOINC would let us build something to let people submit panos to a grid that used the BOINC platform. This may be overkill, and it may take a central server somewhere. In the shorter term, it would be very worth while if hugin could be split into two parts, a server and a client which could submit things to the server(s). Bruno, when you talk about a makefile model, where can I see that? I see, on windows, there's a make.exe, and I'm familiar with make. Where/how are these makefiles generated that make is run on? Would the other machines need access to all the images in the pano? Could only the overlapping parts of the images be sent to the other server for stitching? Michael On Jan 12, 12:38 am, Roger Goodman wrote: > All, > There used to be a product from SUN, called Sun Grid Engine (SGE) > that was made to distribute jobs over multiple computers for > processing. It was free a couple years ago, I haven't looked lately, > now that Oracle owns them. It might be worth looking into. As I > recall, it would run on Windows, Linux, or Solaris systems, but they all > had to be the same OS in the grid. > Roger Goodman > > On 1/11/2011 6:10 PM, Bruno Postle wrote: > > > > > > > > > On Tue 11-Jan-2011 at 09:37 -0800, michael.grant wrote: > > >> Could hugin be split up to run part of it's stitching remotely? > > > Yes, the Makefile stitching system used by Hugin is very suited to > > distribution over multiple machines. -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: what should be in the scripting interface? please have your say!
On 12 Jan., 20:08, Pablo d'Angelo wrote: > In addition to the basic Data model (as you seem to have done already), > the algorithms in hugin_base/algorithms might be useful for scripting > workflows. Here, maybe only the static driver functions are required in > the scripting language as the multi step approach (custruct algorithm > object, call runAlgorithm() & get the results out of the object) is > probably quite a hassle when writing scripts. It would be most helpful if you could point to specific header files and routines therein that you would like to see wrapped. I'll have a look at hugin_base/algorithms and see if anything appeals and yields easily. I also thought to maybe wrap stuff in the PT interface, what do you think? The data model is indeed fairly well covered by now - all functionality from the following headers is in the interface: SrcPanoImage.h PanoramaVariable.h PanoramaOptions.h ControlPoint.h Panorama.h when I say all functionality, I mean that all classes and other data types are available as proxies in the target language (currently only Python, but I suppose I could easily churn out a perl one, and a few others for that matter) and all methods of the classes can be called. Of course this is all quite a lot and I haven't had time to test it thoroughly, but since the process is mainly automatic I am quite convinced it'll all work nicely. The current status quo with the above headers covered feels like a milestone to me, and I'll go over the data now for a bit and then publish. > Btw. is your code available in some repo? Maybe a new hugin_scripting > branch would be a good idea. I don't have and don't want a sourceforge account, so I'll publish via the same route as I have published my other Python material. So far I've GPL'd everything, so if it's well received there's no problem for it to be copied into the hugin distro channels. Intergrating the stuff into the hugin source tree is straightforward, it's all in a separat folder and the master CMakeList.txt only needs to include that folder, from there it's almost automatic, only one of the headers is modified slightly in a compatible manner, but maybe I can work around the issues there and somehow wrap it unmodified. I'll probably also put the binaries for the Python modules online, that'd be Kubuntu 10.10 and Python 2.6. I haven't been willing (Windows) or able (Mac OS) to do tests on other systems, but SWIG 2.0.1 is source-distributed to all these platforms, Python is available for all of them, and CMake also. > > The next step, the 'mechanism to use scripted content from hugin', > > would require code linked into hugin to interface with a scripting > > language, enabling stuff like 'plugins'. > > That would be especially helpful for customizing workflows etc. If the > integration also extends to wxPython, new GUI functionality could be > quite easily prototyped or even implemented in python. It all looks very promising. I even have dreams of 'floating' the Python stuff and make it quite feasible to run the show with Python (so, have the main() there and use the C++ as a backend for time- critical stuff). The great difference using a scripting language is that you don't have to compile and link; the access is practically instantaneous. Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: what should be in the scripting interface? please have your say!
Hi Kay, Am 10.01.2011 12:39, schrieb kfj: I have set out creating a scripting interface for hugin. Great, I think that hugin can benefit greatly from such an interface, both for custom utilities, as well as quick prototyping of new ideas. So the next thing that I feel needs to be done before I proceed is this: - decide which part of the hugin functionality should be scriptable In addition to the basic Data model (as you seem to have done already), the algorithms in hugin_base/algorithms might be useful for scripting workflows. Here, maybe only the static driver functions are required in the scripting language as the multi step approach (custruct algorithm object, call runAlgorithm() & get the results out of the object) is probably quite a hassle when writing scripts. Btw. is your code available in some repo? Maybe a new hugin_scripting branch would be a good idea. The next step, the 'mechanism to use scripted content from hugin', would require code linked into hugin to interface with a scripting language, enabling stuff like 'plugins'. That would be especially helpful for customizing workflows etc. If the integration also extends to wxPython, new GUI functionality could be quite easily prototyped or even implemented in python. ciao Pablo -- 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] PTS files
On Wed 12-Jan-2011 at 11:00 -0600, Dale Beams wrote: Is there a way to combine several PTS files in Hugin into one set? Hugin can import ptgui .pts files and save them as Hugin .pto projects, though if you have any cropped photos in the project you will need to fiddle with the crop and reoptimise. You can use File -> Merge project... to merge multiple Hugin projects together. -- 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: radial correction
Yes, we need better lens calibration, based on better camera models. But (having looked into the matter lately) I strongly agree that revising libpano is not the way to get that. Libpano was designed to support panorama stitching, not lens calibration. Its way of representing and optimizing lens parameters is not what an optical theoretician would prescribe, but it does get the job of aligning images done very well, thank you. The fact that the resulting parameters don't apply to images having different dimensions is an inconvenience only if you make it one, by trying to use them for that. What I would suggest is to add 'portable' lens calibration at the level of Hugin, which can be done with at most minor changes to libpano. The first step would be very easy: converting saved lens parameters to suit the image at hand. The key to this is storing the original image dimensions, along with (hfov,a,b,c,d,e). Hugin now does store at least the width, but uses it only to put up a warning when you try to apply the lens to an image of a different width. Instead (or rather, in addition) it should rescale hfov to suit the new width, which is straightforward using the calibration parameters and existing libpano functions. That may or may not be a valid operation, for several possible reasons, however it is valid in all the common use cases: the image was rotated 90 degrees, or was taken at a different camera resolution, or with the lens on a different camera. So this would be a big help to the average Hugin user at little cost. PTGui is already doing something like this (but without the warning message). The next step would be to make it possible to import calibrations from other sources. I'm thinking of Adobe Lens Profiles in particular; but it should be easy to accommodate correction polynomials from any source, if the user is able to pick the source from a list and willing to enter the coefficients by hand. To apply these foreign calibrations, libpano would need a new radius correction mode (and stack routine) for each polynomial style. There is already a var that selects a radial mode, and the coefficients could go in existing slots. It would need some thought whether 'lens' optimizations could be allowed when using an imported calibration. Certainly, it would not be feasible to get 'exportable' lens calibrations without heavily revising libpano; but I have a feeling the libpano model could be used in tandem with a foreign one, just to better align the current pano. Anyhow, one required basis for such improvements is a unified database, that can store any calibration Hugin can use. This should not be so hard to set up. I'm well along with something of the kind for Panini, that uses the ini file-based app settings facility of Qt. It is just a personal-scale db, but that is what I think is wanted here. Cheers, Tom On Jan 11, 6:44 pm, Bruno Postle wrote: > On Tue 11-Jan-2011 at 13:08 -0800, Klaus wrote: > > > > > I have to second Bruno in noting the shortcomings of the current > > camera model. > > Yes it has obvious technical shortcomings, but I'm not certain they > are actually a problem in practice. Switching Hugin to a different > system for would be very disruptive. > > -- > 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] PTS files
Is there a way to combine several PTS files in Hugin into one set? -- 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: Product Vision (was:An idea to expand HDR)
On Mon, 2011-01-03 at 09:55 -0600, Dale Beams wrote: > In addition, other programs often use date/time of photo as an > indication of loading to the grid. For example, the first photo having > a time of 11:00 and the next having a time of 11:00:15 would indicate > the first and next photos of the set, and their relationship to one > another. This method is can also be used to extract multiple pano's > from a group of photos. One would expect photos taken on the 1st of the > month to be a set and photos taken on the second of the month to be a > set as well. > > Using a date/time sequence, when photo 12 and photo 13 does not match, > one can assume a new row. > > One only needs to indicate direction at this point. > > > > On Mon, 2011-01-03 at 09:31 -0600, Dale Beams wrote: > > Not as complicated as one might seem. There are many programs that ask > > for table sizes. This is essentially a table > > > > Dialog: > > > > How many rows & columns > > Which direction > > Etc. > > > > The other option is to present a table layout. It's then easy to mark > > each cell in the table as row/column, set the direction, set the > > starting row, etc. Rows with different number of photos sets would have > > empty cells where the rows were shorter. > > > > Comparison is a good measuring stick to be subject to, unless the > > project is so creative and so groundbreaking it becomes the measuring > > stick. > > > > Even the simplest stitchers have layout options, direction, rotation, > > etc. > > > > Dale > > > > > > On Mon, 2011-01-03 at 14:49 +, Bruno Postle wrote: > > > On Sun 02-Jan-2011 at 22:15 -0500, Yuval Levy wrote: > > > > > > >> I see very little value in a wizard that asks you a number of rows > > > >> and columns, this will only add complication to the GUI and won't > > > >> help a significant proportion of people who do seriously large > > > >> panoramas. > > > > > > > >and yet there is demand for that? > > > > > > People ask for it. But we had a determined attempt to design a GUI > > > for it as part of James's Layout Summer of Code project and > > > immediately encountered so many special cases that it would be the > > > most complex interface in the whole software. Some of the issues: > > > > > > Different numbers of photos in each row is normal (actually it's > > > preferred for spherical panoramas). > > > > > > Left to right, or right to left, or up and down sequences are all > > > valid. > > > > > > Zig-zagging sequences are valid and preferable for partial > > > panoramas. > > > > > > Middle-row first is almost always preferable to starting top-left. > > > > > > All this is why the multi-row procedure exists in Hugin, in > > > principle it deals with all these cases automatically without a GUI. > > > > > > -- > > > 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: Usability bug: Optimiser alignment options confusingly ordered
Hmm, in my "2010.4.0.c379b4821223 built by Matthew Petroff" version (Windows), the Reset button in the *Images* tab *does* reset y/p/r as well as XYZ. Read my previous post again. You were in the *Camera and Lens* tab, where the Reset... button has different functionality. XYZ are not camera/lens parameters, so it makes sense that this button does not affect XYZ. Actually it would also make sense that y/p/r remain untouched by this button, since those parameters are not really camera/lens related either. -- Bart -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: On the way to 2011.0
On 10 Jan., 12:02, kevin wrote: > Only thing I've noticed odd is that the debug > output seems to be turned on by default and haven't figured out how to > turn it off . Tired -DCMAKE_BUILD_TYPE=Default but still lots of > DEBUG, TRACE, and INFO output on the commandline it's launched from. see http://groups.google.com/group/hugin-ptx/browse_thread/thread/5ee9374207a404ec# Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
