Hi Seth, Sorry.
you are completely right. I read the comment and saw the hash mark and jumped too fast to conclusions. I'll have a look again this weekend. Harry 2009/4/16 Seth Berrier <seth.berr...@gmail.com> > Are you sure? > > In C/C++ lines are commented out only with '//' or with '/* ... */'. > > Statements pre-pended with a '#' are preprocessor directives. You have > things like: > > #include > #define > #ifdef > #else > #endif > #pragma > > and many others, including: > > #undef > > '#undef XXX' will undefine the preprocessor macro 'XXX' if it is defined ( > http://www.cppreference.com/wiki/preprocessor/undef). > > As it stands right now, lm.h will always undefine 'HAVE_LAPACK'. I assume > in the original distribution of LevMar this line looked like this: > > //#undef HAVE_LAPACK // uncomment this to force not using LAPACK > > With the extra '//' at the beginning. For whatever reason, it has already > been uncommented in the hugin-levmar version forcing levmar to not use > LAPACK no matter what. Aside: we might want to ask why ... this seems > intentional and perhaps those who understand the math better than we had > good reasons. > > For fun, I went ahead and removed this on my system and added the line > '#define HAVE_LAPACK' just below it (just a hack). The system compiled > happily (since there are links to LAPACK in /usr on OS X) but I haven't > tried to run Hugin just yet to see if it really has everything it needs for > LAPACK. > > Note: I think '#' is used for comments in shell scripts and the like but > not in C/C++. > > Seth > > P.S. Sorry for hijacking your thread RickyRicky. None of this is much > help for your problem I'm afraid. > > > On Thu, Apr 16, 2009 at 9:25 AM, Harry van der Wolf <hvdw...@gmail.com>wrote: > >> Hi Seth, >> >> thanks for looking into it. >> >> However, your statement that lm.h undefines it, is not correct. >> the line is: >> >> #undef HAVE_LAPACK // uncomment this to force not using LAPACK >> >> As soon as you remove the # it will be an undef statement. Currently it is >> only a remark, so currently it will use lapack provided it can be found. >> >> Hoi, >> Harry >> >> >> 2009/4/16 Seth Berrier <seth.berr...@gmail.com> >> >>> Okay, it looks like LevMar (the Levenburg-Marquardt (sp) library) is >>> what's looking for LAPACK. It uses the preprocesser define 'HAVE_LAPACK' to >>> indicate that it is available. >>> >>> If you look in 'lm.h' the code specifically UN-defines HAVE_LAPACK so >>> even if you were to define it, this line would defeat your define (very odd >>> choice). So, perhaps this might be doing it. You just need to go into lm.h >>> and comment out line 23. >>> >>> Of course, this by itself won't fix the problem. You need to find LAPACK >>> on the drive and provide the library paths and header paths to cmake but it >>> sounds like you have that going already. If you can find them then you just >>> need to add -DHAVE_LAPACK to the compiler flags for the libhuginlevmar.a >>> target and comment out that line in lm.h. >>> >>> Hope that helps. >>> Seth >>> >>> >>> On Thu, Apr 16, 2009 at 8:27 AM, Seth Berrier <seth.berr...@gmail.com>wrote: >>> >>>> I'll take a look. No idea if I can help but it sounds like something I >>>> might be able to figure out. >>>> >>>> Seth >>>> >>>> >>>> On Thu, Apr 16, 2009 at 1:45 AM, Harry van der Wolf >>>> <hvdw...@gmail.com>wrote: >>>> >>>>> Lapack is simply not correctly detected in hugin (actually in levmar). >>>>> I dug a little deeper and the routines to correctly detect BLAS and Lapack >>>>> are simply not there. Lapack and BLAS are available via the Accelerate >>>>> framework and via the vecLib framework on MacOSx. To maintain >>>>> compatibility >>>>> they are even linked to in /usr/lib. >>>>> To test I also built hugin on Ubuntu with lapack (BLAS) installed (libs >>>>> and dev) and also there it is not detected. >>>>> I already tried to implement the FindBLAS.cmake and FindLapack.cmake >>>>> modules to detect it correctly but can't make it work (yet?). I know I'm >>>>> on >>>>> the correct route but I simply lack the programming skills to make it a >>>>> success. I'm a builder, not a programmer. >>>>> >>>>> The warnings you get when compiling via cmake is what everyone gets on >>>>> every platform (as far as I can tell now). I can only say that all my >>>>> builds >>>>> are also always using LU instead of Lapack/BLAS. >>>>> I will try to get it working but if I can't get it to work very soon, I >>>>> will simply file a bug and hope a programmer can take a look. >>>>> >>>>> Harry >>>>> >>>>> >>>>> >>>>> 2009/4/15 RickyRicky <meles...@gmail.com> >>>>> >>>>> >>>>>> Hello Harry, >>>>>> >>>>>> No, I do not have vigra or jhead installed as a part of MacPorts... >>>>>> >>>>>> BigDaddy:Application meleschi$ port installed | grep -i vigra >>>>>> BigDaddy:Application meleschi$ port installed | grep -i jhead >>>>>> >>>>>> Thanks... Anything else I can check? >>>>>> >>>>>> Ricardo >>>>>> >>>>>> On Apr 13, 1:29 pm, Harry van der Wolf <hvdw...@gmail.com> wrote: >>>>>> > Hi Ricardo, >>>>>> > >>>>>> > Did you install vigra and/or jhead via MacPorts for some reason? If >>>>>> you did, >>>>>> > please deactivate them (sudo port deactivate vigra; sudo port >>>>>> deactivate >>>>>> > jhead) and reconfigure and recompile Hugin. >>>>>> > If the configure script finds vigra "outside" hugin it will use >>>>>> that one. >>>>>> > >>>>>> > You can find installed packages by running "port installed" or "port >>>>>> > installed | grep <package>". >>>>>> > The deactivate command will not uninstall the packages. It will only >>>>>> remove >>>>>> > them from the install libraries. If you want them back you can >>>>>> simply use >>>>>> > "sudo port activate <package>". >>>>>> > >>>>>> > Hoi, >>>>>> > Harry >>>>>> > >>>>>> > 2009/4/13 RickyRicky <meles...@gmail.com> >>>>>> > >>>>>> > >>>>>> > >>>>>> > > Hey Seth, >>>>>> > >>>>>> > > Thanks for the tip on running Hugin from the command line. I did >>>>>> so, >>>>>> > > and here are the lines before the big crash. I hope someone can >>>>>> > > recognize my problem!: >>>>>> > >>>>>> > > Determining placement of the images: 53% >>>>>> > > Number of images 2 >>>>>> > > Hugin(77452,0xa06cd830) malloc: *** error for object 0x2a2c200: >>>>>> double >>>>>> > > free >>>>>> > > *** set a breakpoint in malloc_error_break to debug >>>>>> > > Optimizing Variables >>>>>> > > Strategy 1 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 0 iteration(s): 801.152704448697 units >>>>>> > > Strategy 1 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 1 iteration(s): 801.019725960169 units >>>>>> > >>>>>> > > Optimizing Variables >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 0 iteration(s): 57.1154776303789 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 1 iteration(s): 56.9698889445181 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 2 iteration(s): 8.60724772529945 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 3 iteration(s): 7.72758159217231 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 4 iteration(s): 6.58494386005708 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 5 iteration(s): 5.40204786941155 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 6 iteration(s): 3.79597859019421 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 7 iteration(s): 1.66872838105291 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 8 iteration(s): 0.479946564550839 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 9 iteration(s): 0.479481987047642 units >>>>>> > > Strategy 2 >>>>>> > > Average (rms) distance between Controlpoints >>>>>> > > after 10 iteration(s): 0.479481986986529 units >>>>>> > >>>>>> > > Bus error >>>>>> > >>>>>> > > Thanks, >>>>>> > > Ricardo Meleschi >>>>>> > >>>>>> > > On Apr 13, 10:58 am, Seth Berrier <seth.berr...@gmail.com> wrote: >>>>>> > > > Hmm, well I got this compiler problem while compiling on my >>>>>> MacBook >>>>>> > > > (incidentally, I didn't think 10.5 would run on powerpc arch >>>>>> anymore, >>>>>> > > glad >>>>>> > > > to know). However, I ignored the error message and things still >>>>>> seem to >>>>>> > > > work okay for me. The Hugin.app and all the supporting >>>>>> applications are >>>>>> > > > built and installed correctly. I had to monkey with the path >>>>>> setting a >>>>>> > > > little bit. For that, you can check out this >>>>>> > > > thread< >>>>>> > > >>>>>> http://groups.google.com/group/hugin-ptx/browse_thread/thread/3efbca4.. >>>>>> .>. >>>>>> > > > However, the path problem will come up when you do auto control >>>>>> point >>>>>> > > > detection or with the final stitch as this is when external >>>>>> programs are >>>>>> > > > used. I don't think this woulod cause problems at position >>>>>> optimization. >>>>>> > >>>>>> > > > My best advice would be to run hugin from the terminal shell >>>>>> (just run >>>>>> > > <path >>>>>> > > > to hugin.app>/Hugin.app/Contents/MacOS/Hugin) You might get >>>>>> more >>>>>> > > messages >>>>>> > > > from the terminal output. >>>>>> > >>>>>> > > > Seth >>>>>> > >>>>>> > > > On Mon, Apr 13, 2009 at 9:34 AM, RickyRicky <meles...@gmail.com> >>>>>> wrote: >>>>>> > >>>>>> > > > > Gents, >>>>>> > >>>>>> > > > > I've been working on compiling Hugin these last few days and >>>>>> have >>>>>> > > > > succeeded in getting it compiled, but for some reason whenever >>>>>> I run >>>>>> > > > > Hugin and attempt to align images, hugin always crashes when >>>>>> > > > > determining placement of the image, after Celeste is run. I >>>>>> don't see >>>>>> > > > > a log file being generated anywhere. I'm not too familiar >>>>>> with Hugin >>>>>> > > > > so I may be looking in the wrong places. >>>>>> > >>>>>> > > > > When I review my compile log, I see I was having problems with >>>>>> LAPACK: >>>>>> > > > > ----------- >>>>>> > > > > [ 3%] Building CXX object >>>>>> src/foreign/jhead/CMakeFiles/huginjhead.dir/ >>>>>> > > > > exif.o >>>>>> > > > > In file included from >>>>>> /Users/meleschi/src/hugin/src/foreign/levmar/ >>>>>> > > > > misc.c:42: >>>>>> > > > > >>>>>> /Users/meleschi/src/hugin/src/foreign/levmar/misc_core.c:562:2: >>>>>> > > > > warning: #warning LAPACK not available, LU will be used for >>>>>> matrix >>>>>> > > > > inversion when computing the covariance; this might be >>>>>> unstable at >>>>>> > > > > times >>>>>> > > > > In file included from >>>>>> /Users/meleschi/src/hugin/src/foreign/levmar/ >>>>>> > > > > misc.c:57: >>>>>> > > > > >>>>>> /Users/meleschi/src/hugin/src/foreign/levmar/misc_core.c:562:2: >>>>>> > > > > warning: #warning LAPACK not available, LU will be used for >>>>>> matrix >>>>>> > > > > inversion when computing the covariance; this might be >>>>>> unstable at >>>>>> > > > > times >>>>>> > > > > [ 3%] Building C object >>>>>> src/foreign/levmar/CMakeFiles/huginlevmar.dir/ >>>>>> > > > > lmlec.o >>>>>> > > > > /Users/meleschi/src/hugin/src/foreign/levmar/lmlec.c:39:2: >>>>>> warning: >>>>>> > > > > #warning Linearly constrained optimization requires LAPACK and >>>>>> was not >>>>>> > > > > compiled! >>>>>> > > > > ------------- >>>>>> > >>>>>> > > > > I've searched on the above problem but haven't found exact >>>>>> > > > > instructions as to how to resolve it. The closest I've found >>>>>> is this: >>>>>> > > > > ----- >>>>>> > > > > I had the same problem with Xcode with OS 10.5. In OS 10.5 >>>>>> LAPACK is >>>>>> > > > > part of the Accelerate framework. >>>>>> > > > > I put this into the project options >>>>>> > > > > OTHER_LDFLAGS = "-framework Accelerate" >>>>>> > > > > I'm not sure if this is the correct syntax but it did get rid >>>>>> of the >>>>>> > > > > LAPACK warnings. >>>>>> > > > > ---- >>>>>> > >>>>>> > > > > Where exactly do I put the OTHER_LDFLAG option? I've tried >>>>>> multiple >>>>>> > > > > places with no joy. >>>>>> > >>>>>> > > > > I'm running 12 GB of ram on a Dual 2 GHz PowerPC G5 with OSX >>>>>> 10.5.6 >>>>>> > > > > fully patched. >>>>>> > >>>>>> > > > > The svn revision is 3784. I did follow the instructions on >>>>>> > > > >http://wiki.panotools.org/Hugin_Compiling_OSX. >>>>>> > >>>>>> > > > > Here's the info on the ports I have installed... >>>>>> > >>>>>> > > > > BigDaddy:Application meleschi$ sudo port info boost tiff jpeg >>>>>> libpng >>>>>> > > > > wxWidgets subversion openexr exiv2 glew >>>>>> > > > > boost @1.38.0 (devel) >>>>>> > > > > Variants: darwin, darwin_9, debug, docs, graphml, icu, >>>>>> openmpi, >>>>>> > > > > python24, python25, python26, st >>>>>> > >>>>>> > > > > -- >>>>>> > > > > tiff @3.8.2, Revision 3 (graphics) >>>>>> > > > > Variants: macosx, universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > jpeg @6b, Revision 3 (graphics) >>>>>> > > > > Variants: universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > libpng @1.2.35 (graphics) >>>>>> > > > > Variants: universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > wxWidgets @2.8.10 (graphics, devel) >>>>>> > > > > Variants: debug, nonmonolithic, universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > subversion @1.6.1 (devel) >>>>>> > > > > Variants: bash_completion, darwin_7, disable_keychain, >>>>>> > > > > mac_os_x_server_mod_dav_svn, mod_dav_svn, no_bdb, no_neon, >>>>>> tools, >>>>>> > > > > unicode_path >>>>>> > >>>>>> > > > > -- >>>>>> > > > > openexr @1.6.1, Revision 1 (graphics) >>>>>> > > > > Variants: universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > exiv2 @0.18.1 (graphics) >>>>>> > > > > Variants: universal >>>>>> > >>>>>> > > > > -- >>>>>> > > > > glew @1.5.1, Revision 1 (graphics, devel) >>>>>> > > > > Variants: universal >>>>>> > >>>>>> > > > > Thanks for any help! >>>>>> > > > > Ricardo >>>>>> > >>>>>> > > > -- >>>>>> > > > seth.berr...@gmail.com >>>>>> > > > Graduate Research Assistant >>>>>> > > > University of Minnesota >>>>>> > > > Digital Technology Center >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> seth.berr...@gmail.com >>>> >>>> Graduate Research Assistant >>>> University of Minnesota >>>> Digital Technology Center >>>> >>>> >>> >>> >>> -- >>> seth.berr...@gmail.com >>> Graduate Research Assistant >>> University of Minnesota >>> Digital Technology Center >>> >>> >>> >>> >> >> >> > > > -- > seth.berr...@gmail.com > Graduate Research Assistant > University of Minnesota > Digital Technology Center > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
