[hugin-ptx] Re: windows binary release
Software can be copyrighted but not patented. An algorithm can be patented. It is a more high-level, abstract concept than a piece of software. It's just too easy to change a few lines of code and claim it's a different program, and too hard to say how much should be changed before they are different. At least that's what I learned in my very brief 'patent law for engineers' class in university. Laws of man change faster than laws of nature, I know the patent law has changed since then but I don't know what the differences are exactly. On Oct 8, 12:52 pm, Yuval Levy wrote: > I thought the European Patent Office would not grant patents on software? > Yuv > > allard wrote: > > Thanks. That certainly shows the USPTO database search is no good. > > Also surprised that this goes unmentioned in so many places. But the > > EPO was a pretty obvious place to look as well. > > >> See:http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=2027558A2&;... > > >> 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: windows binary release
On Thu, Oct 08, 2009 at 03:52:16PM -0400, Yuval Levy wrote: > I thought the European Patent Office would not grant patents on > software? Because they get paid for the work they do, the patent office likes "more patents". So they were a strong proponent of the practise. I believe there was a short period where they allowed software patents and the legislators had not yet intervened. Roger. -- ** 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! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
I thought the European Patent Office would not grant patents on software? Yuv allard wrote: > Thanks. That certainly shows the USPTO database search is no good. > Also surprised that this goes unmentioned in so many places. But the > EPO was a pretty obvious place to look as well. > > >> See:http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=2027558A2&;... >> >> 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: windows binary release
Am Thursday 08 October 2009 schrieb Yuval Levy: > > Bruno Postle wrote: > > On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: > >> Perl is required for Bruno's Panotools-Scripts which are part of the > >> panotools distribution. I don't know the exact detail of the CMake > >> build, but I think it should also work without perl (and simply not > >> install the perl scripts). Alternatively, try installing Perl on your > >> Windows box and see what it does. > > > > Panotools::Script is in the same SVN repository, but it is a > > different piece of software from libpano13. > > I did not articulate my thoughts well enough. The impression I have is > that when the CMake was expanded by Kornel beyond what Thomas started, > he looked at the whole repository and made it work for all, including > the Panotools::Script. > > I don't see any other reason for making the CMake build dependent on > finding perl on the build machine. > > Yuv > Including the tests directory to be precisely. And only the tests are not done, if there is no perl. Kornel -- Kornel Benko kornel.be...@berlin.de signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: windows binary release
Thanks. That certainly shows the USPTO database search is no good. Also surprised that this goes unmentioned in so many places. But the EPO was a pretty obvious place to look as well. > > See:http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=2027558A2&;... > > 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: windows binary release
allard schrieb: >> no panomatic is definitely not in the SDK. and it adds "short term" >> problems - until the patent (SURF) expires. >> >> I think we need to follow the lead of the Mac OSX builds and make >> separate installers for the CP generators. But I also think that this >> should come after the SDK-build, binaries-build and installer >> compilation work well enough in sync. not now. for now leave it as it >> is, but leave it "broken" (i.e. don't add panomatic itself). > > I was recently looking for that patent on SURF. I couldn't find it. See: http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=2027558A2&KC=A2&FT=D&date=20090225&DB=EPODOC&locale=en_V3 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: windows binary release
Jim Watters wrote: > Lets get the current release out first. I wont be checking any of this > into trunk soon. I'm looking forward for the updated Photoshop plugins. I'm currently stuck with Photoshop CS2 because Photoshop CS3 crashes on my box when I use the plugins there. How about a developer branch? Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
Bruno Postle wrote: > On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: >> Perl is required for Bruno's Panotools-Scripts which are part of the >> panotools distribution. I don't know the exact detail of the CMake >> build, but I think it should also work without perl (and simply not >> install the perl scripts). Alternatively, try installing Perl on your >> Windows box and see what it does. > > Panotools::Script is in the same SVN repository, but it is a > different piece of software from libpano13. I did not articulate my thoughts well enough. The impression I have is that when the CMake was expanded by Kornel beyond what Thomas started, he looked at the whole repository and made it work for all, including the Panotools::Script. I don't see any other reason for making the CMake build dependent on finding perl on the build machine. Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: > >Perl is required for Bruno's Panotools-Scripts which are part of the >panotools distribution. I don't know the exact detail of the CMake >build, but I think it should also work without perl (and simply not >install the perl scripts). Alternatively, try installing Perl on your >Windows box and see what it does. Panotools::Script is in the same SVN repository, but it is a different piece of software from libpano13. -- 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: windows binary release
allard wrote: > Until this is solved I'll take panomatic out of the install script and > update. Herbert Bay, the inventor of SURF, was a GSoC-Mentor for Hugin/Panotools in 2007. I recall he mentioned a patent. I've pinged him as well. Independent on wether SURF is patented or not, I repeat that I think that it makes sense to make separate installers for the CP generators, like on MacOSX. > I was using Cmake. There's a few unfound files that Cmake comes with, > mostly in WxWidgets. that's OK and it will not cause problems because we don't use them. > Then there's these two that don't show up in the hugin CMakecache.txt > > _svnversion:FILEPATH=_svnversion-NOTFOUND > PERL_EXE:FILEPATH=PERL_EXE-NOTFOUND > > Could that be part of the problem? partially. the svnversion can be fixed. IIRC Kornel used it to implement differently what is in Hugin's top level CMakeLists.txt around line 22. I'd suggest changing the Panotools CMake build to do the same thing as the Hugin build, tried and tested on many platforms including Windows. Perl is required for Bruno's Panotools-Scripts which are part of the panotools distribution. I don't know the exact detail of the CMake build, but I think it should also work without perl (and simply not install the perl scripts). Alternatively, try installing Perl on your Windows box and see what it does. All this feedback is blind - I don't have access to my Windows box now; and I don't have time to look at libpano's CMake. Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
allard wrote: > I'm trying to build libpano from svn 1096 but MSVC is giving me some > errors. I run into something that is beyond my extremely limited > coding abilities. Here's the output from MSVC that keeps showing up: > > 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol > _optind > 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol > _optarg > 12>pano13.lib(PTcommon.obj) : error LNK2019: unresolved external symbol > _getopt referenced in function _panoCroppingMain > 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol > _hDllInstance > 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol > _wndOwner > 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol > _CenterDialog referenced in function _set...@16 > 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol > _SetWindowOwner referenced in function _set...@16 > > Ideas anyone? > > Allard > Have you managed to resolve these errors? _optind and _optarg require the file getopt.c it is in libpano\tools\compat_win32 If PTCommon is using it then the folder compat_win32 should be moved up a level. The errors of hDllInstance, wndOwner, CenterDialog, and SetWindowOwner indicate that you building the CMD version of the tools using sys_ansi but have also included sys_win.h. The tools currently only build as CMD. To do this define MSDOS or _CONSOLE (see panorama.h line 40 and PTDialogs.c line 28) CMD tools are built with sys_ansi GUI tools are built with sys_win (currently broken) -- Jim Watters jwatt...@photocreations.ca http://photocreations.ca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
> > no panomatic is definitely not in the SDK. and it adds "short term" > problems - until the patent (SURF) expires. > > I think we need to follow the lead of the Mac OSX builds and make > separate installers for the CP generators. But I also think that this > should come after the SDK-build, binaries-build and installer > compilation work well enough in sync. not now. for now leave it as it > is, but leave it "broken" (i.e. don't add panomatic itself). I was recently looking for that patent on SURF. I couldn't find it. Not in the USPTO database at least, and not in Google either. The SURF homepage doesn't mention a patent. And none of the inventors -by which I mean the authors of the original paper- have the patent listed in their CV's or publication lists as far as I could find. All I could find was the *implementation* of SURF (confusingly called SURF) which is proprietary and not allowed for commercial use. See http://www.vision.ee.ethz.ch/~surf/download.html . Copyright is mentioned, not a patent. And then there's a bunch of open source implementations under GPL licence like OpenSurf (http:// code.google.com/p/opensurf1/ ) or MIT license like libmv (http:// code.google.com/p/libmv/wiki/SurfImplementation). They don't mention anything about patents. I couldn't find the patent for the algorithm anywhere. The only places I found that claim the algorithm is patented are this list and the panomatic page http://aorlinsk2.free.fr/panomatic/ . Am I that bad at searching, is it really patented? If any of you can point me to the patent that would be great. If not, I'll send one of the inventors an email to clarify the matter. Until this is solved I'll take panomatic out of the install script and update. > > My recent experience, with both CMake and the MSVC projects, was when > Jim asked for a Windows binary of the layout codeline. At first nothing > worked. Then Jim fixed it, at least partially. The overall build would > still fail but the library (which is what is needed for Hugin) built > well and worked well. I am not sure if in the meantime the building of > the tools themselves has improved in Windows (and the tools themselves; > and the related perl Panotools-scripts by Bruno are something to > consider when expanding the installer). > I was using Cmake. There's a few unfound files that Cmake comes with, mostly in WxWidgets. The same errors show up in the hugin build but they never cause problems CMAKE_LINKER:FILEPATH=CMAKE_LINKER-NOTFOUND WX_mono:FILEPATH=WX_mono-NOTFOUND WX_monod:FILEPATH=WX_monod-NOTFOUND WX_odbc:FILEPATH=WX_odbc-NOTFOUND WX_odbcd:FILEPATH=WX_odbcd-NOTFOUND wxWidgets_wxrc_EXECUTABLE:FILEPATH=wxWidgets_wxrc_EXECUTABLE-NOTFOUND Then there's these two that don't show up in the hugin CMakecache.txt _svnversion:FILEPATH=_svnversion-NOTFOUND PERL_EXE:FILEPATH=PERL_EXE-NOTFOUND Could that be part of the problem? Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
Bruno Postle wrote: > On Tue 06-Oct-2009 at 16:27 -0400, Yuval Levy wrote: > >> Jim Watters wrote: >> >>> Last night I was playing with updating my MSVC projects for libpano to >>> create multiple binaries. I want to build .lib or .dll for both >>> command line or GUI, as release or debug. The .dll built with java >>> support. The .lib without java support. I have managed to figure out >>> many things but still much to do. I want to support 32 and 64bit too. >>> >> is Java still used? what for? how will the dll behave if there is no >> Java on the machine? >> > As far as I know it is only used by the ptpicker and pteditor tools, > but since they only link to libpano12 and are unfixable it seems a > bit pointless maintaining this java interface. > Yes Java only needed for PTPicker and PTEditor. And probably pointless. My main goal is to have the tools built for both CMD and GUI. I also want to release new versions of the PS plugins. > I'm not sure if removing java support changes the ABI, I would hate > to have to bump the soname again just for this. > Maybe it is time to move the java files to their own folder. I can probably give up on building as a dll. Lets get the current release out first. I wont be checking any of this into trunk soon. -- Jim Watters http://photocreations.ca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Tue 06-Oct-2009 at 16:27 -0400, Yuval Levy wrote: >Jim Watters wrote: >> Last night I was playing with updating my MSVC projects for libpano to >> create multiple binaries. I want to build .lib or .dll for both >> command line or GUI, as release or debug. The .dll built with java >> support. The .lib without java support. I have managed to figure out >> many things but still much to do. I want to support 32 and 64bit too. > >is Java still used? what for? how will the dll behave if there is no >Java on the machine? As far as I know it is only used by the ptpicker and pteditor tools, but since they only link to libpano12 and are unfixable it seems a bit pointless maintaining this java interface. I'm not sure if removing java support changes the ABI, I would hate to have to bump the soname again just for this. -- 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: windows binary release
thanks for the info, Jim. Jim Watters wrote: > Last night I was playing with updating my MSVC projects for libpano to > create multiple binaries. I want to build .lib or .dll for both > command line or GUI, as release or debug. The .dll built with java > support. The .lib without java support. I have managed to figure out > many things but still much to do. I want to support 32 and 64bit too. is Java still used? what for? how will the dll behave if there is no Java on the machine? Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
Yuval Levy wrote: >> I was having some difficulties building libpano, as posted earlier. >> Haven't solved them yet. But I need sleep too. >> > take your time. I guess you tried building libpano with CMake? > > My recent experience, with both CMake and the MSVC projects, was when > Jim asked for a Windows binary of the layout codeline. At first nothing > worked. Then Jim fixed it, at least partially. The overall build would > still fail but the library (which is what is needed for Hugin) built > well and worked well. I am not sure if in the meantime the building of > the tools themselves has improved in Windows (and the tools themselves; > and the related perl Panotools-scripts by Bruno are something to > consider when expanding the installer). > > It would be nice if we can get the Windows distribution up to par for > Christmas, in time for (hopefully) a "big bang XYZ release". > > Yuv > Last night I was playing with updating my MSVC projects for libpano to create multiple binaries. I want to build .lib or .dll for both command line or GUI, as release or debug. The .dll built with java support. The .lib without java support. I have managed to figure out many things but still much to do. I want to support 32 and 64bit too. I am concatenating the .def file together depending on what is bing built. Once I have it figured out I will post a patch. I don't know about CMake files. So I'll leave that to someone else. -- Jim Watters jwatt...@photocreations.ca http://photocreations.ca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
allard wrote: >> you can find the different versions of enblend and enfuse in my >> recently posted binary > > THX for those. I'll try to test them and incorporate them. Will take > me a bit of time. there is some thinking to do on how to integrate this properly into the build. currently, the build system expect one folder in the SDK, and in that folder it expects a distribution of enblend, which in the old day was a single folder with two executables, enblend.exe and enfuse.exe; and some sripts and texts. this won't work if there are many variations of enblend and enfuse. Enblend's own packaging system is not ready for that either. IIRC correctly what I saw on Windows when I built them, the different targets would overwrite each other in the INSTALLDIR. They are produced in subfolders of src: "Release", "Release (GPU)", "Release (GPU,SSE2)" and so on. Add to it that Enblend has a new CMake build system which I hope will become the official way of building Enblend because IMO it is better maintainable in the long-run for multi-platform use. But AFAIK the CMake build system in Enblend does not produce all of these different targets. For somebody building for their own machine, this is overkill / not necessary. One will chose and build only the right version for him. For distribution there was a lot of manual work involved: build a specific target, harvest the produced enblend.exe and enfuse.exe. Rename them manually. We need to bridge between the (moving) Enblend build process and the (also moving) Hugin build process, with the end in mind to offer the Window user an option in the installer to select one version of Enblend/Enfuse to install (and some guidance for the choice). > I commited my script as I have used it for 0.8 snapshots (plus update > to cmakelists in installer directory). First commit ever, another > milestone. They are of course not completely up to date but i can now > adapt them for everyone as I go along. well done! > I do have to say that my version of the SDK is not the same anymore as > Guido's, as I had to add or change a few things so I'm not 100% sure > this will work with the current SDK. that's what we have to zero in on. We have to provide an upgrade path for the SDK; and keep it in sync with the build system and the installer. Guido and Ryan were talking of a scripted SDK building; Ad has a scripted Hugin building; you have the installer script. All the pieces will be there and can be made work with a little bit of coordination. > I think panomatic wasn't in the > SDK but it was very easy to add so I did that. There were some patches > here and there as well. no panomatic is definitely not in the SDK. and it adds "short term" problems - until the patent (SURF) expires. I think we need to follow the lead of the Mac OSX builds and make separate installers for the CP generators. But I also think that this should come after the SDK-build, binaries-build and installer compilation work well enough in sync. not now. for now leave it as it is, but leave it "broken" (i.e. don't add panomatic itself). > I was having some difficulties building libpano, as posted earlier. > Haven't solved them yet. But I need sleep too. take your time. I guess you tried building libpano with CMake? My recent experience, with both CMake and the MSVC projects, was when Jim asked for a Windows binary of the layout codeline. At first nothing worked. Then Jim fixed it, at least partially. The overall build would still fail but the library (which is what is needed for Hugin) built well and worked well. I am not sure if in the meantime the building of the tools themselves has improved in Windows (and the tools themselves; and the related perl Panotools-scripts by Bruno are something to consider when expanding the installer). It would be nice if we can get the Windows distribution up to par for Christmas, in time for (hopefully) a "big bang XYZ release". Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
> What "works for me" does not necessarily "work for them". I was more commenting on my own incompentence as a tester than anything else :-) > > > you can find the different versions of enblend and enfuse in my > recently posted binary of the layout branch. No OpenMP versions yet > (maybe somebody who has OpenMP can build them and contribute them to > the effort?) THX for those. I'll try to test them and incorporate them. Will take me a bit of time. > > IIRC you have write access to SVN. I suggest doing the development/ > implementation there. The current status, from my perspective, is that > in the Hugin SVN we have installer files for 0.7.0. Ad posted here on > the list his (latest?) version which he used for 2009.2. You have your > personal version. I'd like to see all of them in a collaborative > effort on SVN. Then it will also be easier to sync the installer with > Ad's scripted build system and with Guido and Ryan's efforts to update > the SDK. > I commited my script as I have used it for 0.8 snapshots (plus update to cmakelists in installer directory). First commit ever, another milestone. They are of course not completely up to date but i can now adapt them for everyone as I go along. I do have to say that my version of the SDK is not the same anymore as Guido's, as I had to add or change a few things so I'm not 100% sure this will work with the current SDK. I think panomatic wasn't in the SDK but it was very easy to add so I did that. There were some patches here and there as well. I was having some difficulties building libpano, as posted earlier. Haven't solved them yet. But I need sleep too. Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
some errors report missing getopt functions (described at http://www.gnu.org/s/libc/manual/html_node/Using-Getopt.html#Using-Getopt). it looks like a missing library or incorrect path to the library. however, i don't know anything about Hugin build process so i'm not able to say exactly how to fix it. regarding the other functions, i don't recognize them. hopefully someone else. best regards camlost On 5 říj, 08:37, allard wrote: > I'm trying to build libpano from svn 1096 but MSVC is giving me some > errors. First there was an issue with a file not found: fftn.c. I > found some lines of code in there that gave me a hint that __FILE__ > might give some problems so I managed to fix that. But now I run into > something that is beyond my extremely limited coding abilities. Here's > the output from MSVC that keeps showing up: > > 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external > symbol _optind > 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external > symbol _optarg > 12>pano13.lib(PTcommon.obj) : error LNK2019: unresolved external > symbol _getopt referenced in function _panoCroppingMain > 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external > symbol _hDllInstance > 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external > symbol _wndOwner > 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external > symbol _CenterDialog referenced in function _set...@16 > 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external > symbol _SetWindowOwner referenced in function _set...@16 > > Ideas anyone? > > Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Oct 5, 8:25 am, cspiel wrote: > Yuv - > > On Oct 5, 1:42 am, Yuval Levy wrote: > --- snip --- > > > I don't know what Christoph plans are for enblend - he's the one who > > has moved enblend forward to pre-release 4.0. I don't know what is > > considered critical to be fixed before release. > > You could ask this Christoph guy what his plans with > Enblend/Enfuse are, can't you? IIRC this Dr. House guy told me about having other interests at the moment. IIRC he also reads this list, and I thought that if he had news he'll share it with us here. If you are missing my nagging, I'll go fetch the Dr. Cuddy outfit (is at the dry cleaner preparing for the Halloween) and be with you in a minute ;-) I also have some other things on my todo list for enblend that we discussed (have not forgot it, just had other things keeping me busy). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Oct 5, 12:43 am, allard wrote: > > AFAIK glut.dll should not be necessary. policy on Windows is to link > > statically to avoid problems with missing / disappearing dlls and other > > nice side effects of lack of proper package management. > > > Possibly a bug in the build system that links nona-gpu dynamically. > > OK, is that a line in a Cmake text file or is it more hidden in the > code? I'll report it as a bug. CMake, I think. Thanks for the bug report. > I had forgotten completely about the libpano issues. I was using a > version that I think I got from Guido's most recent SDK. I'll add > libpano in my SVN system and build the newer version. What exactly do > you mean when you say: use the CMake build? I don't recall the exact status of libpano from Guido's most recent SDK in terms of stability. In terms of features Hugin 2009.4 may still be OK linked against it, but latest when we'll introduce the layout version it will not. Windows users have an interest to follow the development of libpano closely, like OSX and Linux users already do. The CMake build make it easier to build libpano. The instructions are similar to those for the Hugin CMake build. IIRC the Ubuntu ones are updated. If the Windows ones are not, you can update them while in the process of building. > 2.5.1 on the sourceforge page is the RC1 version. I built that and it > worked without problems. I have missed the release notes. Yes, 2.5.1_rc1 is what you want to use and should work w/o problems. > Although I have to be honest and say I never > noticed the problems with 2.5.0 either. What "works for me" does not necessarily "work for them". There are plenty of bug reports against 2.5.0 and 2.5.2 both in the tracker and here: and there was already enough in depth analysis to determine that both are not good enough, even if they may be good enough for an individual user on a specific machine with some limited test cases. 2.5.0 worked well for me with my simple 6-fisheye 360x180 but crashed a 30 images project (and I now have 300 images projects to test too). > I haven't looked at Ad's scripts yet, but I have my own customized > installer scripts that I could adapt. I remember I sent Ad my version > when he first started to make installers but I don't know what he has > changed since then. I think the 'choice' solution is good. I'll see if > I can figure out how to implement that, if not I'll be back with > questions. I would suggest also to add an option to install multiple > versions and let the user choose through the 'use alternative enblend > program' preference. Where do I get the different versions of > enblend? you can find the different versions of enblend and enfuse in my recently posted binary of the layout branch. No OpenMP versions yet (maybe somebody who has OpenMP can build them and contribute them to the effort?) IIRC you have write access to SVN. I suggest doing the development/ implementation there. The current status, from my perspective, is that in the Hugin SVN we have installer files for 0.7.0. Ad posted here on the list his (latest?) version which he used for 2009.2. You have your personal version. I'd like to see all of them in a collaborative effort on SVN. Then it will also be easier to sync the installer with Ad's scripted build system and with Guido and Ryan's efforts to update the SDK. Yuv > > Thanks, Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
Yuv - On Oct 5, 1:42 am, Yuval Levy wrote: --- snip --- > I don't know what Christoph plans are for enblend - he's the one who > has moved enblend forward to pre-release 4.0. I don't know what is > considered critical to be fixed before release. You could ask this Christoph guy what his plans with Enblend/Enfuse are, can't you? /cls --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Sun 04-Oct-2009 at 19:42 -0400, Yuval Levy wrote: > >Furthermore, at runtime, the pre-relese enblend breaks the backward >compatibility of the command line switches. The critical one is the -w >switch. > >There are two ways to fix it: >(1) fix enblend to be backward compatible with the switches >(2) fix hugin to issue the proper new command line > >I personally prefer (2). (1) would set a precedent that makes it more >difficult to improve/expand enblend. I don't think that there should be >a rule for enblend to be backward compatible for command line switches. Eh? I thought it was clear that this is unintended enblend behaviour: http://sourceforge.net/tracker/index.php?func=detail&aid=2853823&group_id=77506&atid=550441 ..and moreover only effects Windows builds: http://sourceforge.net/tracker/?func=detail&aid=2854858&group_id=123407&atid=696409 -- 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: windows binary release
I'm trying to build libpano from svn 1096 but MSVC is giving me some errors. First there was an issue with a file not found: fftn.c. I found some lines of code in there that gave me a hint that __FILE__ might give some problems so I managed to fix that. But now I run into something that is beyond my extremely limited coding abilities. Here's the output from MSVC that keeps showing up: 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol _optind 12>pano13.lib(PTcommon.obj) : error LNK2001: unresolved external symbol _optarg 12>pano13.lib(PTcommon.obj) : error LNK2019: unresolved external symbol _getopt referenced in function _panoCroppingMain 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol _hDllInstance 12>pano13.lib(PTDialogs.obj) : error LNK2001: unresolved external symbol _wndOwner 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol _CenterDialog referenced in function _set...@16 12>pano13.lib(PTDialogs.obj) : error LNK2019: unresolved external symbol _SetWindowOwner referenced in function _set...@16 Ideas anyone? Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
On Oct 4, 4:42 pm, Yuval Levy wrote: > > AFAIK glut.dll should not be necessary. policy on Windows is to link > statically to avoid problems with missing / disappearing dlls and other > nice side effects of lack of proper package management. > > Possibly a bug in the build system that links nona-gpu dynamically. OK, is that a line in a Cmake text file or is it more hidden in the code? I'll report it as a bug. > > > Anyway, as far as I can remember the main problem in bringing out a > > windows package (including dependencies) was enblend. > > actually it was three main issues with dependencies; and the enblend > dependency got more complex: > > * libpano: there have been a couple of glitches. things seems to be > solved / stable with the current SVN. The previous two beta releases > where broken. Bruno intends to issue a new beta release soon, beta3 if I > am not mistaken. => build against beta3 when it is out. Until it is out, > build against most current SVN (trunk at revision 1096 works). Use the > CMake build. > I had forgotten completely about the libpano issues. I was using a version that I think I got from Guido's most recent SDK. I'll add libpano in my SVN system and build the newer version. What exactly do you mean when you say: use the CMake build? > * autopano-sift-c: 2.5.0 suffer of major memory leaks and crashes often. > 2.5.2 has other, major issues. 2.5.1 is a compromise interim release > because we do not know when 2.5.2 will be fixed. 2.5.1 has not yet been > released. => build from 2.5.1 beta tarball when it will be released. > Until it is out, build from SVN 2.5.1 codeline. 2.5.1 on the sourceforge page is the RC1 version. I built that and it worked without problems. Although I have to be honest and say I never noticed the problems with 2.5.0 either. No crashes and if there were memory leaks they were not severe enough to cause real problems. I also built SVN version 4250, but it did not work, By that I mean that it does build, I tried it with hugin, it seemed to run normally, but no control points were found in a test sequence. I think an error screen appeared for 0.1 second after the APSC run but I couldn't read it. > > * enblend. .. > > The safe, conservative solution is to use the enblend/enfuse that are in > the 0.7.0 binaries until the issues are sorted out. The better solution > is to implement the choice of enblend (GPU, OpenMP, etc) in the > installer, and deliver the 3.x binaries that were shipped with 0.7.0 as > an additional choice. I still have to look into the upddated installer > scripts that Ad published here a week or so ago. I haven't looked at Ad's scripts yet, but I have my own customized installer scripts that I could adapt. I remember I sent Ad my version when he first started to make installers but I don't know what he has changed since then. I think the 'choice' solution is good. I'll see if I can figure out how to implement that, if not I'll be back with questions. I would suggest also to add an option to install multiple versions and let the user choose through the 'use alternative enblend program' preference. Where do I get the different versions of enblend? Thanks, Allard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: windows binary release
Hi Allard, welcome back ;-) allard wrote: > I built 2009.2 on my system, as well as ap-sift-c 2.5.1, they both > seem to work fine on the limited testing I've done. Two small glitches > involving glut: 1 glut dll is not installed into bin directory by > MSVC. AFAIK glut.dll should not be necessary. policy on Windows is to link statically to avoid problems with missing / disappearing dlls and other nice side effects of lack of proper package management. Possibly a bug in the build system that links nona-gpu dynamically. > Anyway, as far as I can remember the main problem in bringing out a > windows package (including dependencies) was enblend. actually it was three main issues with dependencies; and the enblend dependency got more complex: * libpano: there have been a couple of glitches. things seems to be solved / stable with the current SVN. The previous two beta releases where broken. Bruno intends to issue a new beta release soon, beta3 if I am not mistaken. => build against beta3 when it is out. Until it is out, build against most current SVN (trunk at revision 1096 works). Use the CMake build. * autopano-sift-c: 2.5.0 suffer of major memory leaks and crashes often. 2.5.2 has other, major issues. 2.5.1 is a compromise interim release because we do not know when 2.5.2 will be fixed. 2.5.1 has not yet been released. => build from 2.5.1 beta tarball when it will be released. Until it is out, build from SVN 2.5.1 codeline. * enblend. there are mixed reports about this one in terms of functionality / crash. in my (limited) experience on Windows pre-release 4.0 is better than any 3.x. And also on Ubuntu I use mainly pre-release 4.0. I built enblend pre-release 4.0 pretty close to the current tip (just before the CMake and MSVC builds break). The added complexity is that there are now different builds of enblend-enfuse that suit different needs. I could not build the OpenMP versions, which are recommended for multi-core CPUs, because I was not able to find Microsoft's OpenMP libraries. Thomas Modes had more luck, although when I used the same installer as he did, OpenMP did not install. There are GPU optimized versions; SSE2 optimized versions; versions without ImageCache; and combinations. This will require a change to the installer, because so far only the user knows if he has a better GPU or a better multi-core CPU to install the GPU or the OpenMP version; and for really old CPUs the user will choose the version without SSE2 support. All at install time. Furthermore, at runtime, the pre-relese enblend breaks the backward compatibility of the command line switches. The critical one is the -w switch. There are two ways to fix it: (1) fix enblend to be backward compatible with the switches (2) fix hugin to issue the proper new command line I personally prefer (2). (1) would set a precedent that makes it more difficult to improve/expand enblend. I don't think that there should be a rule for enblend to be backward compatible for command line switches. On Linux we solve this very easily by using the package manager and setting the required version of enblend according to what our Hugin version outputs to the Makefile. On Windows... well, it's up to the builder to match a working version of enblend with the version of Hugin that is in the installer. The safe, conservative solution is to use the enblend/enfuse that are in the 0.7.0 binaries until the issues are sorted out. The better solution is to implement the choice of enblend (GPU, OpenMP, etc) in the installer, and deliver the 3.x binaries that were shipped with 0.7.0 as an additional choice. I still have to look into the upddated installer scripts that Ad published here a week or so ago. > From what I've > read while catching up this is still not solved. no, but we're getting there. > Before I stopped working on it, I had almost finished a release > package with an old version of enblend (the one distributed with the > 0.7 binary). Should I go ahead and prepare a test version of a > complete package of hugin with this old version, so the package can be > tested by some of you and then released to the public? Or are there > reasons to wait a little until the enblend issue is solved? I don't know how long it will take to solve the enblend issues. Ideally we'd have a release of enblend, but this is beyond my control. I don't know what Christoph plans are for enblend - he's the one who has moved enblend forward to pre-release 4.0. I don't know what is considered critical to be fixed before release. "released to the public" - you can always release from your website or from other third party space. and publish officially on the Hugin Sourceforge space when you feel that the build has achieved the necessary quality. Yuv --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group
