[hugin-ptx] Re: cpfind ransac mode
On 22 Jan., 22:20, Pablo d'Angelo wrote: > I have thus implemented a new RANSAC model that can make use of the > restrictions we have in panoramas, and also include prior information > about lens type, HFOV and distortion etc. Basically, it tries to > estimate roll,pitch and yaw for each image pair (using two control > points), and checks if the remaining points are consistent, and repeats > that a few times. This is definitely the way to go. Since RANSAC bases it's exclusion of outliers on a consistency check which depends on feedback from a model, if the model is wrong (i. e. assuming rectilinear images) consistency of a set of points under consideration cannot be established. Extending the tolerances here will only gloss over the fact that the model is wrong, not the points fed into it. There is no way to avoid having information about FOV and projection - if the EXIF data don't yield, the user must provide. > Unfortunately, in some cases, the HFOV is not know very well (incomplete > EXIF data, bad crop factors entered by the user etc...), so one cannot > unconditionally recommend --ransacmode rpy. You have to draw the line somewhere. If the EXIF data are missing and the user is prompted to supply sufficient subset of FOV, crop factor and focal length and the user enters wrong data, you can't make it right for him/her. What the user can do if he/she has no clue at all is do a panorama as best as they can and so arrive at an estimate of these data to use from then on. > 1. User has a good estimate of the HFOV (EXIF Data or prior > calibrations) -> use cpfind --ransacmode rpy > which makes cpfind virtually bullet proof to really bad mismatches. > > 2. Bad EXIF Data and user doesn't know about crop factors or the like -> > use cpfind --ransacmode auto (the default) or cpfind --ransacmode > homography, and accept some outliers. I think that is a perfectly reasonable choice. And once case 2 has produced a roughly correct output, the FOV has been established with sufficient accuracy to use --ransacmode rpy. > I hesitate to default to --ransacmode rpy, as this will probably lead to > quite some breakage for novice users, who enter bad crop factors. quite right. I'd assume the inexperienced users aren't usually the ones using fisheyes anyway. > I find 2. a bit unsatisfying as it means that we will get suboptimal > results for many inexperience users (and many experienced ones too, who > don't know about all the cpfind internals...). > > Whats your opinion about that? I feel that the problem here is in the presentation of these choices. As long as the user, experienced or not, has to make all the way into the CPG settings dialog to modify command line arguments, all but the most confident and experienced users will hesitate to go down that road. The treatment of CPGs, CPG parameters and their manipulation needs a facelift. The capabilities of the CPGs themselves, be it your creature cpfind or the other, patent-encumbered ones, are, imho, perfectly sufficient. > - Try to automatically add --ransacmode rpy, if the hugin could > successfully read HFOV from the EXIF data? In theory this is a fine idea. But keep in mind one point that noone ever adresses in this whole discussion: The treatment of FOV in hugin is, if I am interpreting the mechanism right, fundamentally flawed. The only thing that is asked for and processed seems to be the HORIZONTAL field of view. Now if I make images with an APSC sensor and, in landscape mode, have a HFOV of 60 degrees, then do some shots in portrait, suddenly the HFOV is 40 degrees. Hugin even insists on me entering a 'different lens' instead of just calculating the diagonal fov and realizing it's the same thing after all. So a 60 degree limit does not necessarily work - if hfov in landcape is, say, 65 (like with my ordinary zoom lens at 18mm) and 43 in portait, all of the sudden the same lens would once be treated as a fisheye and once as a rectilinear. Please correct me if I'm mistaken. 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: Test case for cpfind
Hi Yuv, Am 23.01.2011 04:33, schrieb Yuval Levy: > can somebody please check why Hugin/cpfind has difficulties with this set of > images from Michel Thoby? > > http://www.sendspace.com/file/vnek81 I tried the set with the following steps: With assistant: 1. load images, set 14 mm rectilinear 2. align 3. straighten by drag in preview http://www.flickr.com/photos/vonengel/5379754185/ Without assistant: 1. load images, set 14 mm rectilinear 2. run cpfind (without multirow) 3. optimize pairwise, rpyvde, rpyvbcde 4. straighten by drag in preview http://www.flickr.com/photos/vonengel/5380355446/ Both seem to work fine. What problems did you encounter? Note: done with the latest hg version, 2010.4 wont work. 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
[hugin-ptx] Re: clustered hugin
Hi Michael, Am 22.01.2011 12:20, schrieb michael.grant: Unless you do something like this, I can't see how hugin is going to be able to create a pano any greater than the available swap space. How difficult would it be to rework emblend to do something like the above? Enblend can use temporary files (if compiled without OpenMP), and then can process very large images. A good option for clustering would be to split the panorama in many smaller parts (tiles, using the crop feature of hugin), and distribute these. There might be some artefacts near the boundaries, so rendering overlapping tiles is probably better. Then these tiles could be cropped and easily assembled together into a big output file (if one output file is required at all...). 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
[hugin-ptx] Test case for cpfind
can somebody please check why Hugin/cpfind has difficulties with this set of images from Michel Thoby? http://www.sendspace.com/file/vnek81 thanks Yuv signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: clustered hugin
On Jan 12, 9:28 pm, "michael.grant" wrote: > 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 Einstein@home > and 50% to Seti@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. I've been loosely following the thread, but slurm would be pretty good as an alternative to SGE (we use slurm quite a bit in work for our compute clusters) and to top it off, there is a patch to gnumake which does an "srun" (under an a slurm allocation) instead of a fork and sh .. if would be quite easy to taskfarm out the jobs if hugin could dump out a makefile with a bunch of commands to run for the stitch jimmy. -- 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] cpfind ransac mode
Hi all, panomatic and thus cpfind use a RANSAC step for outlier removal. This used to be based on a homography, which works ok for non-wide angle images. It breaks for fisheye images, here a large error tolerance must be choosen, and this results in a rather weak outlier check for wide angle and fisheye images. Additionally, the homography is more general than what we expect for panoramic images (it can also "mirror" images, for example), and this can result in some false matches slipping through, even when a relatively strict RANSAC threshold is choosen. Unfortunately, this can sometimes connect unrelated images together, and cpclean doesn't help as it won't remove all matches in an image pair. I have thus implemented a new RANSAC model that can make use of the restrictions we have in panoramas, and also include prior information about lens type, HFOV and distortion etc. Basically, it tries to estimate roll,pitch and yaw for each image pair (using two control points), and checks if the remaining points are consistent, and repeats that a few times. A new --ransacmode parameter can be used to switch between the ransac modes. By default it uses the homography and switches to the roll,pitch,yaw model if the HFOV is bigger than 65 degrees, the same value that is used to decide whether to remap to stereographic or not. For testing, the HFOV can also be estimated in the RANSAC routine, but this is quite fragile due to panotools problems with estimating HFOV on image pairs. Some examples: --ransacmode rpy (new) http://www.flickr.com/photos/vonengel/5378995090/ --ransacmode auto (default mode, uses homography) http://www.flickr.com/photos/vonengel/5378994908 Unfortunately, in some cases, the HFOV is not know very well (incomplete EXIF data, bad crop factors entered by the user etc...), so one cannot unconditionally recommend --ransacmode rpy. It might be possible to work around that problem, but it will require some significant work, and I'm not sure if it worth it. For the user that means: 1. User has a good estimate of the HFOV (EXIF Data or prior calibrations) -> use cpfind --ransacmode rpy which makes cpfind virtually bullet proof to really bad mismatches. 2. Bad EXIF Data and user doesn't know about crop factors or the like -> use cpfind --ransacmode auto (the default) or cpfind --ransacmode homography, and accept some outliers. I hesitate to default to --ransacmode rpy, as this will probably lead to quite some breakage for novice users, who enter bad crop factors. I find 2. a bit unsatisfying as it means that we will get suboptimal results for many inexperience users (and many experienced ones too, who don't know about all the cpfind internals...). Whats your opinion about that? - Should we add more default presets to the control point detector preferences? - Try to automatically add --ransacmode rpy, if the hugin could successfully read HFOV from the EXIF data? - Try to robustly add HFOV to the RANSAC model? Maybe just trying a range of initial HFOVs would be sufficient... However, I'm not sure if I can do that with my limited time budget. Another way to reduce the problem would be to use a camera-crop factor database, such as the one from Autopano PRO: http://www.autopano.net/wiki-en/Cameras.txt 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
[hugin-ptx] Re: hugin plugin interface - developers please liaise
On 22 Jan., 16:05, "T. Modes" wrote: > I finally found a solution to automatically create the preprocessed > file and input it into the swig process. So there is no need to fiddle > by hand with the preprocessing and there are not 2 version of the same > file which needs to be in sync (commited in 25f830e2d143). > So you can further testing now. Your solution absolutely does the trick. I'm no good at cmake, and seeing what you did with it I'm duly impressed. I feel this is a nice and clean solution now; it worked on my Ubuntu system, just a tiny error in CMakeLists.txt - the directive for the gcc preprocessor is -E and not /E. And all automatic, as it should be! Well done :-) 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: clustered hugin
This probably deserves another thread, but anyway, if I may ask, what is the state with Enblend, and are there any other plans to make another blender? I still use smartblend regularly, it's 5 years old, single core, 32-bit a dinosaur. but still superior in terms of blending to anything else out there, in my opinion. Blending is the most expensive part of stitching PTStitcherNG is great, but the blending is not very "smart". I heard Prof. Dersch will continue development of PTStitcherNG this winter, apparently (by the way) Jeffrey -- 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 plugin interface - developers please liaise
On 22 Jan., 16:05, "T. Modes" wrote: > I finally found a solution to automatically create the preprocessed > file and input it into the swig process. So there is no need to fiddle > by hand with the preprocessing and there are not 2 version of the same > file which needs to be in sync (commited in 25f830e2d143). > So you can further testing now. Excellent. I'll have a look at your solution when I get round to it, if not tonight then tomorrow. I'll report back and tell you how it works here. Thank you for your cooperation! So by now you should have the thing running, accessor functions and all? Congratulations! 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: hugin plugin interface - developers please liaise
I added also an installer for windows in CMake. The lines for unix are prepared by comment out because I don't know in which directories the files should go on unix. 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
[hugin-ptx] Re: hugin plugin interface - developers please liaise
Hi Kay, > swigpyrun.h is input. It is included by hpi_classes.h which is in turn > included by hpi.cpp. This is why it is needed in the source tree. It's > needed in the making of the hpi object code which is then linked into > libhugin.so, but is irrelevant further down the road and does not > belong to the output. But it should be generated anew every time the i- > file is processed, to reflect possible changes in the SWIG-generated > data structure. It's not needed in the source tree. The compiling and linking work also if the file is in the build tree (when the paths are configured right). So it works e.g. with hugin_config.h, where some platform/user specific things are defined. So no need to generated in the source tree with all implications. > > > 2.) There is no need for 2 versions of PanoramaVariable.h. The little > > difference for hugin and swig can easily achieved by an ifndef. So > > there is only one version and you don't handle with synchronisation of > > 2 versions of the same file. > > I felt this was the cleaner solution while hsi is still under > development. Ok, I did not see this point. > > Yes, it works. It has only a minor glitch. The output of the print > > command is not shown (a fear something similiar for an input > > function). But modifications to the pano object occur and appear also > > in hugin. > > did you start hugin from the command line? If not, there's no way you > can see anything, the prints just go into thin air. The affectiveness > of the modifications to the panorama are the main thing; the print > statements in hpi.py and demo_plugin.py are only as a quick proof that > something goes wrong or right. But hugin must be started in a console > window to see them. Yes, also tested on console, but this does not help because the console works in an other way than on unix. > > > - I've preprocessed this section separately: gcc -E > > > hsi_SrcPanoImage_accessor_macros.h > xx > > That will not work on windows, because we are using an other compiler. > > I'm confident that every C++ compiler in existence offers separate > precompilation. But as stated in the previous section I will try and > find a solution to avoid this. I finally found a solution to automatically create the preprocessed file and input it into the swig process. So there is no need to fiddle by hand with the preprocessing and there are not 2 version of the same file which needs to be in sync (commited in 25f830e2d143). So you can further testing now. 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
[hugin-ptx] Re: hugin plugin interface - developers please liaise
On 22 Jan., 11:16, "T. Modes" wrote: > > I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in > > the source tree instead of the target tree, but I still haven't > > figured out how to have it made automatically initially - I can get > > only get it to be created if I explicitly call make 'hsi_header'. > That's a bad idea. We configured cmake so that all files are generated > in the target tree to keep the source tree clean. So what's the reason > for generating in the source tree? > I commited a slightly modified version of your patch. > Some comments about the changes: > 1.) If you create swigpyrun.h in the source tree, it can happen (as in > your patch) that you pull in this file into the repository and > therefore the version management. An automatic created file should not > be in version management. So I removed this part. swigpyrun.h is input. It is included by hpi_classes.h which is in turn included by hpi.cpp. This is why it is needed in the source tree. It's needed in the making of the hpi object code which is then linked into libhugin.so, but is irrelevant further down the road and does not belong to the output. But it should be generated anew every time the i- file is processed, to reflect possible changes in the SWIG-generated data structure. > 2.) There is no need for 2 versions of PanoramaVariable.h. The little > difference for hugin and swig can easily achieved by an ifndef. So > there is only one version and you don't handle with synchronisation of > 2 versions of the same file. I felt this was the cleaner solution while hsi is still under development. Initially I was doing it with an #ifdef, but the difference can easily be seen by running diff on the two versions. Please consider, that every change to hugin header files triggers a major recompile, which takes a long time, and if the changes only affect hsi/hpi, this is a total waste of time. Once everything is stable, reverting to switching by #ifdef is a snap. As a temporary measure, it allows quick changes to the headers going into hsi and leaving the rest as it is. Also, I feel that ideally at least the changes to ImageVariable.h could beome unnecessary - I think it's safe to include default constructors for the classes, and I hope to get the PrintVariable class to work, so for this one there wouldn't be a need for different versions. If you insist, though, we can revert to the #ifdef _Hugin_SCRIPTING_INTERFACE solution I was using before. to reply to your previous post concerning your getting it to run on windows: > Yes, it works. It has only a minor glitch. The output of the print > command is not shown (a fear something similiar for an input > function). But modifications to the pano object occur and appear also > in hugin. did you start hugin from the command line? If not, there's no way you can see anything, the prints just go into thin air. The affectiveness of the modifications to the panorama are the main thing; the print statements in hpi.py and demo_plugin.py are only as a quick proof that something goes wrong or right. But hugin must be started in a console window to see them. concerning the accessors: > What's with the following idea: > Put all for SWIG unnecessary includes into #ifndef SWIG and then run > swig with includeall? > Can swig run with includeall on a single file or have we to modify all > files in this case? you can't activate 'include all' for just one header file. To achieve this effect, it would be possible to make a separate i-file for the accessors, create another python module from that and load that when hsi is loaded. This separate i-file can be processed with different options like --include-all. The problem is that SrcPanoImage.h includes tons of other headers, which would all be pulled in and wrapped with --include-all if SRCPanoImage.h was %included whole by the i-file. This is certainly not what we want. What may be possible is to put the accessor macros into a separate header which can be %included by a separate i-file with --include-all to just generate the accessors. SrcPanoImage.h could also include this header, and everything should work both ways. I'll investigate and make a proposition if it's feasible. > > - I've preprocessed this section separately: gcc -E > > hsi_SrcPanoImage_accessor_macros.h > xx > That will not work on windows, because we are using an other compiler. I'm confident that every C++ compiler in existence offers separate precompilation. But as stated in the previous section I will try and find a solution to avoid this. I do feel it's a bit of a side issue, though - I've already spent a fair amount of time getting the accessor functions to run and I feel the time would be better spent in testing if they do what they're supposed to do. Anyway, I'll try and avoid the separate preprocessing step, but for now you can let hsi.i %include hsi_SrcPanoImage.h and have the accessors - all other code still uses the unmodifies SrcPanoImage.h and is una
[hugin-ptx] Re: clustered hugin
By needing the emblend to be done all in one shot like this you loose the advantage of make here. Especially since if you stop the job at this point, you have to start the emblend all over again. Distributing the other pieces is a small job in comparison to the emblend which seems to take the most time. So it seems that emblend is keeping the entire image in memory. What if you broke up the job of emblend so that it output it's pieces to intermediate tiles files which were then assembled into the final tiff after? Then maybe you could distribute the non-overlapping tiles and and input images to another machine. You kind of "lock" those tiles until that section is done. The idea is to keep in memory just the section you are working on, even it it's like 100meg or so, that's not too large. Unless you do something like this, I can't see how hugin is going to be able to create a pano any greater than the available swap space. How difficult would it be to rework emblend to do something like the above? Michael -- 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 plugin interface - developers please liaise
Hi Kay, On 22 Jan., 10:08, kfj <_...@yahoo.com> wrote: > The new patch is now online at > > http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch48... > > This has the accessor code for class SrcPanoImage and some cosmetic > changes I commited a slightly modified version of your patch. Some comments about the changes: 1.) If you create swigpyrun.h in the source tree, it can happen (as in your patch) that you pull in this file into the repository and therefore the version management. An automatic created file should not be in version management. So I removed this part. 2.) There is no need for 2 versions of PanoramaVariable.h. The little difference for hugin and swig can easily achieved by an ifndef. So there is only one version and you don't handle with synchronisation of 2 versions of the same file. 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
[hugin-ptx] Re: hugin plugin interface - developers please liaise
On 21 Jan., 18:58, kfj <_...@yahoo.com> wrote: > I'll put a patch online today or tomorrow and post when I've done so. The new patch is now online at http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4878.gz This has the accessor code for class SrcPanoImage and some cosmetic changes 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: hugin plugin interface - developers please liaise
Hi Kay, >But you got it to run? On Windows? That would be good news indeed, >because there are so many Windows hugin users out there, and I was >secretly afraid of subtle differences in SWIG and Python that might >make my code useless there. Yes, it works. It has only a minor glitch. The output of the print command is not shown (a fear something similiar for an input function). But modifications to the pano object occur and appear also in hugin. On 21 Jan., 18:58, kfj <_...@yahoo.com> wrote: > On 21 Jan., 11:39, kfj <_...@yahoo.com> wrote: > > > ... I'll generate the required i-file code (so, code for SWIG) by means of > > a Python script > > ... hmmm ... that didn't work out either. So I've now settled on the > following aproach (which works but isn't very elegant): > What's with the following idea: Put all for SWIG unnecessary includes into #ifndef SWIG and then run swig with includeall? Can swig run with includeall on a single file or have we to modify all files in this case? > - I've preprocessed this section separately: gcc -E > hsi_SrcPanoImage_accessor_macros.h > xx That will not work on windows, because we are using an other compiler. > I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in > the source tree instead of the target tree, but I still haven't > figured out how to have it made automatically initially - I can get > only get it to be created if I explicitly call make 'hsi_header'. That's a bad idea. We configured cmake so that all files are generated in the target tree to keep the source tree clean. So what's the reason for generating in the source tree? 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
