RE: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64
Sorry, I should have reviewed what I sent :) As of 4.0, Enblend/Enfuse transitioned to a CMake build system. So the patches should no longer be necessary, you should be able to just CMake it. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Aron H Sent: Thursday, July 01, 2010 4:23 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64 Lots of progress. I'm catching up with Tom Glastonbury - I have successfully compiled the main Hugin project, release and debug win32, and release x64. I've updated the wiki page: http://wiki.panotools.org/Hugin_SDK_%28MSVC_2010%29 except for the final stages to compile Hugin, because there's not a spot. I'll make one... I've used the pre-compiled version of Enblend 4.0, so it's win32. One of the recurring requests on the list is for x64 builds, but the last ones I see, from Ryan Sleevi: http://groups.google.com/group/hugin- ptx/browse_thread/thread/4d19acdfdce90731/f14270cf01284a8d and download-able here: http://ryan.sleevi.com/files/enblend-enfuse-4.0/ have the problem with the -w parameter - if I drop in the x64 openMP enblend, it says the -w option -fXXX is invalid. What are the most current instructions for building enblend/enfuse for windows x64? This? http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Enblend_and_Enfuse or this? http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK Thanks for your help! Aron -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64
What if it's neither? ;-) The patch at the first link (part of the Hugin SDK / MSVC 2008 instructions) is more recent. If the patch doesn't apply cleaning, you can see what the patch does at http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)_Patches#Enblend.2FEnfuse.2Fl ibxmi . That was required for 3.2 - it may not be required for 4.0. Hope that helps. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Aron H Sent: Thursday, July 01, 2010 4:23 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64 Lots of progress. I'm catching up with Tom Glastonbury - I have successfully compiled the main Hugin project, release and debug win32, and release x64. I've updated the wiki page: http://wiki.panotools.org/Hugin_SDK_%28MSVC_2010%29 except for the final stages to compile Hugin, because there's not a spot. I'll make one... I've used the pre-compiled version of Enblend 4.0, so it's win32. One of the recurring requests on the list is for x64 builds, but the last ones I see, from Ryan Sleevi: http://groups.google.com/group/hugin- ptx/browse_thread/thread/4d19acdfdce90731/f14270cf01284a8d and download-able here: http://ryan.sleevi.com/files/enblend-enfuse-4.0/ have the problem with the -w parameter - if I drop in the x64 openMP enblend, it says the -w option -fXXX is invalid. What are the most current instructions for building enblend/enfuse for windows x64? This? http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Enblend_and_Enfuse or this? http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK Thanks for your help! Aron -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64
They're all there in SVN. Perhaps the .tar.gz you downloaded excluded them? See http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/tools/ , I see all the tools referenced by the .sln. The patch may be out of date - though it was just a patch to update the projects for VS2008, IIRC, and looks like it's been unnecessary for the trunk projects for a while anyways. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Aron H Sent: Wednesday, June 30, 2010 2:39 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64 I've made lots of progress, but I'm stuck on PanoTools. The current 10.2 release process intends to release libpano13 2.9.17 so I downloaded that .tar.gz from the sourceforge site. I can't find instructions to build it with MSVC that work. Looking at the current instructions to build the SDK: http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Panorama_Tools the patch that worked for 2.9.14 doesn't work for 2.9.17 because the .sln file and all the .vcproj files for the tools, like PTBlender or PTCrop, don't exist - libpano.vcproj is the only one i see. Help? Thanks, Aron On Jun 29, 10:57 am, Aron H aron.hel...@gmail.com wrote: Well I'm going to plow ahead, because one advantage has become apparent: x64 targets are immediately available after installing the Win7 SDK, with no additional steps, unlike MSVC 2008. I've started and will be updating this wiki page:http://wiki.panotools.org/Hugin_SDK_%28MSVC_2010%29 Feedback or help appreciated! Aron On Jun 28, 4:34 pm, Tom Glastonbury t...@tomglastonbury.com wrote: On 28/06/2010 7:06 PM, Aron H wrote: Has anyone attempted to compile Hugin or enblend with MSVC 2010 Express? Success or failure? There's no mention in the wiki so far. Aron I had a look at this but stuck to 2008 for now as there didn't seem to be a meaningful advantage in using 2010. Also, it wasn't clear to me if the VS2010 targets in CMake were yet considered a 'release' feature or were still in beta. Tom -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64
I haven't built with the new libpano, but it looks to have transitioned to a CMake based build system since I last looked at it. See http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/CMakeLis ts.txt?revision=1268view=markup It also indicates you don't have to have Java, so that may further explain. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Aron H Sent: Wednesday, June 30, 2010 3:11 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Hugin and MSVC 2010 on win32/ x64 Yes, I can confirm that. The .tar.gz also leaves out LocalDefs.vsprops, which lets you avoid setting the WXWIDGETS_HOME environment var globally, if I'm understanding it correctly. Why are the .sln and tool .vcproj files left out of the .tar.gz? I guess because the README.windows file says to build it with mingw, and makes no mention of MSVC. I also didn't have to install or point to the Java SDK. Does that sound correct to you? Aron On Jun 30, 2:45 pm, Ryan Sleevi ryan+hu...@sleevi.com wrote: They're all there in SVN. Perhaps the .tar.gz you downloaded excluded them? Seehttp://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/ t..., I see all the tools referenced by the .sln. The patch may be out of date - though it was just a patch to update the projects for VS2008, IIRC, and looks like it's been unnecessary for the trunk projects for a while anyways. -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Windows 64-bit Build
-Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Tom Glastonbury Sent: Monday, May 17, 2010 6:26 AM To: hugin-ptx@googlegroups.com Subject: Re: [hugin-ptx] Re: Windows 64-bit Build Hi Ryan, Thanks for all that info - I'll digest it and do some research. One comment re NSIS - I certainly wasn't thinking of using it for building, but more in response to Yuv's note about downloading dependent source/binary packages. Windows doesn't come with wget as standard, and I'm not clued-up on some of the more enterprise-oriented scripting stuff that later versions of Windows support, so I was thinking that NSIS would be a useful tool for managing these downloads and for generally bootstrapping the installation (but not the build) of the SDK without requiring the user to download and install several utilities by hand in advance. Have you worked with NSIS before? It's more akin to assembly language than it is a generic scripting. Registers and stacks make up the core language, and it's frustratingly limited. The support for downloading files is rudimentary, and the selection of compression algorithms is limited (which would affect the source downloads). My comments about Python/Perl earlier were meant to demonstrate that it's arguably perfectly reasonable to have some minimal set of dependencies (perhaps even distributed with the file): ex, you need wget and python, and here's the executables, as well as the python script that does the work. Or batch, or what have you. As it relates to the SDK, there isn't much dependency management that needs resolution: If you're going 32-bit, you need packages X, Y, and Z, and if you're wanting to compile 64-bit, you equally need packages X, Y, and Z. The only variation is if you're also wanting to compile enblend/enfuse, as then you'll also need packages A, B, and Z. There is question, at this point, whether that rightfully composes the Hugin SDK or not (really, it's just useful because of the overlap) I don't want to discourage you from pursuing something you're comfortable in, I'd just suggest that NSIS wouldn't be the right tool for the job, which is something Yuv also echoed. Can it be made to do what you want? Possibly - but my own experiences with NSIS tell me it'll be a bit messy. Another note: As it stands, there are a few patches required to 3rd party libs that go beyond .sln file mods, and actually touch source code. From what various people have said, and the convention in use for the do-it-yourself SDK, I understand that the desired option is to download the unmodified source code of a specific version from a given library's main repository, then apply hugin-specific patches if needed. Is there general agreement with this (or at least lack of disagreement)? That's the best strategy, IMO, as it allows for flexibility to change/update the library in the future, and hopefully eliminate the patches once they become unnecessary (most are minor, I think the closest anything gets to 'major' is just patching the wxWidgets config for third-party libraries) -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Windows 64-bit Build
Hey Tom, I'm commenting out of order here, but hopefully it makes sense this way :) The other issue that I've mentioned before is that of producing x64 and Win32 builds from one source tree/SDK. It seems to me that the hugin CMake stuff will differentiate between debug and release libs (at least for some 3rd party dependencies), but not for 32 vs 64 bit - it generally seems to look for and generate link info for somelib.lib and somelibd.lib, but not somelib32.lib, somelib32d.lib, somelib64.lib and somelib64d.lib. Ideally, I'd like to be able to freely choose between any combo of x64/Win32 and Debug/Release within Visual Studio, and have the build process work. Is there a CMake master in the project who might be able to comment on this? As far as I know, I was the first to really pursue the x64 builds. What you're describing re: CMake is arguably a limitation both of CMake itself (and more aptly, it's Visual Studio project generation ability) and a limitation of the CMake recipes (for lack of a better word). The distinction between Debug and Release is something that CMake (tool) itself supports via a language-specific + compiler-specific extension that allows creators of CMake files (FindGLUT, for example) to specify what the filenames will be. No such directives exist for platform-specific definitions (that would allow one to create a .sln that supports Win32 and x64 development). So, at a minimum, we're talking two .sln files (or nmake, if you prefer) generated from a single CMake, with a generic variable tracking target platform (which CMake already sets for you, mind you). However, once there, it becomes a bit tricker. This is because some of the (third-party) libraries use MSVC extensions (namely, #pragma comment(lib, libname)) to specify what the library name will be, which is based on arguments you pass to their (non-CMake) build scripts. I recall it being Boost and STLplus that did this, but it may be more. So you'll still need to be specifying separate build arguments to these tools, and hoping to get them to dump their compiled output into separate directories with a sane naming scheme, which ends up with multiple copies of the include files as well (since they deploy the library once compiled). At one point, right before enblend-enfuse-4.0 was released, I did have a system and a set of batch and CMake files that could compile the entire set of libraries through, but unfortunately I lost those with a drive crash. It involved touching every Find*.cmake and changing the paths/libnames it would check based on whether the target platform was Win32 or x64 - which further involved copying/modifying some of the .cmake files that come with the standard CMake distribution, and copying them into the local repository so they'd be picked up first. I say that to clarify that it's definitely do-able, it just requires a lot of CMake hacking, and even what I had, was so messy that I didn't feel confident committing upstream. I haven't followed up with CMake development, but they may now support multi-platform targeting within a single solution, they just didn't when I last worked on it. Hope that helps. I was interested to read that the idea worked on in the past for the Win SDK is based around a script that downloads 3rd party source/binaries as needed. I'll see what I can find in the Wiki, but notably I'd be interested to know which scripting system was being suggested - perhaps NSIS is a good choice? NSIS is more of an installer system than a build system. The build system needs to be scriptable, capable of applying patches, and executing the various custom build scripts (bjam, for example, for Boost compilation). I've got a lot of experience with NSIS, and feel confident saying This is not the tool you're looking for. My original solution was simply a batch script, but depending on what the lowest common denominator is, you may feel more comfortable with either a Windows Script Host script (VBScript, JScript), a PowerShell script, or even a third-party language like Perl/Python via ActivePerl/ActivePython (though introducing that dependency just for a build-helper script seems overkill) Just let me know if you have any further questions and I'll do what I can to help. -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: hugin image cache larger than 2047MB?
Lukas, Check PreferencesDialog.cpp. On my (slightly out of date) branch, its around lines 907, which has cfg-Write(wxT(/ImageCache/UpperBound), MY_G_SPIN_VAL(prefs_cache_UpperBound) 20); MY_G_SPIN_VAL is a macro to read back the wxSpinCtrls value via GetValue(). As a result, it will be returned as an int, and thus preserved as an int during the shift. My guess is a little static cast/C-cast (similar to how RotationStartAngle/RotationStopAngle are done just above) should solve the problem. Original cfg-Write(wxT(/ImageCache/UpperBound), MY_G_SPIN_VAL(prefs_cache_UpperBound) 20); Suggested patch cfg-Write(wxT(/ImageCache/UpperBound), (long)MY_G_SPIN_VAL(prefs_cache_UpperBound) 20); This is just off-the-cuff - I can't exactly test being on Windows here. Note that for Windows 64-bit users, if needing to support them, they'll get tripped up by long being 4 bytes, whereas long long is the 64-bit variant (http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows ). -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Lukáš Jirkovský Sent: Tuesday, January 12, 2010 10:45 AM To: hugin-ptx@googlegroups.com Subject: Re: [hugin-ptx] Re: hugin image cache larger than 2047MB? 2010/1/12 kevin ke...@bluelavalamp.net: Hi Lukas, I'm running Slackware64, so 64-bit Linux with 12G of memory. With some of my larger stitches (current one working on is 228 images) there are times when it will go through and be loading images for the preview - this is after having previewed before, so I'm guessing it's having to reload because the cache size won't hold all of them. Would like to try a larger cache to see if it would speed that process up but can't go above 2047. Kevin Oh, I have misunderstood first time. I thought you were talking about enblend/enfuse image cache. Is the limit correctly set in preferences after restart? Anyway I took a look at the code and I don't see any limits here (OK, it seems there is limit to 2048TB). I can't find any limit which could cause this. Currently I can think only about one cause and it's some setting in /etc/security/limits.conf (If it's here, I remember Slackware 10(or 9?) didn't use it). I've never tried any of the memory related setting though Of course it may be some strange kernel option so I'd browse through /proc if the former doesn't help. Lukas -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Windows Build error - svn4843
Unfortunately, the error you pasted is about as meaningful as 'an error has occurred'. The error message indicates that the expected project/library 'huginbase' wasn't built. This is generally caused by one or more compilation errors earlier on. Scan 'up' in your log (eg: earlier), and you should find a more meaningful error message - either a compilation issue or a linking issue. In particular - look for the first occurrence of the error if it happens multiple times. A starting point would (going from memory) be to look for a line like XXhuginbase - Y error(s), Z warning(s). Once you've found what XX is for huginbase, look for all the lines (earlier) prefixed with XX (which will be individual file compilations) and look for any errors. Hope that helps -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of brian_ims Sent: Thursday, December 31, 2009 12:47 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Windows Build error - svn4843 Hi, I've been trying to build svn4843 using the steps I used when building before the recent layout merge and get the following error multiple (19) times in Visual Studio: 30Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1 30Copyright (C) Microsoft Corporation. All rights reserved. 30Linking... 30LINK : fatal error LNK1104: cannot open file '..\..\hugin_base\Debug\huginbase.lib' 30Build log was saved at file://f:\sdk\hugin_build\src\hugin1\ptbatcher\PTBatcherGUI.dir\Debug\ BuildLog.htm 30PTBatcherGUI - 1 error(s), 0 warning(s) Can anybody give guidance on what to do? Cheers -- View this message in context: http://old.nabble.com/Windows-Build- error---svn4843-tp26975683p26975683.html Sent from the hugin ptx mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: binary distribution policy
well I'd be thrilled to contribute and I do use windows. actually I've been going off it lately but I imagine it's cyclical. What I would require is a crude explanation what is and how works C and what is C ++ how is the same name for program language different in windows and unix. I would need to know what these differences are before I dived in and tried to figure stuff out mick Not to discourage anyone from contributing, because it's always welcome, but it's important to understand that the lack of Windows binaries is not solely related to 'the lack of someone to compile them,' which I think is what Yuv was getting at originally before the flame war erupted. What is needed is someone to do for the Windows side what Yuval (previously) did for the general releases: Someone who can shepherd the platform, maintain it, and support it. For example, what happens if someone has a crash that is only on Windows? Who will be responsible for tracking it down, getting diagnostic information, etc? Who will maintain the installer, ensuring everything gets put in its proper place? And let's not forget dependencies - and all their myriad configurations. When development progresses, will the person building binaries have the necessary knowledge and skill to keep their environment up to date - and to ensure that when it's prepared for end-users, it's kept as simple and clean as possible? There has definitely been a lot of interest in getting Windows compiled - which is great, as it's a good beginners step into this. However, judging by the questions on the list so far, it doesn't seem like (and I hope I'm not offending anyone when I say this) that no one who has stepped up really understands what the challenges were and are, and that the same quality concerns may persist once your first 'hugin.exe' is sitting in your output directory. I've seen suggestions about possible installer scripts and the like - except there is already an installer script that, while valid for 0.7.0, definitely needs polish and attention. I've seen a lot of questions about dependencies and compilation bugs (on all platforms, for that matter), when many of the questions are already answered on the Wiki. While yes, I'm aware that sounds dangerously close to the anti-user RTFM, it really cannot be understated how important that step is. In terms of what has (historically) prevented a 0.8.0 release, consider the following: - No one has stepped up to own the installer. A huge amount of work is already done, but there is still significant work to be done to put together an end-user-friendly, international-law-abiding installer. - No one has stepped up for the 'cat herding' task of building a plan for how a Windows release might go. Once the binaries are built (which, not to insult anyone, really is the easiest part), how will they get tested on the various platforms? How will feedback be collected? How will issues be addressed - Windows specific issues, installer issues, platform issues? - What about 32-bit and 64-bit binaries? They *are* different, they *do* have different build steps and, while their dependencies are the same, actually resolving those dependencies requires quite a few different steps. For Linux and Mac this is much easier, but on a platform like Windows, with a build system like CMake, a compiler like MSVC, and a (justifiable) policy of static linking, this is a whole new set of challenges. - How will the exes be 'audited'? Consider that in the case of Linux, you're often building from source or seeing it distributed by your distro vendor - which is a nice clean audit trail of no back doors. For Mac and Windows, when shipping binary versions, there is a matter of trust - trust which takes time to establish (as Harry has). Certainly that needs to be a consideration, even as a community with no specific liability. For those who are realizing that this task is a lot larger than perhaps they'd realized, or that it involves a set of skills that they may not necessarily have, don't be disheartened - there are still ways to contribute. Testing and feedback will always be a necessary part, just as interface design and behaviour will be important as well. While I can understand how Yuval's message seems to have got lost or misinterpreted, I would absolutely agree with the concerns he expressed on his personal page regarding the significance of this task, and why it is frustrating when people are frequently asking on list. It's not that there is anything wrong for asking, it's just that it's not nearly as simple as people may think it is, and it's misguided and potentially insulting to insist that it is, as some have in the past. -- 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
RE: [hugin-ptx] Re: (Probably very basic) help needed for build process on WinXP: missing files?
See http://sourceforge.net/tracker/?func=detailaid=2789320group_id=77506atid= 550443 Look at the diff files for libxmi-1.2 and lcms-1.18 tiff.h can be found in wxWidgets, unless you're specifically linking against a newer version for the larger file support (note: if doing so, make sure you're not duplicating symbols in wxWidgets) More details are at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 -Original Message- From: J. Schneider [mailto:j-schn...@gmx.de] Sent: Sunday, November 15, 2009 4:49 PM To: hugin-ptx@googlegroups.com Subject: Re: [hugin-ptx] Re: (Probably very basic) help needed for build process on WinXP: missing files? Hallo Yuv, I took my moving_target.html and my huginbase directory to reconsider where I was standing. - trying to build enblend - lcms built successfully - wxWidgets found again after it looked like missing - libtiff built sucessfully - STLport: Got the source and did that configure thing - but actually I don't exactly know (or remember) what this produced. Anyway there is an STLport folder now. - libxmi: Got the source and unzipped it. Is this it? This is where I stopped and the last question was, whether I should do anything more than unzipping it: 2. libxmi-1.2 In the INSTALL file it says 1. Do './configure', 'make', and 'make install', as usual. This will install both libxmi and its header file, xmi.h. but I'm not sure if installing is what I want to do in this case. these are standard instruction for Linux/Unix. They don't work for MSVC. Also IIRC you just want to unpack it there, not necessarily build/install it. But I may be wrong. I'm currently on Linux and it's late. I shall look at my Windows box soon. OK, let's keep this one for later. Just to verify that MSVC doesn't complain any more about missing things that I believe I solved I reran a build. The logs are below. First thing I wondered about is that two projects are built: first vigra_impex and then enblend. But I found out that I have to chose from a submenu to build only a certain part. Next thing is that it complains about missing tiff.h when building vigra. There was still tiff-3.8.2 listed in it's properties and with changing it to 3.9.1 this was solved. (Updated moving_target.html accordingly.) Building enblend didn't fail any more because of some dependency missing but because of too many other errors occurring. I put the complete log at http://www.joachimschneider.info/BuildLog.htm, but beginning and end are cited here: 2-- Erstellen gestartet: Projekt: enblend, Konfiguration: Release Win32 -- 2Kompilieren... 2cl : Befehlszeile warning D9035 : Die Option Wp64 ist veraltet und wird in einer der nächsten Versionen entfernt. 2getopt_long.c snip 2d:\huginbase\lcms-1.18\include\icc34.h(781) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'count' 2d:\huginbase\lcms-1.18\include\icc34.h(781) : fatal error C1003: Mehr als 100 Fehler gefunden; Kompilierung wird abgebrochen. Ergebnisse Das Buildprotokoll wurde unter file://d:\huginbase\enblend\src\Release\BuildLog.htm gespeichert. enblend - 264 Fehler, 1 Warnung(en) I'm not sure if this is some progress. But at least it is a new kind of failing. I don't know if MSVC had found anything else missing if it hadn't stopped at some point. (Probably this is configurable, but I didn't find where.) Can you give me the next hints? regards Joachim -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Can't build Enblend under Windows
This is caused when PACKAGE_NAME_B is defined, as it expects automake to have replaced the symbolic @UINT8_T@ with the actual type. However, on Windows, you don't have Automake, so this doesn't work. If you visit the Wiki page, you can see the instructions for how to do this - http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 - including the necessary patch files - http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Diff_Files - which I linked to previously, directly, at http://sourceforge.net/tracker/?func=detailaid=2789320group_id=77506atid= 550443 You specifically want the lcms patch. This undefines the symbolic PACKAGE_NAME_B, which then forces it to go down the codepath appropriate for Windows, which is contained on lines 220-223. -Original Message- From: Rotareneg [mailto:rotare...@gmail.com] Sent: Sunday, November 15, 2009 6:22 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Can't build Enblend under Windows I cannot figure out how to get Enblend to compile using VC2008 Express. This is the show-stopping error that's killing me right now: -- Build started: Project: enfuse, Configuration: Release Win32 -- Compiling... enfuse.cc d:\huginbuild\lcms-1.18\include\icc34.h(154) : error C2018: unknown character '0x40' d:\huginbuild\lcms-1.18\include\icc34.h(154) : error C2018: unknown character '0x40' d:\huginbuild\lcms-1.18\include\icc34.h(154) : error C2146: syntax error : missing ';' before identifier 'icUInt8Number' d:\huginbuild\lcms-1.18\include\icc34.h(154) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int d:\huginbuild\lcms-1.18\include\icc34.h(154) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int d:\huginbuild\lcms-1.18\include\icc34.h(155) : error C2018: unknown character '0x40' d:\huginbuild\lcms-1.18\include\icc34.h(155) : error C2018: unknown character '0x40' d:\huginbuild\lcms-1.18\include\icc34.h(155) : error C2146: syntax error : missing ';' before identifier 'icUInt16Number' d:\huginbuild\lcms-1.18\include\icc34.h(155) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int d:\huginbuild\lcms-1.18\include\icc34.h(155) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int d:\huginbuild\lcms-1.18\include\icc34.h(156) : error C2018: unknown character '0x40' d:\huginbuild\lcms-1.18\include\icc34.h(156) : error C2018: unknown character '0x40' This continues on and on with the same pattern. Any ideas? -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Can't build Enblend under Windows
Looks like this was code added in the past few days (I see it as rev 610 being when it was introduced). It appears rint() is only implemented in GCC - MSVC math.h headers do not include it. Some quick Googling shows: http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2007-08/msg03695.html and the followup http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2007-08/msg03917.html For those concerned about licensing/where the source comes from, an alternative (non-x64 friendly) version is available at http://websvn.kde.org/trunk/kdesupport/kdewin/include/msvc/math.h?view=marku p Or another, which appears to be correct (although non-ASM), and would be fine for both x32 and x64 compiles http://www.eecg.utoronto.ca/~aamodt/sourceware/MSVC.html I haven't built Enblend in the past month or so, so sorry that I can't be more specific help. -Original Message- From: Rotareneg [mailto:rotare...@gmail.com] Sent: Sunday, November 15, 2009 10:20 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Can't build Enblend under Windows Thanks, that fixed that problem. Unfortunately there are more problems. First there was an error about slist which I fixed by building STLport. Now I'm stuck at: 1c:\huginbase\enblend\src\mask.h(190) : error C3861: 'rint': identifier not found On Nov 15, 6:24 pm, Ryan Sleevi ryan+hu...@sleevi.com wrote: This is caused when PACKAGE_NAME_B is defined, as it expects automake to have replaced the symbolic @UINT8_T@ with the actual type. However, on Windows, you don't have Automake, so this doesn't work. If you visit the Wiki page, you can see the instructions for how to do this -http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29- including the necessary patch files - http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Diff_Files- which I linked to previously, directly, athttp://sourceforge.net/tracker/?func=detailaid=2789320group_id=7750 ... 550443 You specifically want the lcms patch. This undefines the symbolic PACKAGE_NAME_B, which then forces it to go down the codepath appropriate for Windows, which is contained on lines 220-223. -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
RE: [hugin-ptx] Re: Can't build Enblend under Windows
You forgot to include libxmi with the linker. My guess is you added libxmi folder to the include directory (like the default MSVC proj has). You actually have to compile libxmi and make sure to include it with the linker. The patch files previously mentioned several times do address this. I would strongly encourage you to review the Wiki pages mentioned and examined the patches, as you will likely find that many possible questions have already been answered and challenges already addressed. -Original Message- From: Rotareneg [mailto:rotare...@gmail.com] Sent: Sunday, November 15, 2009 10:31 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Can't build Enblend under Windows Ok, found out that rint() is missing under MSVC so I just pasted in a replacement from: http://www.eecg.utoronto.ca/~aamodt/sourceware/MSVC.html Now I'm getting linking errors in enblend: 2Linking... 2 Creating library Release/enblend.lib and object Release/ enblend.exp 2enblend.obj : error LNK2001: unresolved external symbol _miNewPaintedSet 2enblend.obj : error LNK2001: unresolved external symbol _miDeleteGC 2enblend.obj : error LNK2001: unresolved external symbol _miDeletePaintedSet 2enblend.obj : error LNK2001: unresolved external symbol _miNewGC 2enblend.obj : error LNK2001: unresolved external symbol _miFillPolygon 2Release/enblend.exe : fatal error LNK1120: 5 unresolved externals -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin- ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. 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: Enblend: CMake (Windows) broken
-Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Yuval Levy Sent: Tuesday, September 22, 2009 8:20 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: Enblend: CMake (Windows) broken SNIP makes sense - I'm on MSVC EE and it looks like Microsoft wants to cap the wings of developers for its plattform / extract a tax from them - OpenMP is not supported in MSVC EE, just in the higher up, paying editions. Not entirely accurate. You probably want to view http://blog.codekills.net/archives/25-OpenMP-and-Visual-C++-the-free-way-sor ta.html It turns out OpenMP is like x64 compilation - It's possible, just requires a little... finesse. --~--~-~--~~~---~--~~ 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: Enblend + cmake + FindBoost
Or just update the versions (in Enblend and ideally in Hugin) to match something from the more recent CMake distributions. I'd like to see that for a number of the .cmake files derived/modified from CMake sources - figuring out what sort of changes were made, and keeping them up to date as appropriate. I don't know what sort of changes have been made for other platforms, but on the Windows side of things, FindLibraryForCPU / FindLibraryWithDebug are two important macros that, unfortunately, require altering the 'stock' CMake files to use (there isn't a way to overload FIND_LIBRARY AFAIK). In addition to that, several other packages that have their own complex naming rules (Boost, STLPort, wxWidgets) require a little bit of tweaking to properly handle the libraries' ability for 64-bit builds via their native build tools. I've got no objections to combining that plus a scheme for renaming local .cmake files, with a preference for local copies over CMake distributed versions when they exist (for the obvious reason that local copies have, presumably, necessary modifications). eg: FindEnblend_Boost.cmake + FindPackage(Enblend_Boost) IF(NOT Boost_FOUND) FindPackage(Boost) ENDIF(NOT Boost_FOUND) -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Kornel Benko Sent: Tuesday, September 15, 2009 1:49 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Enblend + cmake + FindBoost Hi all, currently we are using our own FindBoost.cmake. I was unable to make it work on OpenSuSE. That is, though I have Boost installed (the standard way, add needed packages with yast), this version of FindBoost does not find it. (Yes Ryan, I tried to set the environment BOOST_ROOT, I tried to make a directory containing symbolic links to lib and include and so on) On the other side, using the FindBoost from installed cmake, I had no problems. So I propose to remove our version. I am prepared to make any needed changes in CMakeLists.txt If that is not OK, then there is another possibility. Rename our version, so that in case nothing is found we could use the official version too. (This is currently not possible) Kornel -- Kornel Benko kornel.be...@berlin.de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Enblend + cmake + FindBoost
-Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Kornel Benko Sent: Tuesday, September 15, 2009 6:21 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: Enblend + cmake + FindBoost SNIP And we could make it configurable. 1.) no boost search 2.) only our FindBoost 3.) only cmake's FindBoost 4.) Both, like proposed I mean: cmake ... -DSearchBoost=[NO|Enblend|System|Both] Default may be Both. Kornel I'd much rather we no. Every option directly increases the complexity of the user experience and maintenance, and more options do not necessarily make for a 'better' configuration. An alternative solution would be to try to resolve the inconsistencies amongst the various stock Find*.cmake files. Some allow you to override paths (through Advanced View, which is much easier IMHO than using -D all the time, or through setting the various lib/include/search paths that are documented in CMake), some let you set variables so that searching only happens if the variable isn't set, and some ignore any user-specified options entirely. If it becomes a problem (and I don't think it really is at this point), we could modify those of the last case to be 'smarter' about it by looking at the first two. I think we should approach it carefully though, and try to understand under what specific conditions something like that would need to be overridden by the user, and accommodate that, rather than adding a whole bunch of unnecessary configuration + logic. Plus, a user today can ALWAYS override what is found by using advanced view and, after auto detection is completed, altering the paths. That is, after all, the whole purpose of the CMake cache being generated. --~--~-~--~~~---~--~~ 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 Hugin SDK and documentation
Or we can go the easier route (for end users) that I've been pursuing: An automatable that handles it all for you ;-) With the basic pre-requisite of 1) Sources for packages 2) The patches from me (already applied, but nothing to say we can't automate that in the future) 3) MSVC Express Edition 4) Windows SDK (6.1 or 7) It digs in and builds each part of the SDK - Debug Release, 32-bit and 64-bit. I'm currently using batch files as the means, but after working with the CMake-ification of Enblend/Enfuse, I think there is enough capability (by means of the external commands) that for the non-CMake'd portions (eg: Everything *BUT* enblend/enfuse), we can call the appropriate tools (eg: configure.bat for STLport, bjam for boost, vcbuild for the various .sln based projects, etc). With my batch file setup, I've got it automatically building everything through enblend-enfuse hands-free. Using the four basic requirements above, I can kick it off, and step back and I've got all the enblend-enfuse binaries. At that point, the distribution of the SDK needs merely concern itself with the maintenance of 1) The patches - Which tend to fix path resolution issues relative to the SDK for .sln projects and add 64-bit configurations 2) The CMake configuration script - Which is used really just to find the various packages, determine if they're built yet or not, and if not, build them using the packages appropriate build mechanism. This seems a much more realistic and reasonable scenario for getting people started, and also resolves potential issues where, for example, a user might want to alternative between statically and dynamically linking the MSVC runtime (Legal concerns, performance concerns, functionality, who knows) and issues w/ versions (eg: 2008 v 2008 SP1 v 2010 at some point) Thoughts? -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Yuval Levy Sent: Thursday, September 10, 2009 12:16 PM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Windows Hugin SDK and documentation Hi Ryan and other Windows developers I'm moving this piece of information to the main mailing list. Ryan Sleevi wrote: -Original Message- From: Yuval Levy Sent: Tuesday, September 08, 2009 8:34 AM To: kornel.be...@berlin.de Cc: Harry van der Wolf; Christoph Spiel; ryan+hugin; bst; Thomas.Modes; Andrew Mihal; Lukáš Jirkovský; Bruno Postle; Pablo d'Angelo; Pascal Spörri Subject: Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list] SNIP OK, so we may create something working on more then one platform. reminds me that I did not yet even try on Windows. I'm stuck with not being able to build lcms-1.18a inside the Hugin SDK (which has 1.17). Yuv, check the .diff file uploaded to the Wiki for building the Windows SDK. It's just a one line change for lcms (1.18). The trick for lcms-1.18 is that you *only* need to build the lcms project, not the entire solution. lcms (the project) doesn't depend on the TIFF or JPEG libraries, so it should have no trouble building. Thanks, Ryan - this did the trick. I was going to add this bit of information, as well as document the lack of OpenMP support in the Express Editions of MSVC, to the page documenting the [Hugin SDK]. Then I realized that I was going to raise a conflict again: There is a major inconsistency in the document which stems from the definition of Hugin SDK. When writing up the document, Guido defined Hugin SDK as the minimal stable binaries and headers needed to build and run Hugin. To me it must be more than that. And to Ryan obviously too: lcms is not needed to build the Hugin binary. Hence it is documented as 64-bit Only. But as I found out, it concerns 32-bit as well. The logical consequence would be to first define what the Hugin SDK really is; then to update the documentation and distributed binaries accordingly. Ad's releases are to me the proof that the current SDK does not work. It becomes stale quickly as upstream tools and libraries evolve. Worse: it leaves people like Ad dependent on the next binary SDK instead of giving them the tools and knowledge to update their SDK. The [Hugin SDK] Wiki page should make people like Ad independent. Hence my suggestion: 1. The [Hugin SDK] will document how to build each and every package upstream, including further upstream dependencies (e.g. Hugin depends on enblend; and enblend depends on lcms; hence both should be documented), for both 32 and 64 bit. 2. Distribute the SDK in two forms: one large archive containing everything (almost like the current one). It will become outdated, but here comes the second distribution: archives of individual packages. This way the faster evolving packages can be updated/distributed more often. To achieve this, I suggest to expand on the current structure
[hugin-ptx] Re: cmake compilation of enblend prelease version 4.0
miNewGC is from libxmi. I'm guessing that cmake isn't quite finding it. Presumably, libxmi (and lcms) need to be set to REQUIRED in the find_library calls, as they are necessary. That should allow CMake to bubble the error up if it's having trouble resolving where you put it. From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Harry van der Wolf Sent: Wednesday, September 09, 2009 7:50 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] cmake compilation of enblend prelease version 4.0 All, I have lifted this discussion to the hugin-ptx list to make it available for everyone. I also skipped the rest of the conversation to remove all the email addresses from the private conversation. @Christoph: Please implement the attached gpu_patch.diff patch to the repository. It is necessary for OSX, both for autoconf and cmake. @Kornel: You write that we don't need Boost. As such you are right as you can compile without Boost. However, when boost-filesystem is available enblend/enfuse will use it. That's why I had Boost detection in my cmake stuff (but it didn't work correctly in compilation) I can now compile against GLUT and GLEW, so I have a gpu enabled enblend/enfuse. I had to modify config.h.cmake, configurechecks.cmake and src/CMakelists.txt for correct detection of openGL.framework on apple and for linking against the correct libraries. These three files are attached in the mod-KB-cmakefiles.tgz. I did not have to change anything else. Note: The compilation via cmake is really very, very fast compared with the current autoconf method. When running either enblend --gpu -o pipo.tif image files or enblend -o pipo.tif images files, I do get the following error. /usr/local/bin/enblend --gpu -v -o pipo.tif 1222-021*.tif : info: using graphics card: NVIDIA Corporation : info:renderer: NVIDIA GeForce 9600M GT OpenGL Engine enblend: info: loading next image: 1222-021-1222-025.tif 1/1 enblend: info: loading next image: 1222-021-1222-0250001.tif 1/1 enblend: info: creating blend mask: 1/3 2/3 3/3 enblend: info: optimizing 1 distinct seam enblend: info: strategy 1, s0: 1/4 2/4 3/4 4/4 enblend: info: strategy 2: s0 dyld: lazy symbol binding failed: Symbol not found: _miNewGC Referenced from: /usr/local/bin/enblend Expected in: flat namespace dyld: Symbol not found: _miNewGC Referenced from: /usr/local/bin/enblend Expected in: flat namespace Trace/BPT trap Antares-4:enblend harryvanderwolf$ /usr/local/bin/enblend -v -o pipo.tif 1222-021*.tif enblend: info: loading next image: 1222-021-1222-025.tif 1/1 enblend: info: loading next image: 1222-021-1222-0250001.tif 1/1 enblend: info: creating blend mask: 1/3 2/3 3/3 enblend: info: optimizing 1 distinct seam enblend: info: strategy 1, s0: 1/4 2/4 3/4 4/4 enblend: info: strategy 2: s0 dyld: lazy symbol binding failed: Symbol not found: _miNewGC Referenced from: /usr/local/bin/enblend Expected in: flat namespace dyld: Symbol not found: _miNewGC Referenced from: /usr/local/bin/enblend Expected in: flat namespace Trace/BPT trap It's referenced from mask.h where it's used but that's as far as I come. Harry 2009/9/8 Kornel Benko Am Dienstag 08 September 2009 schrieb Yuval Levy: ... *I* am a code-monkey :-) Kornel did most of the hard job on the CMake build and deserves all the credits. I feel GOOD OK, so we may create something working on more then one platform. reminds me that I did not yet even try on Windows. I'm stuck with not being able to build lcms-1.18a inside the Hugin SDK (which has 1.17). It does find the TIFF and JPEG headers; and when I manually edit the source code to find the TIFFs .h (I have not yet tried with the JPEG) it does not link. Sorry for the extra work to bring the files together. no need to apologize. thank you everybody for your contribution and patience. maybe we should continue talking on hugin-ptx? whoever transfers the thread, make sure email addresses are *not* transferred, and do not CC (at least not me) the email addresses currently on this thread. I lookud at the cmake-files from Harry. I may have overseen something, but most of things we not had were not needed. (e.g. definition of BINDIR, DATADIR or LOCALEDIR) src/win32helpers/CMakeLists.txt were included, but the is essentially empty. There may come something later, so I integrated it. Also I added the definitions for APPLE. We do not need boost, nor do we need KDE. Yuv The CMakeModules is now part of enblend. But I would like to use the hugin directory. Chritoph, is it possible in mercurial to add a directory which references another project? I saw something in this direction in mplayer project, but this was with svn. Attaching my version of cmakefiles ... which again compiles on ubuntu, after someone added DEFAULT_VERBOSITY Kornel
[hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
-Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Kornel Benko Sent: Wednesday, September 09, 2009 9:02 AM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list] It compiles now. We have to set OpenMP_FOUND somewhere. Maybe in FindOpenMP.cmake? But why do you prefer image_cache and no openmp be default? As we're already seeing on the list, without the image cache, a number of perfectly valid tests in the past (if not perfectly common), no longer run. The OpenMP version really is a specialized version for those concerned with speed or 'bleeding edge', but does not represent a feature necessarily ready for mainstream use without understanding the trade-offs/caveats. Hence, an ideal non-feature Am Wednesday 09 September 2009 schrieb Kornel Benko: Am Wednesday 09 September 2009 schrieb Kornel Benko: I try to compile now on OpenSuSE. CMake Error at CMakeLists.txt:131 (FIND_PACKAGE): Could not find module Findlibxmi.cmake or a configuration file for package libxmi. This is because on linux you have to search for LibXMI == FIND_PACKAGE(LibXMI REQUIRED) Sorry, this was an unfinished non-Win32 stub that I was hoping to be filled in by someone more knowledgeable in the nescessary CMake incantations. CMake Error at CMakeLists.txt:130 (FIND_PACKAGE): Could not find module Findlcms.cmake or a configuration file for package lcms. there is only FindLCMS.cmake in CMakeModules == FIND_PACKAGE(LCMS REQUIRED) I'm guessing CMake on other platforms opts for a different capitalization scheme. This one would be impossible to test except on other systems. Win32 is less-concerned with it. Apart from that, it compiled, but the linking stage was erroneous. cd /usr/BUILD/BuildEnblend/src /usr/bin/cmake -E cmake_link_script CMakeFiles/enblend.dir/link.txt --verbose=1 /usr/local/bin/c++ -fPIC CMakeFiles/enblend.dir/gpu.o CMakeFiles/enblend.dir/filenameparse.o CMakeFiles/enblend.dir/enblend.o -o ../bin/enblend -rdynamic vigra_impex/libvigra_impex.a -lboost_thread -lboost_date_time -ljpeg -ltiff -lpng -lz -llcms -lxmi -lImath -l IlmImf -lIex -lHalf -lIlmThread -ltiff -lpng -lz CMakeFiles/enblend.dir/gpu.o: In function `checkFramebufferStatus()': gpu.cc:(.text+0xb): undefined reference to `__glewCheckFramebufferStatusEXT' CMakeFiles/enblend.dir/gpu.o: In function `clearGPUTextures()': gpu.cc:(.text+0x21a): undefined reference to `__glewDeleteFramebuffersEXT' gpu.cc:(.text+0x235): undefined reference to `glDeleteTextures' Missing -lglew, even when _not_ enabling ENABLE_GPU Could this be an issue of a stale cache? All of the GPU code depends on HAVE_LIBGLEW being set, which is added as a pre-processor definition if you select ENABLE_GPU and the checks for GLEW and GLUT succeed. But even then I got cd /usr/BUILD/BuildEnblend/src /usr/bin/cmake -E cmake_link_script CMakeFiles/enblend.dir/link.txt --verbose=1 /usr/local/bin/c++ -fPIC CMakeFiles/enblend.dir/gpu.o CMakeFiles/enblend.dir/filenameparse.o CMakeFiles/enblend.dir/enblend.o -o ../bin/enblend -rdynamic vigra_impex/libvigra_impex.a -lglut -lXmu - lXi -lGLEW -lboost_thread -lboost_date_time -ljpeg -ltiff -lpng -lz - llcms -lxmi -lImath -lIlmImf -lIex -lHalf -lIlmThread -ltiff -lpng -lz CMakeFiles/enblend.dir/enblend.o: In function `printVersionAndExit()': enblend.cc:(.text+0x2652): undefined reference to `omp_get_nested' ... which means, the OpenMP Flags (-fopenmp on my system) were not set on linking stage, which impiles, that OpenMP_FOUND were not set. . I try to correct Kornel The flag OpenMP_FOUND doesn't really matter as much, at least not in the code. All that matters is whether or not _OPENMP is defined, and that should only be defined if your compiler has run with -fopenmp (in the case of GCC). There is no need for OpenMP_FOUND - if you select OpenMP, then OpenMP is marked as required, and if it's not found, compilation will stop right there. I suspect this could be a cache issue as well, of older object files. --~--~-~--~~~---~--~~ 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: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
Hrm... The flow is supposed to go:
CMakeLists.txt
IF(ENABLE_OPENMP)
find_package(OpenMP REQUIRED)
add_definitions(${OpenMP_CXX_FLAGS})
ENDIF(ENABLE_OPENMP)
This calls CMakeModules/FindOpenMP.cmake, which as the second-to-last
execution, runs
find_package_handle_standard_args(OpenMP DEFAULT_MSG
OpenMP_C_FLAGS OpenMP_CXX_FLAGS )
This calls CMakeModules/FindPackageHandleStandardArgs.cmake, which will set
OpenMP_FOUND if both OpenMP_C_FLAGS and OpenMP_CXX_FLAGS are defined.
When dealing with the MSVC compiler, the flag candidate (/openmp) works
successfully for both the C and the C++ source code. Perhaps GCC is only
setting OpenMP_CXX_FLAGS and not detecting anything for OpenMP_C_FLAGS? If so,
that would explain why OpenMP_FOUND was not being set to true, but how the
define could end up getting set. If both _C_FLAGS and _CXX_FLAGS are set, then
that really is odd, because FindPackageHandleStandardArgs is used pretty
extensively and seems to be well-tested.
I suppose the 'better' resolution to handle that case is to check the check in
src/CMakeLists from IF(${OpenMP_FOUND}) to IF(${OpenMP_CXX_FLAGS}), since it
really is that variable (and not the _C_FLAGS or the _FOUND) that is
controlling whether or not it compiles with OpenMP.
From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf
Of Kornel Benko
Sent: Wednesday, September 09, 2009 11:34 AM
To: hugin-ptx@googlegroups.com
Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker
and developer mailing list]
Am Mittwoch 09 September 2009 schrieb Ryan Sleevi:
I try to correct
Kornel
The flag OpenMP_FOUND doesn't really matter as much, at least not in the
code.
Not in the code, but you introduced it in src/CMakeLists.txt. And there it
matters.
All that matters is whether or not _OPENMP is defined, and that
should only be defined if your compiler has run with -fopenmp (in the case
of GCC). There is no need for OpenMP_FOUND - if you select OpenMP, then
OpenMP is marked as required, and if it's not found, compilation will stop
right there. I suspect this could be a cache issue as well, of older object
files.
I selected OPENMP, therefore the source was compiled with the corresponding
flag.
But on the linker stage it was missing, beacuse OpenMP_FOUND was not set.
Kornel
--
Kornel Benko
kornel.be...@berlin.de
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
hugin and other free panoramic software group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---
[hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
FindLibraryWithDebug is safe for Release calls. It's just a special handler for Windows platforms that tend to have libraries with debug file suffices (and with my modifications, also handles situations where x86 and x64 libs are side-by-side, sharing 1 include dir, but having their own unique lib dirs, and potentially their path suffixes - eg Release/x86/libfoo.lib vs Debug/x86/libfoo.lib or x64/libbard.lib vs x64/libbar.lib). On other platforms, it just passes through to FIND_LIBRARY, which on the non-Win platforms is more an issue with the CMAKE_BUILD_TYPE. As you indicated in your follow-up, the CMAKE_BUILD_TYPE is what controls whether or not the compiler is set to be optimized for release mode. For the Windows platforms, all the build types are exported into a single .sln and can be chosen within the MSVC ide / vcbuild command-line (CMake tries to preserve the native build semantics, and that's how it is done on Windows). FindLibraryWithDebug further eases this process for the Windows world. From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Kornel Benko Sent: Wednesday, September 09, 2009 12:28 PM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list] Am Mittwoch 09 September 2009 schrieb Harry van der Wolf: Hi all, Here are the results from the OSX jury. OpenMP is not an issue as it is not available on OSX (apart from some extremely bleeding edge source packages) enblend via cmake compiles and works now too on OSX. however, on doing some tests I had some shocking results. enblend pre 4.0 via cmake. with openGL, GLEW and GLUT /usr/local/bin/enblend --version enblend 4.0-11ca5b567bc9 /usr/bin/time /usr/local/bin/enblend --gpu -o pipo.tif 1222-02*.tif : info: using graphics card: NVIDIA Corporation : info: renderer: NVIDIA GeForce 9600M GT OpenGL Engine snip enblend: info: writing final output 103.61 real 100.38 user 1.39 sys /usr/bin/time /usr/local/bin/enblend --gpu -o pipo.tif 1222-02*.tif enblend: info: writing final output 106.16 real 104.16 user 0.91 sys enblend pre 4.0 via autoconf. No openGL, no GLEW, no GLUT enblend --version enblend 4.0-8d38f4ffc03c /usr/bin/time /Applications/Hugin.app/Contents/Resources/HuginStitchProject.app/Contents/ MacOS/enblend -o pipo.tif 1222-02*.tif 12.88 real 11.80 user 0.45 sys The autoconf version is almost 10X faster! Harry I see. 1.) In this version we are not optimizing 2.) We are using FindLibraryWithDebug.cmake Kornel -- Kornel Benko kornel.be...@berlin.de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
Seconded - any further modifications should happen in the repo. I'm holding off on my 'cleanup' of my additions/macros until the code can at least be based there From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Harry van der Wolf Sent: Wednesday, September 09, 2009 1:50 PM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list] What is missing now, is the control from command line for this. Since we don't have the same cmake-base we should search for some way to exchage changes only. The version here is mostly your modified version with corrections from me. Should we really be forced to send each time all the data? What do you think Ryan? I'm not Ryan, but Harry ;-) We (at least one of us) need access to the repository. It is completely harmless for the autoconf build to add the cmake stuff. From that moment on we can uses diff's to patch the repository Harry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker and developer mailing list]
Kornel,
At the lowest level, you can always MESSAGE(STATUS Message)
so
IF(${SOME_FLAG})
MESSAGE(STATUS Project will be built with
some_flag disabled. If you prefer to build without some_flag support, you may
use -DSOME_FLAG=0)
ELSE(${SOME_FLAG})
MESSAGE(STATUS Project will be built with
some_flag enabled. If you prefer to build with some_flag support, you may use
-DSOME_FLAG=1)
ENDIF(${SOME_FLAG})
Of course, that get's wildly inefficient for more than a few
options. Not to mention there are two presumptions - that the description
messages will containing meaningful context for non-native speakers of that
language - and that people are building through a command-line or means that
expects flags like -DSOME_FLAG. I know the CMake-gui actually exposes OPTIONs
as boolean checkboxes in the interface, and while I suspect it probably would
support args on the command-line, they don't exactly make it obvious
(especially for those in the Windows world)
The better/preferred/consistent alternative would be to use
ccmake / cmake-gui to provide users with options
More details are available via cmake --help-command SET and
cmake --help-command OPTION
eg:
SET(SOME_VAR def value PATH path to put awesome stuff)
OPTION(BOOL_VAR enable me to turn on the awesome stuff ON)
In the default view for ccmake/cmake-gui, only those options
NOT flagged MARK_AS_ADVANCED will be shown. Since all of our FindXXX* code uses
MARK_AS_ADVANCED, the default view shows only basic/core CMake arguments and
the options we have defined explicitly (such as the ENABLE_SSE2 stuff). No
consulting of the CMakeLists.txt necessary!
ccmake/cmake-gui is to cmake what ./configure --help is to
./configure :)
From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf
Of Kornel Benko
Sent: Wednesday, September 09, 2009 3:39 PM
To: hugin-ptx@googlegroups.com
Subject: [hugin-ptx] Re: cmake compilation of enblend [was: Enblend bug tracker
and developer mailing list]
Am Mittwoch 09 September 2009 schrieb Pablo d'Angelo:
What is missing now, is the control from command line for this.
Do you mean:
cmake -DCMAKE_BUILD_TYPE=Release
Yes, I know. But I prefer something which will be more recognised. And which
will print some suggestions.
Like this one (in another project)
cmake projectdir
Project will be built with nls support enabled. If you prefer build without nls
select -Dnls=0 on commad line
...
cmake -Dnls=1 projectdir
Project will be built with nls support disabled. If you prefer build with nls
support select -Dnls=1 on commad line
...
This way I am not supposed to remember the settings. (Or to look into
CMakeLists.txt to find out)
If I remember correctly, the enblend autoconf script does use more
aggressive optimisation options than most other packages.
We are pretty good now.
Kornel
--
Kornel Benko
kornel.be...@berlin.de
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
hugin and other free panoramic software group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---
[hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin
-Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Zoran Zorkic Sent: Monday, September 07, 2009 4:25 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin SNIP Is there a reason it wasn't compiled with image cache and OpenMP? If I recall correctly, the cached file representation used by enblend has not been made re-entrant/multi-threaded aware yet, so it causes some issues. I'm not sure if any work has been done towards supporting it, but I suspect it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image segments across multiple threads efficiently. --~--~-~--~~~---~--~~ 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] Enblend/Enfuse 4.0 dev snapshots
I'm not sure if many people are aware, but there has been a lot of ongoing development lately over in the repository for enblend/enfuse. Perhaps most importantly, Christoph Spiel's staging branch has been fully merged in, which introduces support for OpenMP on platforms that support it, as well as resolving several long standing leaks and bugs. I've gone and packaged up some snapshots for Windows users of the various configuration options that are possible - OpenMP support, GPU support, 64-bit support, and posted them at http://ryan.sleevi.com/files/enblend-enfuse-4.0/ In a change-up of things, I've gone ahead and linked them against the DLL-based versions of the MS C/C++ Runtime (for various reasons), and I want to make sure that process is working smooth for people. Most importantly, if you're planning to mess with OpenMP, you'll need to make sure you have the redistributable. Many already have the necessary files, as they have been shipping for some time, but for those who have issue, the two links are: x86 - http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391- 8A4D-074B9F2BC1BF Microsoft Visual C++ 2008 Redistributable Package (x86) x64 - http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230- B809-9A8D7548C1B6 Microsoft Visual C++ 2008 Redistributable Package (x64) This isn't an official release of 4.0 by any means, but this is an attempt to get dev binaries out there, as well as a chance to try out a more automated build system that should make it easier to package enblend/enfuse and Hugin in the future, so feedback would be appreciated. Cheers! --~--~-~--~~~---~--~~ 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: Can hugin stitch together Then and Now photos?
You could use Hugin to create the control points to align the images 'as best as possible'. Presumably, the images won't be taken with the exact focal length, angles, etc, so this will cause distortion between the images, but you can control the level by choosing your control points. You then use nona to remap the images, which will result in two images with the similar geometry, as specified by the control points. Depending on how complex your masks are, you can either use Enblend with a mask file, or you can load these two images into your layered image editor of choice and do the blending by hand. For how to use it with Enblend, see http://enblend.sourceforge.net/enblend.htm . If using TIFF files, Enblend will use the alpha channels of the images. A great tutorial on this process was written by Bruno and can be found at http://hugin.sourceforge.net/tutorials/enblend-svg/en.shtml In short, Hugin doesn't really care one way or the other. However, Nona + Enblend/Favorite image editor will provide you a tool chain for doing this, and both Nona + Enblend are available in the Hugin binary builds. --~--~-~--~~~---~--~~ 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: nona-gpu - has anybody got it working?
Ryan is so far the only one who has reported success, with his
self-built version. I wonder if one of the pre-compiled (from Guido or
from me) yield the same result. This would exclude building errors.
His video card is a GeForce 8800 GTS (256 mb) - anybody else with that
same video card who can run nona -g successfully? and other video
cards?
Yuv
Yuv,
So I did some testing with your exe
(http://www.photopla.net/hugin/nona_4169.7z ). Several projects I was able
to run without error with mine generated the following error:
nona: GL error in
..\..\..\hugin\src\hugin_base\vigra_ext\ImageTransformsGPU.cpp:743: out of
memory
However, when I re-created the simple project I'd used when testing
my version (just a simple transform), that I previously posted, I was able
to run without errors.
Since there appears to be some degree of variance depending on the
project and the settings, is there any desire to create a sample setup (or
preferably few) that test different levels of complexity?
For what it's worth, here's the results using your exe:
nona: using graphics card: NVIDIA Corporation GeForce 8800 GTS/PCI/SSE2
destStart=[0, 0]
destEnd=[3000, 2800]
destSize=[(3000, 2800)]
srcSize=[(4296, 2856)]
srcBuffer=062D0020
srcAlphaBuffer=0A610020
destBuffer=085F0020
destAlphaBuffer=09E00020
destGLInternalFormat=GL_RGBA8
destGLFormat=GL_RGB
destGLType=GL_UNSIGNED_BYTE
srcGLInternalFormat=GL_RGBA8
srcGLFormat=GL_RGB
srcGLType=GL_UNSIGNED_BYTE
srcAlphaGLType=GL_UNSIGNED_BYTE
destAlphaGLType=GL_UNSIGNED_BYTE
warparound=0
needsAtanWorkaround=0
maxTextureSize=8192
Source chunks:
[(0, 0) to (4296, 2856) = (4296x2856)]
Dest chunks:
[(0, 0) to (1500, 1400) = (1500x1400)]
[(1500, 0) to (3000, 1400) = (1500x1400)]
[(0, 1400) to (1500, 2800) = (1500x1400)]
[(1500, 1400) to (3000, 2800) = (1500x1400)]
Total GPU memory used: 190555008
Interpolator chunks:
[(0, 0) to (4, 4) = (4x4)]
#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect SrcTexture;
float sinh(const in float x) { return (exp(x) - exp(-x)) / 2.0; }
float cosh(const in float x) { return (exp(x) + exp(-x)) / 2.0; }
float atan2_xge0(const in float y, const in float x) {
return atan(y, x);
}
float atan2_safe(const in float y, const in float x) {
return atan(y, x);
}
float atan_safe(const in float yx) {
return atan(yx);
}
void main(void)
{
float discardA = 1.0;
float discardB = 0.0;
vec2 src = gl_TexCoord[0].st;
src -= vec2(1500., 1400.);
// rotate_erect(18000.000, -0.)
{
//src.s += -0.;
float w = (abs(src.s) 18000.000) ? 1.0 : 0.0;
float n = (src.s 0.0) ? 0.5 : -0.5;
src.s += w * -36000.000 * ceil(src.s /
36000.000 + n);
}
// sphere_tp_erect(5729.5779513082325000)
{
float phi = src.s / 5729.5779513082325000;
float theta = -src.t / 5729.5779513082325000 +
1.5707963267948966000;
if (theta 0.0) {
theta = -theta;
phi += 3.1415926535897931000;
}
if (theta 3.1415926535897931000) {
theta = 3.1415926535897931000 - (theta - 3.1415926535897931000);
phi += 3.1415926535897931000;
}
float s = sin(theta);
vec2 v = vec2(s * sin(phi), cos(theta));
float r = length(v);
theta = 5729.5779513082325000 * atan2_safe(r, s * cos(phi));
src = v * (theta / r);
}
// persp_sphere(5729.5779513082325000)
{
mat3 m = mat3(0.8074283680792127, -0.58996561799899783000,
0.,
0.58996561799899783000, 0.8074283680792127,
0.,
0., 0.,
1.000);
float r = length(src);
float theta = r / 5729.5779513082325000;
float s = 0.0;
if (r != 0.0) s = sin(theta) / r;
vec3 v = vec3(s * src.s, s * src.t, cos(theta));
vec3 u = v * m;
r = length(u.st);
theta = 0.0;
if (r != 0.0) theta = 5729.5779513082325000 * atan2_safe(r, u.p) /
r;
src = theta * u.st;
}
// rect_sphere_tp(5729.5779513082325000)
{
float r = length(src);
float theta = r / 5729.5779513082325000;
float rho = 0.0;
if (theta = 1.5707963267948966000) rho = 1.6e16;
else if (theta == 0.0) rho = 1.0;
else rho = tan(theta) / theta;
src *= rho;
}
// resize(1.6728386297652815000, 1.6728386297652815000)
src *= vec2(1.6728386297652815000, 1.6728386297652815000);
src += vec2(2144.5000, 1427.5000);
src = src * discardA + vec2(-1000.0, -1000.0) * discardB;
gl_FragColor = vec4(src.s, 0.0, 0.0, src.t);
}
#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect CoordTexture;
[hugin-ptx] Re: coding style
Granted, I'm not committing (yet?), but that doesn't keep me from voicing an
opinion, right? :)
1.2. VARIABLE NAMES
some variables are named with the CamelCase convention - capitalizing
the beginning of the word. Other use the word_separated_by_underscore
convention. Are there other conventions? Which one do you favor?
variable names should be clear and descriptive. no contractions, maybe
with a few listed exception, e.g. Pano instead of Panorama. Any more
exceptions?
Support James' comments re: LeadingCaps for classes/structures/typedefs, and
favoring mixedCase for variables. For functions, I always like the visual
distinction between public and private methods, if only to save a
consultation to intellisense or the header file. Using LeadingCaps for
public functions, mixedCase for private/protected/internal seems to offer
some visual distinction, but that's more a personal preference thing :)
I'm a fan of mixedCase over underscore_insertions_for_words myself, if only
to save the keyboard extension to the underscore. Readability wise I think
they're fairly equal. The only question comes when using acronyms (eg:
sqlVar vs SQLVar vs sQLVar), but I don't know how much of a problem that is.
I haven't seen many variables that have that problem in the codebase, and it
doesn't seem like it'd need to be hammered out now...
1.3. FUNCTION NAMES
should functions follow the same conventions as variables? or a
different one?
function names should be descriptive. no contractions, maybe with a few
listed exception, e.g. Pano instead of Panorama. Any more exceptions?
Agree with James' comment that whatever contractions are acceptable, they be
used exclusively.
3. SPACING AND INDENTATION
3.1. BRACES
there are many different indent styles [3]. I am personally used to
1TBS
[4] (like the Linux Kernel), but I recently heard good arguments to
adopt Allman style [5], which puts the brace associated with a control
statement or a function on the next line, indented to the same level as
the control statement. I am ready to go Allman. Or maybe you want to
suggest other alternatives? Which one do you prefer?
I always find 1TBS to be readable. The most helpful thing is the requirement
that single-line conditionals always include braces. Had too many bugs
working in teams where one dev would use a short construct, and either
between merging or sloppy devs, a second statement would be added that
screws up the code.
eg:
if (condition)
doSomething();
becoming
if (condition)
doSomething();
doSomeOtherThing();
instead of
if (condition) {
doSomething();
doSomeOtherThing();
}
The problem I have with Allman is that I've seen too many bugs where the
code ends up like
if (condition);
{
doSomething();
}
See the error? The extra ; accepted by all the compilers I've ever used,
ends up causing the { } to always be executed. It can be a real pain to
trace through those in complex systems to find out who added the extra ;
when typing
3.2. TABULATORS
use spaces instead of tabulators (to maintain consistency across
editors). use four spaces for one indentation. or are there other
preferences?
Spaces, tabs, it's all the same to me. Visual Studio can be a pain when
adjusting between the two, but it's doable. My own preference is Tabs are
used for logical columns, spaces are used for alignment, but that's not
exactly easy to enforce :) (Of course, a diff usually reveals right away if
things are off). It's only really an issue if column width is also being
fixed - since artificial wrapping is often necessary in those cases.
void foo()
{
tabif (someLongCondition
tab otherLongCondition
tab|| someOptionalCondition) {
tabtabdoSomething();
tabtabif (didSomething) {
tabtabtabdoSomethingElse();
tabtab}
tab}
}
3.3. SPACES
I would not go into that much detail. or maybe we should adopt/adapt a
strict coding guide like [2]?
Personally find it readable to use spaces before the parenthesis after
control statements, but not to use spaces before the parenthesis after
functions.
eg:
fn(foo, bar) / x(y) / y(z)
if (condition) / while (condition) / else (something else)
and use spaces after commas
fn(foo, bar, baz)
I find it less readable when the extreme is taken
fn( foo, bar, baz ) or worse fn( foo , bar , baz ), which I've seen both in
projects.
3.4. LINE ENDS
Unix/Linux line ending (Windows and OSX users have to adapt)
Um, is there any reason we're not just using
svn propset svn:eol-style native?
Seems like it solves the problem right there and everybody wins :) I've used
it on all my projects in the past, multiple platforms, and it always works
out. Also handles cygwin in Windows fine (uses LF, like you'd expect from a
posix layer, not CRLF, like Windows)
http://svnbook.red-bean.com/en/1.1/ch07s02.html
4. COMMITTS
It is tempting to clean up old code while fixing bugs or adding new
code. Please don't - it makes the
RE: Test Cases (was Re: [hugin-ptx] Re: nona-gpu - has anybody got it working?)
mhh... is yours 64bit? or 32bit? 64-bit through and through. Using a DLL version of Glut, rather than a static library, simply because it was convenient at the time. However, the error seemed to suggest to me it was a GPU allocation error and not a system allocation error. The memory usage of nona only peaked at ~100 megs when generating that error. --~--~-~--~~~---~--~~ 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: Boost not found
completely unrelated, but what is vc90.pdb? I suddenly see enormous numbers of this same warning: The Program Database Filename. If you look at a solution configuration, you'll see it is configured under Configuration Properties - C/C++ - Output Files. I'm guessing you probably cleaned your intermediate directories, since the default is $(IntDir)\vc90.pdb. The PDB files contents are controlled by the /Z switches (/Z7/Zi/ZI). The PDB contains the information necessary for debugging - symbolic names, types of variables, line numbers, etc. *Extremely* handy to have for production releases. I'm guessing that the linker errors are all related to SDK components built outside of the CMake process (eg: libpano, OpenEXR, etc). Many of the libraries in the SDK don't have explicit pathnames specified, hence the default vc90.pdb. For Hugin itself, and the other CMake projects, if you build RelWithDebInfo, you'll end up generating PDB files matching the names of the exes (Under Linker - Debugging - Generate Program Database File). It's by no means a critical error - it just means that symbolic debug information for that static library won't end up in the pdb for the executable. However, since the PDBs aren't being tracked for releases anyways, I wouldn't worry about it. Even if they were, they're not indexed (eg: with srcsrv from the Windows Debugging Tools), so debugging would still be a PITA. Nothing to worry about :) --~--~-~--~~~---~--~~ 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: branching and tagging releases
Anyway I shouldn't have brought up the subject, this is way off topic. I don't think so - how we organize ourselves is very much on topic. For what it's worth, I'd weigh in that what Yuval's proposing for the layout seems to make sense to me. The layout I'm accustomed to is akin to: root/ tags/ 0.7.0/ 0.7.1/ 0.8.0/ 0.8.1/ 0.8.2/ branches/ 0.7/ 0.8/ dev/ feature-a/ feature-b/ feature-c/ trunk/ The process I'm most accustomed to with SVN is: 1) Main development happens in trunk a) ... except when it involves significant rewrites or experimental features, which begin in dev branches first 2) Trunk is ideally kept compliable for nightlies - This is more about quality control than anything. Trunk being in an unstable state for more than a day or two often creates more headache, and suggests the feature may have been better beginning in a branch. 3) When certain objectives are met (either certain functionality goals being in place, or general timing), trunk is branched into a candidate branch 4) The branch is stabilized (which should already be so, more or less), with RCs coming from it. 5) A release is made from that branch when it is agreed to be stabilized. Optionally, it is tagged as well (which is more for convenience than anything - Again, it's cheap, and allows you to instantly find/browse the code for that release) a) Changes from that branch may either be periodically merged back into trunk during stabilization, or it may wait until the end. 6) Where do you put ongoing maintenance? There are several philosophies to this approach: a) The fixes start in the oldest maintained branch, and are successively merged forward through the branches. This is generally easy because each successive version is based on the code that preceded it, so there may not be as many conflicts. I've seen this on several commercial projects - You generally only have conflicts when merging old-new and new was rewritten. b) The fixes start in trunk, and are then (back-)ported to the various branches. This ensures that the fix for each branch is correct for each branch, but runs the risk of conflicts because newer code may have been substantially altered/refactored, and working backwards may not always be easy. Depending on the nature of the bug/fix, this may ensure better quality (by ensuring every fix is appropriate for each branch, rather than just straight merging), but may introduce more complexity (every merge conflicts from new-old if new was rewritten) c) Fixes only go into trunk. The maint branches are treated more like tags/stabilizers than statements of product versions. Major development happens out in dev branches. I've seen b) used frequently in cases where there are issues of API/compatibility. You want to keep the API stable for consumers of it, while at the same time, you want to fix bugs/security holes. PHP is an example of this. However, given that Hugin isn't really exposing APIs, and versioning of the project files themselves is largely a non-issue because they rarely change and is fairly standard, it sounds like c) is the better approach. The challenge in deciding how to do step 6 is, in my mind, largely dependent on what you define a minor version to be. The question is: What is the difference between Hugin 0.8.0, 0.8.1, and 0.9.0? Does 0.8.1 *only* address bugs and will never introduce new features? Then maybe a or b are the best approaches. Is Hugin 0.7.0 still supported when 0.8.0 is released, meaning bug fixes still need to make it in and a Hugin 0.7.1 is eventually released? Then again, maybe a or b are the best approaches. Or is the difference between 0.8.0, 0.8.1, and 0.9.0 that some new features are introduced between 0.8.0 and 0.8.1 (in addition to bug fixes), but that a longer-term rewrite of some core piece along with major new features is 0.9.0. If that's the case, then I'd say c probably sounds the most manageable, and it sounds the most akin to how the current dev lifecycle is. The question about versioning doesn't disappear by using a date-based alternative. In fact, I'd wager the date-based approach loses some of utility in communicating to people what the differences between A and B are. After all, Major.Minor.Rev is a well understood paradigm, even if there is significant debate over what is major and what is minor. Date-based just communicates that X is newer than Y, but that doesn't necessarily mean better or more stable. It also depends heavily on having a well-defined roadmap so you have an understanding of what can/will and cannot/will not make a particular release. Look at Ubuntu, the numerous meetings held for steering to maintain the 6-month active release and 2-year LTS release schedule, and you start to think Hugin is not quite there
[hugin-ptx] Re: 64-bit Windows Installers
So does there actually exist an installer for 64-bit, or am I going to have to compile this myself? The former would be more convenient, but the latter I don't mind doing excessively. The latter. 64-bit compilation is available only through a set of patches. You'll find instructions for building an x64 SDK here: http://wiki.panotools.org/Hugin_SDK_(MSVC_2008) SDK patches are here: http://sourceforge.net/tracker/?func=detailaid=2789320group_id=77506atid= 550443 Hugin patches are here: http://sourceforge.net/tracker/?func=detailaid=2787607group_id=77506atid= 550443 Enblend/Enfuse patches are here: http://sourceforge.net/tracker/?func=detailaid=2787615group_id=123407atid =696411 Once you have a 64-bit SDK, it's just a simple task of using CMake for Hugin as the same process as 32-bit. If you followed the wiki page, the 64-bit libs will have the same filenames as the 32-bit libs, so you won't just be able to switch configurations to compile 32-bit and 64-bit Hugin (instead, you'll need separate SDKs). --~--~-~--~~~---~--~~ 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-0.8.0 released
Hard to tell exactly what it might be, but the error is stemming from the fact that you have at least two instances of the JPEG/zlib libraries loaded (wxjpeg.lib and jpeg.lib via jpeg64.dll, wxzlib.lib z.lib via zlib1.dll). The latter for each of those is probably coming from one of the other libraries you built/linked (other than wxWidgets, since it contains its own). http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29_Patches details some of the changes necessary to the various libraries, which include updating them to point to wxWdigets for TIFF/JPEG/ZLIB where appropriate. If I were to wager though, you may want to check exiv2 to make sure it's linking right, but that's just a guess. Other than that, it's simply a matter of tracking down which library isn't linking against wxWidgets' implentation. You can always start with building a fresh SDK (http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 ) if you're still not able to trace it down. As to building the installer, I would suspect that Ad might be planning on doing it, given as how he's been building installers for XP/Vista x32 during development (http://adhuikeshoven.pbworks.com/hugin%C2%A0installer%C2%A0for%C2%A0Windows %C2%A0Vista ). He's got 4007 built, and IIRC, the only difference between 4007 and 4008 was a translation change. I don't know if anyone has stepped up for the Win x64 'release' build. Being in the US, I'm only really able to push a patent-free installer out, and if people drop in a CP gen that is 32-bit, it's possible there will be WoW64 issues with filenaming / reg keys / the like between Hugin (native x64) and the CP gen (32-bit). That's why I hope someone else can step up, so they can build/ship all the bins (including the CP generators) x64 and potentially dodge that problem. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: 64 bits versions
Nick, No one's stepped up to the role of being the binary builder. I haven't volunteered myself just because I wouldn't be able to compile everything - needing to leave off those tools affected by SIFT/SURF/other patents and the like (which should just be the CP generators, but still, an important part and part of the current distributions) I did, however, update the wiki at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 with the steps to building Hugin on x64, which should fully work with Visual Studio 2008, including Express Edition. If you are using Express Edition, you'll also need the Windows SDK 6.1/6.1a (or whatever is shipping), as that contains the x64 native compilers / x86-64 cross compilers. If using EE, you'll also need to enable the x64 compilers in EE, which requires a little trickery with the registry, but is documented in numerous places You'll also need to run several patches on the various parts of the SDK and Hugin. They are linked in that wiki page, but also found on the SourceForge Patches tracker (there are two patches - one for Hugin, one for the SDK). If you have any trouble, feel free to ask, as I've been running it fine on Vista x64 for over a month now. If there is anything in the wiki you find confusing or need clarification, feel free to ask and/or edit away to resolve that. I'm running on vista. Binaries would be nice, but if it works, but no binaries, then I'll build it myself. nick --~--~-~--~~~---~--~~ 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: 64 bits versions
So hugin works in 64. What about APSC, enblend and enfuse? Thanks, nick With the patches, they all work. Getting enblend/enfuse on 64-bit was the most onerous part, because a number of GNU dependencies are only distributed in 32-bit form. However, the wiki page details the steps necessary to compile them in 64-bit (and the appropriate patches as necessary), so they'll compile fine. I don't think APSCpp required any --~--~-~--~~~---~--~~ 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: 64 bits versions
Thanks for the info. Out of curiosity, is there a reason why it is not a single branch with 2 build targets, but one branch 32, and patches for 64? Thanks, nick That's definitely my goal and on my todo in the coming weeks. The big reason for it not being yet resolved is that the initial goal was to get it working, and get it out there, so that other people can reproduce it. There are a lot of hardcoded interdependencies in the project files on various libraries, and the projects come from several different distributions - some source, some binary, some from svn repos, etc. Being familiar with the process as I am now, it isn't a hard thing, in terms of technical difficulty, it's just a matter of going through everything and checking. My priority at present has been more in the experimenting with the low-hanging fruit of optimizations, as that seems to be able to benefit a larger crowd than the build process smoothing. The patches aren't just for 64-bit though, I should mention. The patches at present are meant to simplify a much longer process that even 32-bit users had to go through in resolving the various conflicts/issues (eg: updating solution files to VS2008, changing paths/dependencies, etc). It's just that the patches at present, in addition to resolving everything for 32-bit, introduce the new 64-bit configurations as options. You end up with 4 projects - Debug, RelMinSize, Release, RelWithDebInfo - and two configurations - 32-bit and 64-bit. You just can't change the configuration of Hugin without also going back through and updating a number of things (from enblend/enfuse to recompiling wxWidgets + OpenEXR etc) Does that help any? --~--~-~--~~~---~--~~ 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: Autopano-sift-c memory leaks
I know of no case in which such a failure has been replicated by a second observer. I have not yet been able to get APSCpp to exhaust memory on either Windows or Linux. And when I run it under a leak- checking debugger (MSVC on Windows, valgrind on Linux) I see no sign of memory leaks during the image processing phase. Both tools report a fairly large leak in the control point phase, which I will fix. That is a one-time thing and could not cause a crash during image processing. But under some conditions (that I have not found) it might conceivably build up to the point of exhausting all memory. Tom, what in your mind represents an 'ideal' memory size for APSCpp? My investigations into 64-bit compilation began first because APSCpp would regularly hork if I fed in all of my images, capping out at 2GB and eventually faulting. It would work fine if I broke my image sets into smaller chunks, but of course, that's a real pain to babysit. I didn't even realize the possibility of combining generatekeys + autopano as a means of optimizing the process, as it seems like it'd be a much more efficient means (esp. when combined with the future layout tool) Once 64-bit, running the same project through it (as inefficient as it may be), APSCpp got up to 6 gigs, but it found points without crashing. Like I said, from what I've learned, it's not the ideal way of generating control points, but it worked. The project itself was 90 TIFFs, comprised of 30 images with three exposures, with an overlap between 10 - 30%, arranged in 5ishx4ish (if I recall correctly), with some more detailed overlapping images. I didn't bother debugging anything, because I didn't have the dev environment setup, but I'll see about reproducing it next week. --~--~-~--~~~---~--~~ 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: Profile Guided Optimization
My experiences with profile-optimized code have been far less positive. For me the speed-up varied from several percent (Enblend, Enfuse, UFRaw) to actually slowing down the code (gcc). One explanation for my findings could be that I ran all of my tests on very fast machines, where it almost does not matter if their cores run at 2 GHz or at full speed. A closer look at the ratio of total stalls to executed instructions in time-critical tight loops showed values of 40% to 60%. In other words, on average the CPU is waiting for data a significant amount of time. What actually helps a lot here is compiling specifically for a CPU type as this not only enables all SSE1-999, but, e.g., also makes the compiler prefer conditional moves to jumps on architectures that support these instructions. Indeed, optimizations specific to the architecture definitely help. However, I'm wondering what sort of system you created the profile on. For myself and Rick, who are using the x64 version on Windows, we're sitting each with 8GB of ram. For many of my stitch jobs, Enblend and Enfuse never have to hit the internal image cache for LDR merges. For HDR merges, or for the extremely heavy stitch, yes, I can understand that those two in particular spend much more time in the image cache code than they do actually processing the work, but that's rare. Of course, for people constrained on x32 systems, this is less of a win for the them - 2GB isn't really a lot to be doing a big stitch on, and the moment they hit that, they're back to being IO bound, easily seeing the CPU usage drop from 50% on a dual core to 2/3%. However, if the compiler knows common sizes of data being requested - eg: this algorithm loops through every pixel, every pixel is an 8 bit uchar for RGBA, and the average size of this loop is on the order of hundreds of pixels, which I think are all realistic scenarios - it can both unroll the loop AND see about optimizing the loads with SSE (for Intel, via the -Q option). With the modern architectures supporting multiple execution pipelines, even on single cores (Intel's been doing it since, what, MMX?), combining PGO + architecture specific optimizations really can yield significantly better fetches. This may explain for some of the gains seen in the Windows, especially going from an x32 version that is both memory-bound and lacks a processor specific optimization, to the x64 binary, which is both no longer memory bound, allowing enblend/enfuse to focus on solely the computation tasks, and optimized for SSE, by virtue of it being available on both of the x86_64 architectures. Combine that with PGO requiring whole program optimization / link time code generation, and the compiler has more opportunity to leverage optimizations across various code blocks. Platform wise, GCC has supported PGO for some time, which means both Linux and Mac clients could potentially benefit from the process. BTW, profiling does _not_ produce reliable results with g++-4.3.2 and OpenMP. So we have to switch to other profiling techniques here. As far as I know, it's only your branch of enblend+enfuse using OpenMP currently, correct? And until the image cache is re-entrant, it's probably not going to be usable by anybody but those with large amounts of memory or smaller projects. Am I misunderstanding the limitation? I think this is an important consideration, definitely, but it sounds like it might not be a deal breaker, nor for some of the other tools in the chain (eg: Hugin's internal optimizations) So far, I've only messed with optimizing enblend/enfuse, which was promising, but PGO doesn't always benefit things for the amount of effort it can take. My experience is that certain things, especially template/functor heavy projects (which Hugin, with vigra, is), often benefit from PGO - Could you please explain that to me? Templated code in known to (sometimes) cause heavier execution-cache thrashing, because there is just more code around and more functions can get inline expanded. Does that indicate an advantage for profile optimizability? In my experience, template-heavy code will result in many different unique code paths being created: eg, a template for an image that is RGB with unsigned char, a template for an image with an RGB for float, etc. These then have further code paths when you throw in the functors, etc. In essence though, they're the same code (after all, it's the same template generating everything), but all with slightly different variants. I've yet to see a compiler get it right the first time, because the templates buy you a flexibility that the compiler doesn't know what your preference or ideal is. Because PGO often reveals a paths and relationships through the code, rather than structuring the code as TemplateA TemplateB FunctorTemplateA FunctorTemplateB it often optimizes to TemplateA FunctorTemplateA TemplateB FunctorTemplateB (poor
[hugin-ptx] Re: More on hugin vs DEP
Finally got a dump and had a chance to inspect.
The DEP crash itself is being caused by atioglxx.dll, which is ATI's OpenGL
driver. I don't have symbol files for it, so I can't trace, but the path
that Hugin takes that causes this crash:
hugin.exe!GLRenderer::Redraw() Line 110C++
hugin.exe!GLViewer::Redraw() Line 198 C++
hugin.exe!GLViewer::RedrawE(wxPaintEvent e={...}) Line 154 C++
hugin.exe!wxAppConsole::HandleEvent() + 0xd bytes C++
hugin.exe!wxEvtHandler::ProcessEventIfMatches() + 0x53 bytes C++
hugin.exe!wxEventHashTable::HandleEvent() + 0x5a bytes C++
hugin.exe!wxEvtHandler::ProcessEvent() + 0x6c bytesC++
hugin.exe!wxWindow::HandlePaint() + 0xb4 bytes C++
hugin.exe!wxWindow::MSWWindowProc() + 0x18d bytes C++
hugin.exe!wxWndProc() + 0x8d bytes C++
The exact line that caused the crashed was:
glClear(GL_COLOR_BUFFER_BIT);
Anybody with more wizardry care to offer advice?
My first advice for Howard is to check for updated ATI drivers, since the
crash is within the drivers themselves, and as far as I know, there isn't
any attempt to execute any code in the GL fast preview window. Unless
someone knows better, I would say this problem is solely in the ATI drivers,
and Howard's workaround (if updating fails) is to disable DEP.
It's been situations like this that have left me disabling DEP - A good
technology, in general, but too many vendors are still way too sloppy.
--~--~-~--~~~---~--~~
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 Windows SDK -- wxWidgets not found
Hugin requires wxWidgets 2.8.10 as of SVN 3842, according to the CMakeLists. Is it possible you've got an older version? The build steps on the SDK reference using wxWidgets 2.8.10, and there is a more recent SDK package posted from May also up on the wiki. Might be time to update :) -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Tom Sharpless Sent: Thursday, July 09, 2009 4:25 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Hugin Windows SDK -- wxWidgets not found Hi Have been building Hugin on Windows now and then, using the SDK that was put together by Guido K. about 6 months ago. Just updated my Hugin source to SVN 4017, and get CMake error cant'f find REQUIRED package wxWidgets.. This is coming from the standard findwxwidgets.cmake script that is distributed with CMake, not from a hugin custom script -- as I think it should be if the Windows SDK were being properly supported and wxWidgets really was missing (actually on my system there would be no error message, because wxWidgets is indeed in the SDK). I'm sure I can find fix the problem, but I'm posting to ask all Hugin developers to be aware that there are special problems with finding packages in the Windows Hugin build environment, and special CMake code to handle them. So please be careful about rearranging FIND_PACKAGE calls and related code in the CMake scripts -- preferably test with a Windows builder before committing. -- Tom --~--~-~--~~~---~--~~ 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: More on hugin vs DEP
Where were the absolute module references to? Hugin.exe, rsaench, or other modules? RSAENH is just the Microsoft RSA Enhanced Cryptographic Service Provider, which is the crypto core of Windows. I'm surprised DEP is flowing through there, as nothing in Hugin or the tools is going to pull in that DLL directly. Since you're working on debugging yourself, have you added the Microsoft Symbol Store to your symbol search path? Information is at http://stackoverflow.com/questions/556383/how-to-use-windows-symbol-packages -with-visual-studio-2008 If it's in hugin.exe that you're having trouble resolving, if you're using an exe you built, make sure you built the package RelWithDebInfo. If you're using the one I posted for x32, it was built with this as the config, so I have all of the (rather large) PDBs for the entire SDK and for Hugin. That's why I was asking for a crashdump file, as it's easier to send the crashdump than all the PDBs. I didn't generate the MAP files, so that's really the best way to get to the bottom of this. The crashdump will give the full stack trace/line references/etc, so with that it'd be something that could be immediately pinpointed. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of hbl Sent: Thursday, July 09, 2009 4:15 PM To: hugin and other free panoramic software Subject: [hugin-ptx] More on hugin vs DEP DEP (actually rsaenh.dll) is raising an exception at some point after wxDropTarget:Register() is entered. After that point, there were no more module references; just calls to absolute memory locations. So, I am not sure the trail leads to atioglxx.dll as the source of the issue. Comments? --~--~-~--~~~---~--~~ 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: More on hugin vs DEP
Since you're building your own, I'm presuming you've got Visual Studio 2008 Express installed (Unless you're going the nmake route, which I haven't bothered with). If so, you should be able to compile the exe as RelWithDebInfo, but launch the exe any way you want. You don't need to start it through the debugger. With the hugin .sln still open, choose Debug - Attach to Process. From there, you should be able to attach to hugin.exe. When DEP triggers, it should (IIRC) invoke the debugger to handle the exception as a first resort. I can't remember for sure if that's the case though - If it doesn't, you can configure the Debug - Exceptions (Control Alt E). Under Win32 Exceptions, make sure that c005 Access Violation is checked. That's what will end up getting thrown when DEP triggers. Click OK. From there, VS should be able to tell a bit more about the stack trace of what triggered the DEP error. When VS catches the error, it will then try to pull in the .pdbs for Hugin, as well as download any PDBs available on the MSFT Symbol Store URL. This should give you maximal stack information. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of hbl Sent: Thursday, July 09, 2009 5:09 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: More on hugin vs DEP Ryan, Thanks for the input. My software debug skills have laid dormant for a decade or so. I will download the additional symbols and start the tracing process again. I built using the 'debug' option. I will rebuild using 'release w/ debug info'. The absolute addressing had no notation as to source code names. Probably because the symbols were missing. I assume rsaenh was the messenger because it was the last module loaded right after atioglxx. I also have someone in the Toshiba help group looking at the issue. I tried to attach to the Fast Panorama Preview process but the system would not allow it. I shall review the procedure and try again. -- Howard On Jul 9, 3:35 pm, Ryan Sleevi ryan+hu...@sleevi.com wrote: Where were the absolute module references to? Hugin.exe, rsaench, or other modules? RSAENH is just the Microsoft RSA Enhanced Cryptographic Service Provider, which is the crypto core of Windows. I'm surprised DEP is flowing through there, as nothing in Hugin or the tools is going to pull in that DLL directly. Since you're working on debugging yourself, have you added the Microsoft Symbol Store to your symbol search path? Information is athttp://stackoverflow.com/questions/556383/how-to-use-windows-symbol- p... -with-visual-studio-2008 If it's in hugin.exe that you're having trouble resolving, if you're using an exe you built, make sure you built the package RelWithDebInfo. If you're using the one I posted for x32, it was built with this as the config, so I have all of the (rather large) PDBs for the entire SDK and for Hugin. That's why I was asking for a crashdump file, as it's easier to send the crashdump than all the PDBs. I didn't generate the MAP files, so that's really the best way to get to the bottom of this. The crashdump will give the full stack trace/line references/etc, so with that it'd be something that could be immediately pinpointed. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin- p...@googlegroups.com] On Behalf Of hbl Sent: Thursday, July 09, 2009 4:15 PM To: hugin and other free panoramic software Subject: [hugin-ptx] More on hugin vs DEP DEP (actually rsaenh.dll) is raising an exception at some point after wxDropTarget:Register() is entered. After that point, there were no more module references; just calls to absolute memory locations. So, I am not sure the trail leads to atioglxx.dll as the source of the issue. Comments? --~--~-~--~~~---~--~~ 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: Profile Guided Optimization
Hi Ryan, interesting stuff. do you do this kind of things for a living? To a degree. I work on a commercial project where three of the main demands are small, fast, and portable, so these sorts of things come up often - OpenMP, Intel VTune/IPP/C++ Compiler, and x64 all end up being part of that scope. The multiplatform diagnostics/support angle comes from it being a commercial product, so there is always financial incentive to identify bugs quickly, so I get to learn first-hand how screwed up the ALL the different platforms are and their little nuances, for better or worse ;) The time I want to optimize is the time I am interacting with the computer. the faster the computer the less of my time it wastes. The time I don't care about is warping / blending /etc . CPU time on an overnight batch is cheap, so if the stitch takes from 21:00 PM to 07:00 AM next morning; or to 03:00 AM next morning; I won't notice. The great thing is that because Hugin is so nicely split into the various utilities, you can both have your cake and eat it too! The hugin executable can be optimized for the more intensive tasks, which I agree with you in that it's probably: - Optimization - CP editing/fine tuning - Preview (Fast and regular, although regular is less of a concern now that fast preview is in) - Celeste (I haven't dug too far into this, but I understand it's both linked as a lib and standalone. Sound correct?) - To a lesser degree, some of the basic imaging code for caching/scaling the images. At the same time, enblend, enfuse, nona, and all the other separate executables, can be optimized independently, unrolling the tight loops and expanding their optimizations, without having to sacrifice any of the improvements in the hugin GUI. In asking the question, I'm wanting to find out what the knife is in the Hugin swiss army toolset, which most everybody uses (and as the primary reason), and not worry about the fish scaler or scissors that nobody ever wastes time with because there are usually better alternatives for those sorts of tasks :) Sharp knife is a win, while a nail filer with extra smooth filing action, not so much. My plan is to first get a bit more testing done with the timing of things, using two of my larger projects for testing (one for profiling, the other for testing), to see what kind of improvements, if any, we're talking about. So far, I've only messed with optimizing enblend/enfuse, which was promising, but PGO doesn't always benefit things for the amount of effort it can take. My experience is that certain things, especially template/functor heavy projects (which Hugin, with vigra, is), often benefit from PGO - Primarily around loop unrolling, inlining, and code locality reorganizing. If it continues to look promising (and this is where the input from the list is going to inform), the next step would be setting up some various project files to represent 'real world' scenarios (eg: a large stitch of 8-bit TIFFs, a 360 stitch of 16-bits, and maybe a small project stitch of a few JPEGs), which would be the tool profilers and can be automated as an optional step in the build, and a test script, to be manually stepped through by the person compiling, for the actual Hugin GUI. These would be platform-independent, as anyone wanting to make a PGO binary could, but standardizing ensures the optimizations aren't too heavily focusing on one thing, the computing equivalent of doing all sit-ups, never any cardio or strength training. Of course, for those interested in speed and handy with a compiler, you can start working on PGO binaries for Linux/Mac, and see how GCC's optimizer works for the project and if it shows similar improvements. For GCC, the flags are -fprofile-generate and -fprofile-use. It's also encouraging to see that work is being done in Christoph's branch to add OpenMP support to enblend/enfuse, as that may likely offer substantial speed improvements for those running on more modern, multi-core systems, well beyond what PGO could offer. It may not directly speed the UI experience, sure, but everybody loves a quicker work flow. --~--~-~--~~~---~--~~ 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 installer for Windows Vista SVN 3975
and with you and your expertise around I allowed myself to note that 64bit Windows is now supported. Well, it's only supported if those two patch sets get merged upstream prior to 0.8 (your prior e-mail asking for thoughts). My belief is they should be very minor (the patches to Hugin itself, really Vigra, were straight from upstream just backported). The patches to the supplementary products are (more or less) just patching the solution files, although other projects that use Vigra had a few changes applied to them as well. I'll try to update the libpano .sln patch (part of the second set), since I found I missed something with x64 on it. Will you contribute a 64bit installer of 0.8.0 final after Bruno released it? With regards to the installer itself, my process has not been clean. I get several errors with the .iss that I haven't bothered to look deeper into. Mostly issues with matchnsift/matchpoint/perl files being missing. I haven't bothered to look into this, because it hasn't affected my personal usage, but it would be a hindrance towards a 'proper' release. The other part is still my own personal concern regarding the patented code and compiling it - being an American and all. The whole distinction of direct and indirect infringement is a point of concern. As to the steps/compilation themselves, the process can be fully accomplished with Microsoft's free-as-in-beer toolchain. The x64 compilers, while not native to the Visual Studio 2008 Express Edition, can be obtained from the Windows Platform SDK 6.1 and native x64 binaries compiled (or cross-compiled, for those on x32). Using the Express Edition requires one extra step (as documented at http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and -64-bit-targets/ ), but otherwise, compilation should prove quite smooth. --~--~-~--~~~---~--~~ 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: Results for Ryan Sleevi SVN 0,8,0,3980
Howard, Can you e-mail me off-list with a dump created by following the steps in http://support.microsoft.com/kb/931673 ? The output you pasted looks to be the result of the standard Vista/Microsoft mini-dump submission. When that dialog is up, you should still have hugin.exe running, so you should be able to follow the directions per that KB article to create a user-mode process dump (prior to responding to that dialog). That will include the full stack-trace, threads, etc. It should output the dump file in C:\Users\(Username)\AppData\Local\Temp Alternatively, you can look at the directions here, http://support.microsoft.com/kb/828222 , which are a bit more convoluted and requires a bit more installation. You follow the directions up to (but not including) the step Configure the Orphan Worker Process settings. When Hugin crashes, run the batch file with the argument of the path to your hugin executable (eg, if using Action.cmd as they did, you'd run 'C:\action.cmd C:\Program Files\Hugin\bin\hugin.exe ' assuming that is the path to the executable). If I recall correctly, this should result in a file being placed in C:\Program Files\Hugin\bin named either hugin.exe.dump or hugin.dump. Or it might be in C:\ as hugin.dump. Compress using your favored compression algorithm (preferably something that 7-zip supports and not something obscure and esoteric) and mail to me direct, and I'll see about looking in to it further as well as posting the stack trace back to the list for those more in the know. Either of the methods described in the KB are the preferred method, rather than sending the diagnostics created by the 'stock' Windows dump tool (more information is included) Cheers, Ryan -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of hbl Sent: Monday, July 06, 2009 2:10 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Results for Ryan Sleevi SVN 0,8,0,3980 Test results for http://ryan.sleevi.com/files/hugin-0.8.0-3980.exe The application is halted by DEP the moment the Fast Panorama Preview window opens (thread 0x1574). Diagnostic data follows: Product hugin.exe Problem Stopped working Date 7/6/2009 12:50 PM Status Report Sent Problem signature Problem Event Name: BEX Application Name: hugin.exe Application Version: 0.0.0.0 Application Timestamp:4a4c2d02 Fault Module Name:StackHash_d34b Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Offset: 06c50840 Exception Code: c005 Exception Data: 0008 OS Version: 6.0.6002.2.2.0.768.3 Locale ID:1033 Additional Information 1: d34b Additional Information 2: 20752c25712bf3f7bc825928e900516d Additional Information 3: cec3 Additional Information 4: 8f23bb82232ba5bb3e019c420185df34 Extra information about the problem Bucket ID:635354591 = 'hugin.exe': Loaded 'C:\Program Files\Hugin\bin\hugin.exe' 'hugin.exe': Loaded 'C:\Windows\System32\ntdll.dll' 'hugin.exe': Loaded 'C:\Windows\System32\kernel32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\user32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\gdi32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\advapi32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\rpcrt4.dll' 'hugin.exe': Loaded 'C:\Windows\System32\opengl32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\msvcrt.dll' 'hugin.exe': Loaded 'C:\Windows\System32\glu32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\ddraw.dll' 'hugin.exe': Loaded 'C:\Windows\System32\dciman32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\setupapi.dll' 'hugin.exe': Loaded 'C:\Windows\System32\oleaut32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\ole32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\dwmapi.dll' 'hugin.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common- controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl3 2 .dll' 'hugin.exe': Loaded 'C:\Windows\System32\shlwapi.dll' 'hugin.exe': Loaded 'C:\Windows\System32\shell32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\comdlg32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\imm32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\msctf.dll' 'hugin.exe': Loaded 'C:\Windows\System32\lpk.dll' 'hugin.exe': Loaded 'C:\Windows\System32\usp10.dll' 'hugin.exe': Loaded 'C:\Windows\System32\ws2_32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\nsi.dll' 'hugin.exe': Loaded 'C:\Windows\System32\ntmarta.dll' 'hugin.exe': Loaded 'C:\Windows\System32\Wldap32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\psapi.dll' 'hugin.exe': Loaded 'C:\Windows\System32\samlib.dll' 'hugin.exe': Loaded 'C:\Windows\System32\uxtheme.dll' 'hugin.exe': Loaded 'C:\Windows\System32\BtMmHook.dll' 'hugin.exe': Loaded 'C:\Windows
[hugin-ptx] Re: Results for Ryan Sleevi SVN 0,8,0,3980
The use of the /clr flag should be unnecessary. /clr is intended for compiling C++/CLI code (as Managed C++ has gone the way of the dodo...). The documentation is at http://msdn.microsoft.com/en-us/library/k8d11d4s.aspx , so I'm curious what lead you to the /clr option. I do know ATI makes semi-heavy use of the .NET assemblies in their driver utilities (or at least did when I had a Radeon in here), but I don't believe the actual driver itself would be using any .NET-ness. Either way, it sounds like the DEP error is (like I originally mused) unrelated to Hugin itself, and more the result of a faulty something else that is getting blamed against Hugin. Which is encouraging for the release to make it out. -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of hbl Sent: Monday, July 06, 2009 7:08 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: Results for Ryan Sleevi SVN 0,8,0,3980 Ryan, It appears the exception is occurring in atioglxx.dll. It's associated with the ATi Radeon video driver. The purported solution is to build with /clr property. Currently trying to validate... On Jul 6, 1:54 pm, Ryan Sleevi ryan+hu...@sleevi.com wrote: Howard, Can you e-mail me off-list with a dump created by following the steps inhttp://support.microsoft.com/kb/931673? The output you pasted looks to be the result of the standard Vista/Microsoft mini-dump submission. When that dialog is up, you should still have hugin.exe running, so you should be able to follow the directions per that KB article to create a user-mode process dump (prior to responding to that dialog). That will include the full stack-trace, threads, etc. It should output the dump file in C:\Users\(Username)\AppData\Local\Temp Alternatively, you can look at the directions here,http://support.microsoft.com/kb/828222, which are a bit more convoluted and requires a bit more installation. You follow the directions up to (but not including) the step Configure the Orphan Worker Process settings. When Hugin crashes, run the batch file with the argument of the path to your hugin executable (eg, if using Action.cmd as they did, you'd run 'C:\action.cmd C:\Program Files\Hugin\bin\hugin.exe ' assuming that is the path to the executable). If I recall correctly, this should result in a file being placed in C:\Program Files\Hugin\bin named either hugin.exe.dump or hugin.dump. Or it might be in C:\ as hugin.dump. Compress using your favored compression algorithm (preferably something that 7-zip supports and not something obscure and esoteric) and mail to me direct, and I'll see about looking in to it further as well as posting the stack trace back to the list for those more in the know. Either of the methods described in the KB are the preferred method, rather than sending the diagnostics created by the 'stock' Windows dump tool (more information is included) Cheers, Ryan -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin- p...@googlegroups.com] On Behalf Of hbl Sent: Monday, July 06, 2009 2:10 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Results for Ryan Sleevi SVN 0,8,0,3980 Test results forhttp://ryan.sleevi.com/files/hugin-0.8.0-3980.exe The application is halted by DEP the moment the Fast Panorama Preview window opens (thread 0x1574). Diagnostic data follows: Product hugin.exe Problem Stopped working Date 7/6/2009 12:50 PM Status Report Sent Problem signature Problem Event Name: BEX Application Name: hugin.exe Application Version: 0.0.0.0 Application Timestamp: 4a4c2d02 Fault Module Name: StackHash_d34b Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Offset: 06c50840 Exception Code: c005 Exception Data: 0008 OS Version: 6.0.6002.2.2.0.768.3 Locale ID: 1033 Additional Information 1: d34b Additional Information 2: 20752c25712bf3f7bc825928e900516d Additional Information 3: cec3 Additional Information 4: 8f23bb82232ba5bb3e019c420185df34 Extra information about the problem Bucket ID: 635354591 = 'hugin.exe': Loaded 'C:\Program Files\Hugin\bin\hugin.exe' 'hugin.exe': Loaded 'C:\Windows\System32\ntdll.dll' 'hugin.exe': Loaded 'C:\Windows\System32\kernel32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\user32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\gdi32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\advapi32.dll' 'hugin.exe': Loaded 'C:\Windows\System32\rpcrt4.dll' 'hugin.exe': Loaded 'C:\Windows\System32\opengl32.dll' 'hugin.exe': Loaded 'C:\Windows
[hugin-ptx] Re: can not find the file(enblend/INSTALLDIR )
Enblend/Enfuse don't use the CMAKE-based system that Autopano-sift-c and Hugin use. As a result, binaries are not deployed into an INSTALLDIR location. Instead, once compiled, they are typically located in enblend-enfuse-3.2-dir\src\Debug and enblend-enfuse-3.2-dir\src\Release , where enblend-enfuse-3.2-dir is the directory where you deployed the enblend-enfuse-3.2 sources. Are you having trouble with the CMAKE file for Hugin locating these files, or were they just not where you expected them to be? -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Dex Sent: Sunday, July 05, 2009 3:18 PM To: hugin and other free panoramic software Subject: [hugin-ptx] can not find the file(enblend/INSTALLDIR ) Hi all! I have tried to build enblend on Windows according to http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK but I am experiencing problems. 2Linking... 2Generating code 2d:\panorama\huginbase\enblend\src\mask.h(117) : warning C4756: overflow in constant arithmetic 2d:\panorama\huginbase\enblend\src\mask.h(117) : warning C4756: overflow in constant arithmetic 2d:\panorama\huginbase\enblend\src\mask.h(694) : warning C4756: overflow in constant arithmetic 2d:\panorama\huginbase\enblend\src\mask.h(694) : warning C4756: overflow in constant arithmetic 2Finished generating code 2Embedding manifest... 2Build log was saved at file://d:\panorama\huginbase\enblend\src \Release\BuildLog.htm 2enblend - 0 error(s), 15 warning(s) == Rebuild All: 2 succeeded, 0 failed, 0 skipped == but i can not find the file enblend/INSTALLDIR --~--~-~--~~~---~--~~ 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 installer for Windows Vista SVN 3975
Only if you like debugging Windows ;) What I meant by DEP being more headache is that there are any number of reasons that DEP can be triggered independent of Hugin, so it may not be a legitimate bug. An example to illustrate this (with all of its frustration) is some recent heartache I had with a certain laptop manufacturer that sounds like Bell and the drivers they supplied for the built-in biometric device. The security functions of the drivers ended up hooking into several Windows API calls for filesystem access (yes, you can do this, and there are a number of legitimate reasons - most popular being anti-virus/security products). Unfortunately, these drivers had a bug (if we count suck as a bug) and it had a huge negative impact on my system performance. Compiling one of the projects I work on, which has thousands of files and hundreds of thousands LOC took almost 100x longer than normal, and eventually failed, because there was a leak in the drivers. A quick uninstall, and my system was back to screaming performance. Consider then, the situation if these drivers had a buffer underrun/overrun. In Windows, the DEP exception would be triggered, and it would work its way up to the stack, finally into the application that made the OS call (which it didn't know was being hooked by the buggy app). That app would then terminate, with the user being told it was that app that was buggy. I wish I could say situations like this are uncommon, but I see regularly applications that instill themselves into critical locations (shell handlers, API hooks, control panel drivers) that are buggy, and because of how the exception works its way up the chain, it ends up crashing a perfectly benign application (as it cannot control for those crashes). That's just the frame of mind I'm in with regards to researching this, is that past experience, especially with DEP, by no means signifies a bug in Hugin necessarily. While still worth investigating, I would not think this bug (especially with the difficulty reproducing) should be considered a 'block' in any means. Cheers, Ryan -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of Yuval Levy Sent: Thursday, July 02, 2009 4:01 PM To: hugin-ptx@googlegroups.com Subject: [hugin-ptx] Re: hugin installer for Windows Vista SVN 3975 Hi Ryan, ryan+hu...@sleevi.com wrote: To be fair, DEP has caused me more headache than it's worth, simply because the sheer number of buggy programs out there. in this case DEP may prove to be a debugging tool :) honestly I don't think that researching DEP is of any help in his context. If DEP had not caught the buffer overflow, it may have gone unnoticed for a longer while. We have an issue to take care of in the Hugin codebase or in an SDK component. Once it will be fixed it won't be relevant to DEP anymore. 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: hugin installer for Windows Vista SVN 3975
Howard, I've enabled DEP on my system, and the programs I know to have trouble do properly report BEX errors, so I know DEP is getting raised appropriately. I've also confirmed with wmic that all the settings reflect its enabled, with a value of True, 3, as you did. I went ahead and built a binary based on the latest SVN (for native x64), through the full build process, including the installer. I opted for x64 since, as noted in the Microsoft KB article and the prior e-mail, always good to match platform and application. I've tried several scenarios, loading old projects, TIFFs and JPGs, etc, and had no problem. Certainly, there are a lot of variables at play here, so it may take some time to isolate. In the mean time, I'd suggest following Yuval's directions of trying the last 'certified' version, in attempt to find the basement on when this issue might have first been introduced. This should be fairly easy and non-invasive. What I'd like to try as a next step, as a means of hopefully getting more information, is getting a crashdump from you when a DEP error has been raised. It's been a while since I've had to do it by hand (tend to use API-based hooks to catch when an application crashes), so I hope you'll bear with me if I direct you down the wrong path once or twice. Since you mentioned Vista, the following KB article may help: http://support.microsoft.com/kb/931673 Since I don't have the symbols Ad used for his installer, I'll be mailing you off-list a 32-bit based version on the latest SVN that I'll compile locally. This will ensure I have the necessary debug symbol files to wind through the stack. If this is a concern for you, we can work off-list on directing the necessary compilation steps, just be aware that it's not uncommon for symbols to reach hundreds of megs for large projects. Once you've gotten the new setup binary and everything is installed, when you get an application crash (eg: due to DEP), see if you can follow the directions of Method 1 as a means to intercept the crash. Once you have that crash (located in the path specified), can you attach it and e-mail it to me off-list? I'm not sure the default settings of Vista for creating crashes, but a simple Crashdump of Notepad is around 50 megs. If it's too large to e-mail, we can work off-list on a transfer mechanism. By all means, compress compress compress! If you're unable to generate a crashdump once it's raised a DEP error, let me know, and I'll see further if I can investigate. For those following on-list, especially Bruno, if a final 'formal' Win32 build is released, it might help to keep the symbol files around. Certainly users can build their own binaries, preserve the symbol files, and debug themselves, but given how most Windows users aren't necessarily handy with compiling and debugging their software, it may be helpful for some of the weird bugs that remain post-release (as I recall, there are a few mystery ones out there affecting Windows users) Ryan -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of hbl Sent: Wednesday, July 01, 2009 9:02 PM To: hugin and other free panoramic software Subject: [hugin-ptx] Re: hugin installer for Windows Vista SVN 3975 Thanks for checking in, Ryan. My notebook has the 32-bit version of Vista Home Premium. I suspect hardware detection is on as I have turned off sw detection using bcdedit. On hardware enforcement, I get True, 3. On Jul 1, 7:38 pm, ryan+hu...@sleevi.com wrote: Howard, Would you mind checkinghttp://support.microsoft.com/kb/912923and reporting back a bit more about the values from WMIC? I'm hoping to identify: 1) Are you using hardware-enforced DEP? 2) What the current value is for the Windows enforcement of it 3) Any possible hardware switches (Note the last line of Method 1) In addition to the information wmic will provide, can you also tell me: 1) Which mobel Toshiba laptop (Trying to understand processor architecture) 2) What version of Windows you're running (Full version string of major/minor/build + 32 bit or 64-bit) If I followed the thread correctly, I understand you can and have compiled your own versions. If you are running on a 64-bit platform with a 64-bit OS, are you compiling 64-bit Windows binaries or the default 32-bit ones? I'm suspecting based on your description that you're on 32-bit and running 32-bit, I just wanted to make sure, since DEP can get weird when there are mismatches. To be fair, DEP has caused me more headache than it's worth, simply because the sheer number of buggy programs out there. It's a trade- off between hard crashes (because of the NX bit being triggered) or soft crahses + potential security
RE: hugin-mac-0.8 RC1: enblend compiled against dmalloc (was: [hugin-ptx] Alpha Channel Masking)
Just an update. I was the one who contacted George about getting the sample files. I've done the merge several times to make sure it wasn't tester error, with both x64 and win32 versions. The x64 I made by hand, while the win32 versions I used from Ad's most recent weekly installer build. Both successfully executed a number of test cases without any errors. I've tried without specifying -m, by specifying -m 1024, -m 2048, and (for the x64 build) -m 4096. Having looked at the strace, it looks like the place where things start to get all crazy is right near/after vigra::CachedFileImagePIXELTYPE::swapOutBlock() / vigra::CachedFileImagePIXELTYPE::getLinePointerCacheMiss() / vigra::CachedFileImagePIXELTYPE::initTmpFile() It should be noted that these methods have different code paths depending on if they're running on Win32 or not (per the ifdef), so that may be related to why I'm unable to reproduce it. If someone who is building binaries wants to strip out some of the comments in those functions, which should increase the debug chatter, it might help. Then again, I could be totally off here as to where the real error is. If I were a betting man/a man prone to donning tinfoil hats (which I am...), I'd be curious to check out getLinePointerCacheMiss(), and the variables blockNumber, firstLineInBlock, numLinesInBlock, and pixelsToRead. If there somehow ended up some over/underflow errors there, and if (blockInFile_[blockNumber]) returned false, then std::uninitialized_fill_n ends up getting called. n, in this case, is pixelsToRead. The result *could* be what is described here, in that it then goes buck-wild on allocation. Judging by the number of calls to brk (12679, give or take a few), I'd set a watchpoint around that code, and see if anything gets crazy. That's just my guess :) It wouldn't hurt for somebody to cout some debug spam for those variables and rebuild enblend/enfuse, if attaching gdb is too much of a pain. For those following, the calls to brk/mmap come from dmalloc, specifically heap.c, under heap_extend. I'm guessing this is being called by the uninitialized_fill_n (STLPort - _unitialized.h - __uninitialized_fill_n - __ufill_n), which is calling the constructor of PIXELTYPE to initialize the pixels (_construct.h - _Param_Construct - _Param_Construct_aux) -Original Message- From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On Behalf Of grow Sent: Monday, May 11, 2009 4:15 PM To: hugin and other free panoramic software Subject: Re: hugin-mac-0.8 RC1: enblend compiled against dmalloc (was: [hugin-ptx] Alpha Channel Masking) Harry, My Mac is an old twin processor G5 with 5.5Gb of RAM. So it has the potential for 64 bit operation. But it is still running MacOSX 10.4.11 I have the disc here for 10.5 and have been meaning to install it for some time ... but have not yet got around to it. This might just be the incentive I have needed to get 10.5 installed - but the weather here is good and I am on an outdoor photo shoot tomorrow and Wednesday so ... it will probably be the weekend before any software installation happens. all the best George On May 11, 7:28 pm, Harry van der Wolf hvdw...@gmail.com wrote: George and others, There are two options to try 64bit on OSX *Option 1*: (Download again and) use the official 0.7.0 version from sourceforge. That one is a 32bit/64bit version. A G5 is a 64bit machine (the only ppc 64bit machine). However, it will only work as 64bit* if you have Leopard!* Tiger is only 32bit, no matter which platform you run it on. Every Intel core2 or newer is 64bit. With Leopard that will enable 64bit applications. *Option 2:* On my website you can still find the 64bit stand-alone enblend version from svn 3176 http://panorama.dyndns.org/download.php?id=241. If you download that one and copy it in the latest build, you could try that one too. (Actually the only binary that really benefits from 64bit is enblend, so you might give that a try) To get it in one of the latest hugin.app's do the following: - right-click (ctrl-click) the Hugin.app. Select Show package content from the popup. - Move down into Contents - Resources There you will find HuginStichProject.app. - Right-click (ctrl-click) the HuginStichProject.app and select again Show package content. - Move down into Contents - MacOS. Copy the downloaded 64bit enblend over that existing enblend. *Note: Again, only within Leopard and only on G5 or Intel Core2 (or newer) 64bit applications will run as 64bit* Note 2: The malloc libs on Leopard are 32bit/64bit libraries. In combination with a 64bit enblend (on Leopard) it will run in 64bit mode. Harry 2009/5/11 grow george...@gmail.com Hi Folks, Another person - Ryan - downloaded the problematic project and ran it on a 64 bit Windows system and it worked!. He had also added options: -v - v
