From michael.rosen at gmail.com Mon Oct 5 13:24:39 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Mon, 5 Oct 2015 10:24:39 -0700 Subject: [Kwiver-users] MapTK issues on Windows Message-ID: Hello Kwiver-folk, I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. MapTK is version 0.6.0, Eigen is 3.2.6 I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj pos2krtd.cxx C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't be aligned C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't ? I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: /// Convert a POS file to a KRTD file bool convert_pos2krtd(const maptk::path_t& pos_filename, const maptk::path_t& krtd_filename, maptk::local_geo_cs& cs, maptk::camera_d& base_camera, // msr. was pass-by-value maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe ... Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen 3\eigen\src/Core/DenseStorage.h, line 86 The web page says that classes which contain certain Eigen data structures as members need to use the EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. Can anyone offer insight into any of this? msr -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Tue Oct 6 13:36:27 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Tue, 6 Oct 2015 13:36:27 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: Message-ID: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> Michael, Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? git fetch origin pull/88/head:dev/camera-pass-by-reference git checkout dev/camera-pass-by-reference If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. ?Matt > On Oct 5, 2015, at 1:24 PM, Michael Rosen wrote: > > Hello Kwiver-folk, > > I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. > > MapTK is version 0.6.0, Eigen is 3.2.6 > > I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: > > [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj > > pos2krtd.cxx > > C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't > > be aligned > > C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't > > ? > > > I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: > > > /// Convert a POS file to a KRTD file > > bool convert_pos2krtd(const maptk::path_t& pos_filename, > > const maptk::path_t& krtd_filename, > > maptk::local_geo_cs& cs, > > maptk::camera_d& base_camera, // msr. was pass-by-value > > maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) > > > > That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: > > > C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe > > ... > > Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d > ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen > > 3\eigen\src/Core/DenseStorage.h, line 86 > > > The web page says that classes which contain certain Eigen data structures as members need to use the > > EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. > > > > Can anyone offer insight into any of this? > > > > msr > > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Tue Oct 6 15:38:53 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Tue, 6 Oct 2015 12:38:53 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> Message-ID: Thanks for this. It compiles and the assert is gone. To be clear, here's what I did: git clone https://github.com/Kitware/maptk.git cd .\maptk git fetch origin pull/88/head:dev/camera-pass-by-reference git checkout dev/camera-pass-by-reference cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" nmake nmake install Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? msr On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta wrote: > Michael, > > Thank you for reporting this issue. I?ll be upfront and warn you that I?m > not a Windows developer and MAP-Tk is currently better tested on Linux and > Mac. That said, we are working toward getting things better running on > Windows more reliably. > > In this case, the issues are related to Eigen byte-alignment issues as > explained on the Eigen website linked from your error message: > > http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html > > I have read this page before, and expected I would need to make changes at > some point to work around these issues, but until now I had not come across > a compiler that exhibited these symptoms. We should probably try to get a > VisualStudio 2012 build up on our dashboard so I can work through those > issues properly. I expect that will take some time. A shorter term > solution is to try to disable alignment in your build. Can you try the > solutions described at the bottom of the page at the above URL? In the "I > don't care about vectorization, how do I get rid of that stuff?? section it > suggests defining some macros to disable alignment. Let me know if that > works. > > In the meantime, I can at least work around that pass-by-value build > issue. That function is pass-by-value because we intentionally want to > make a local copy of the camera object to modify. However, I can > explicitly make that copy inside the function instead. I?ve done this on > the release branch of MAP-Tk and made a pull request ( > https://github.com/Kitware/maptk/pull/88). Can you try to build this > branch and verify that it at least builds for you? > > git fetch origin pull/88/head:dev/camera-pass-by-reference > git checkout dev/camera-pass-by-reference > > If that works, I?ll merge this change into the release and master > branches. Also let me know if the solution on the Eigen page helps. > > ?Matt > > > On Oct 5, 2015, at 1:24 PM, Michael Rosen wrote: > > Hello Kwiver-folk, > > I'm building MapTK on Windows 7/64 using VStudio 12 and having two > immediate difficulties: a compilation problem and a runtime assert. > > MapTK is version 0.6.0, Eigen is 3.2.6 > > I've worked through getting Boost and Eigen built. When I compile maptk, > the first problem is this: > > [ 98%] Building CXX object > tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj > > pos2krtd.cxx > > C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': > formal parameter with __declspec(align('16')) won't > > be aligned > > C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': > formal parameter with __declspec(align('16')) won't > > ? > > > I fixed these compilation errors by changing the signature of the > offending function from pass-by-value to pass-by-reference: > > > /// Convert a POS file to a KRTD file > > bool convert_pos2krtd(const maptk::path_t& pos_filename, > > const maptk::path_t& krtd_filename, > > maptk::local_geo_cs& cs, > > maptk::camera_d& base_camera, // msr. was > pass-by-value > > maptk::rotation_d const& ins_rot_offset = > maptk::rotation_d()) > > > > That allows everything to compile and link. The next problem was that I > got an Eigen Assert when I run any of the executables: > > > C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe > > ... > > Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this > assertion is explained here: " "http://eigen.tuxfamily.org/d > > ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE > !!! ****", file c:\program files (x86)\eigen\include\eigen > > 3\eigen\src/Core/DenseStorage.h, line 86 > > > The web page says that classes which contain certain Eigen data structures > as members need to use the > > EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator > so that those members will be 16-byte aligned. I've done that but am still > seeing the assert. > > > Can anyone offer insight into any of this? > > > msr > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Tue Oct 6 17:01:46 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Tue, 6 Oct 2015 17:01:46 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> Message-ID: <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> > On Oct 6, 2015, at 3:38 PM, Michael Rosen wrote: > > Thanks for this. It compiles and the assert is gone. > > To be clear, here's what I did: > git clone https://github.com/Kitware/maptk.git > cd .\maptk > git fetch origin pull/88/head:dev/camera-pass-by-reference > git checkout dev/camera-pass-by-reference > cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" > nmake > nmake install Interesting, so you didn?t need to do any of the defines to disable byte alignment for Eigen? Were you building master or release before? By the way, I have now merged that dev/camera-pass-by-reference branch into both the release and master branches of MAP-Tk, so you should be able to use one of the primary branches again. > > Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? I?ve been meaning to write up a tutorial on this, but haven?t gotten to it yet. Part of this is because there are big API changes coming soon as well as improvements in algorithms. There is a bunch of stuff building up that I can?t release yet until I get approval from AFRL. A preview of those changes is on the kwiver-integration branch. We are pulling a lot of core guts of MAP-Tk out into a new repository named VITAL (https://github.com/kitware/vital ) that is shared across KWIVER projects. I don?t recommend building that on Windows just yet. But Keith Fieldhouse is working on a KWIVER ?super build? that will use CMake to make the various projects build together easily. Anyway, the best I can do at this point is to point you to a tutorial I gave back in June at the CVPR conference: http://www.kitware.com/cvpr2015-tutorial.html This used a version of MAP-Tk similar to the current release branch. There are examples for applying MAP-Tk to a sample dataset. A Linux VM image is provided with all the software and data pre-installed, but you can also get the config files here: https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk and the sample data here: https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 and slides explaining what to do here: http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it might not work well out of the box on arbitrary images. Good Luck, Matt > > msr > > On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: > Michael, > > Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. > > In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: > > http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html > > I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. > > In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? > > git fetch origin pull/88/head:dev/camera-pass-by-reference > git checkout dev/camera-pass-by-reference > > If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. > > ?Matt > > >> On Oct 5, 2015, at 1:24 PM, Michael Rosen > wrote: >> >> Hello Kwiver-folk, >> >> I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. >> >> MapTK is version 0.6.0, Eigen is 3.2.6 >> >> I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: >> >> [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >> >> pos2krtd.cxx >> >> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >> >> be aligned >> >> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >> >> ? >> >> >> I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: >> >> >> /// Convert a POS file to a KRTD file >> >> bool convert_pos2krtd(const maptk::path_t& pos_filename, >> >> const maptk::path_t& krtd_filename, >> >> maptk::local_geo_cs& cs, >> >> maptk::camera_d& base_camera, // msr. was pass-by-value >> >> maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) >> >> >> >> That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: >> >> >> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >> >> ... >> >> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d >> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >> >> 3\eigen\src/Core/DenseStorage.h, line 86 >> >> >> The web page says that classes which contain certain Eigen data structures as members need to use the >> >> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. >> >> >> >> Can anyone offer insight into any of this? >> >> >> >> msr >> >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Tue Oct 6 17:47:25 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Tue, 6 Oct 2015 14:47:25 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> Message-ID: Thanks very much. This looks really helpful. I'll give it a spin and let you know how it goes. msr On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta wrote: > > On Oct 6, 2015, at 3:38 PM, Michael Rosen wrote: > > Thanks for this. It compiles and the assert is gone. > > To be clear, here's what I did: > > git clone https://github.com/Kitware/maptk.git > cd .\maptk > git fetch origin pull/88/head:dev/camera-pass-by-reference > git checkout dev/camera-pass-by-reference > cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install > -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" > nmake > nmake install > > > > Interesting, so you didn?t need to do any of the defines to disable byte > alignment for Eigen? Were you building master or release before? > > By the way, I have now merged that dev/camera-pass-by-reference branch > into both the release and master branches of MAP-Tk, so you should be able > to use one of the primary branches again. > > > > Is there a simple workflow you can pass that will demonstrate use of some > of the utilities. For example, suppose I have a collection of overlapping > images, what can I do with them? > > > I?ve been meaning to write up a tutorial on this, but haven?t gotten to it > yet. Part of this is because there are big API changes coming soon as well > as improvements in algorithms. There is a bunch of stuff building up that > I can?t release yet until I get approval from AFRL. A preview of those > changes is on the kwiver-integration branch. We are pulling a lot of core > guts of MAP-Tk out into a new repository named VITAL ( > https://github.com/kitware/vital) that is shared across KWIVER projects. > I don?t recommend building that on Windows just yet. But Keith Fieldhouse > is working on a KWIVER ?super build? that will use CMake to make the > various projects build together easily. > > Anyway, the best I can do at this point is to point you to a tutorial I > gave back in June at the CVPR conference: > > http://www.kitware.com/cvpr2015-tutorial.html > > This used a version of MAP-Tk similar to the current release branch. > There are examples for applying MAP-Tk to a sample dataset. A Linux VM > image is provided with all the software and data pre-installed, but you can > also get the config files here: > > https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk > > and the sample data here: > > https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 > > and slides explaining what to do here: > > > http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf > > FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it > might not work well out of the box on arbitrary images. > > Good Luck, > Matt > > > > > msr > > On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: > >> Michael, >> >> Thank you for reporting this issue. I?ll be upfront and warn you that >> I?m not a Windows developer and MAP-Tk is currently better tested on Linux >> and Mac. That said, we are working toward getting things better running on >> Windows more reliably. >> >> In this case, the issues are related to Eigen byte-alignment issues as >> explained on the Eigen website linked from your error message: >> >> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >> >> I have read this page before, and expected I would need to make changes >> at some point to work around these issues, but until now I had not come >> across a compiler that exhibited these symptoms. We should probably try to >> get a VisualStudio 2012 build up on our dashboard so I can work through >> those issues properly. I expect that will take some time. A shorter term >> solution is to try to disable alignment in your build. Can you try the >> solutions described at the bottom of the page at the above URL? In the "I >> don't care about vectorization, how do I get rid of that stuff?? section it >> suggests defining some macros to disable alignment. Let me know if that >> works. >> >> In the meantime, I can at least work around that pass-by-value build >> issue. That function is pass-by-value because we intentionally want to >> make a local copy of the camera object to modify. However, I can >> explicitly make that copy inside the function instead. I?ve done this on >> the release branch of MAP-Tk and made a pull request ( >> https://github.com/Kitware/maptk/pull/88). Can you try to build this >> branch and verify that it at least builds for you? >> >> git fetch origin pull/88/head:dev/camera-pass-by-reference >> git checkout dev/camera-pass-by-reference >> >> If that works, I?ll merge this change into the release and master >> branches. Also let me know if the solution on the Eigen page helps. >> >> ?Matt >> >> >> On Oct 5, 2015, at 1:24 PM, Michael Rosen >> wrote: >> >> Hello Kwiver-folk, >> >> I'm building MapTK on Windows 7/64 using VStudio 12 and having two >> immediate difficulties: a compilation problem and a runtime assert. >> >> MapTK is version 0.6.0, Eigen is 3.2.6 >> >> I've worked through getting Boost and Eigen built. When I compile maptk, >> the first problem is this: >> >> [ 98%] Building CXX object >> tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >> >> pos2krtd.cxx >> >> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': >> formal parameter with __declspec(align('16')) won't >> >> be aligned >> >> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': >> formal parameter with __declspec(align('16')) won't >> >> ? >> >> >> I fixed these compilation errors by changing the signature of the >> offending function from pass-by-value to pass-by-reference: >> >> >> /// Convert a POS file to a KRTD file >> >> bool convert_pos2krtd(const maptk::path_t& pos_filename, >> >> const maptk::path_t& krtd_filename, >> >> maptk::local_geo_cs& cs, >> >> maptk::camera_d& base_camera, // msr. was >> pass-by-value >> >> maptk::rotation_d const& ins_rot_offset = >> maptk::rotation_d()) >> >> >> >> That allows everything to compile and link. The next problem was that I >> got an Eigen Assert when I run any of the executables: >> >> >> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >> >> ... >> >> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this >> assertion is explained here: " "http://eigen.tuxfamily.org/d >> >> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE >> !!! ****", file c:\program files (x86)\eigen\include\eigen >> >> 3\eigen\src/Core/DenseStorage.h, line 86 >> >> >> The web page says that classes which contain certain Eigen data >> structures as members need to use the >> >> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator >> so that those members will be 16-byte aligned. I've done that but am still >> seeing the assert. >> >> >> Can anyone offer insight into any of this? >> >> >> msr >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Wed Oct 14 09:13:41 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Wed, 14 Oct 2015 06:13:41 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> Message-ID: Presentation and test data look great. Sadly, it's not working for me on Windows. maptk_track_features posts an AV. Can you provide some insight into what's wrong? Attempting to follow along with the example, I ran this: C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe -c clif_track.conf I think the debug spew below looks ok: [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically loading plugin impls [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] Loading plugins in search paths [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] Loading modules in directory: "C:/dev/maptk/lib/maptk" [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib /maptk\maptk_core_plugin.dll" [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EE0000 [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis ter_algo_impls [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EE1163 [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_core' [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:bad_frames_only' for def type 'close_loops' [DEBUG][maptk::registrar] Registering algo implementation 'bad_frames_only' for def type 'close_loops' [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:multi_method' for def type 'close_loops' [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' for def type 'close_loops' [DEBUG][maptk::registrar] Registering algo implementation 'compute_ref_homography:core' for def type 'compute_ref_homography' [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'compute_ref_homography' [DEBUG][maptk::registrar] Registering algo implementation 'convert_image:bypass' for def type 'convert_image' [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def type 'convert_image' [DEBUG][maptk::registrar] Registering algo implementation 'filter_features:magnitude' for def type 'filter_features' [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for def type 'filter_features' [DEBUG][maptk::registrar] Registering algo implementation 'bundle_adjust:hierarchical' for def type 'bundle_adjust' [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' for def type 'bundle_adjust' [DEBUG][maptk::registrar] Registering algo implementation 'match_features:homography_guided' for def type 'match_features' [DEBUG][maptk::registrar] Registering algo implementation 'homography_guided' for def type 'match_features' [DEBUG][maptk::registrar] Registering algo implementation 'track_features:core' for def type 'track_features' [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'track_features' [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] Registered 8 of 8 algorithms (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> Successfully called registration func [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib /maptk\maptk_ocv_plugin.dll" [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EA0000 [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis ter_algo_impls [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EA1163 [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_ocv' [DEBUG][maptk::registrar] Registering algo implementation 'analyze_tracks:ocv' for def type 'analyze_tracks' [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def type 'analyze_tracks' But then right after that, I get an Access Violation with this call stack. What's happening? msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ maptk_track_features.exe!__tmainCRTStartup() Line 626 C maptk_track_features.exe!mainCRTStartup() Line 466 C The offending code seems to be this: /// create the default feature detector static cv::Ptr default_detector() { cv::Ptr det; // try the SURF detector first det = cv::FeatureDetector::create("SURF"); //////// Access Violation here. if( !det ) { // if SURF is not available (nonfree not built) use ORB det = cv::FeatureDetector::create("ORB"); } return det; } On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen wrote: > Thanks very much. This looks really helpful. I'll give it a spin and let > you know how it goes. > > msr > > On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta > wrote: > >> >> On Oct 6, 2015, at 3:38 PM, Michael Rosen >> wrote: >> >> Thanks for this. It compiles and the assert is gone. >> >> To be clear, here's what I did: >> >> git clone https://github.com/Kitware/maptk.git >> cd .\maptk >> git fetch origin pull/88/head:dev/camera-pass-by-reference >> git checkout dev/camera-pass-by-reference >> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install >> -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >> nmake >> nmake install >> >> >> >> Interesting, so you didn?t need to do any of the defines to disable byte >> alignment for Eigen? Were you building master or release before? >> >> By the way, I have now merged that dev/camera-pass-by-reference branch >> into both the release and master branches of MAP-Tk, so you should be able >> to use one of the primary branches again. >> >> >> >> Is there a simple workflow you can pass that will demonstrate use of some >> of the utilities. For example, suppose I have a collection of overlapping >> images, what can I do with them? >> >> >> I?ve been meaning to write up a tutorial on this, but haven?t gotten to >> it yet. Part of this is because there are big API changes coming soon as >> well as improvements in algorithms. There is a bunch of stuff building up >> that I can?t release yet until I get approval from AFRL. A preview of >> those changes is on the kwiver-integration branch. We are pulling a lot of >> core guts of MAP-Tk out into a new repository named VITAL ( >> https://github.com/kitware/vital) that is shared across KWIVER >> projects. I don?t recommend building that on Windows just yet. But Keith >> Fieldhouse is working on a KWIVER ?super build? that will use CMake to make >> the various projects build together easily. >> >> Anyway, the best I can do at this point is to point you to a tutorial I >> gave back in June at the CVPR conference: >> >> http://www.kitware.com/cvpr2015-tutorial.html >> >> This used a version of MAP-Tk similar to the current release branch. >> There are examples for applying MAP-Tk to a sample dataset. A Linux VM >> image is provided with all the software and data pre-installed, but you can >> also get the config files here: >> >> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >> >> and the sample data here: >> >> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >> >> and slides explaining what to do here: >> >> >> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >> >> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so >> it might not work well out of the box on arbitrary images. >> >> Good Luck, >> Matt >> >> >> >> >> msr >> >> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta >> wrote: >> >>> Michael, >>> >>> Thank you for reporting this issue. I?ll be upfront and warn you that >>> I?m not a Windows developer and MAP-Tk is currently better tested on Linux >>> and Mac. That said, we are working toward getting things better running on >>> Windows more reliably. >>> >>> In this case, the issues are related to Eigen byte-alignment issues as >>> explained on the Eigen website linked from your error message: >>> >>> >>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>> >>> I have read this page before, and expected I would need to make changes >>> at some point to work around these issues, but until now I had not come >>> across a compiler that exhibited these symptoms. We should probably try to >>> get a VisualStudio 2012 build up on our dashboard so I can work through >>> those issues properly. I expect that will take some time. A shorter term >>> solution is to try to disable alignment in your build. Can you try the >>> solutions described at the bottom of the page at the above URL? In the "I >>> don't care about vectorization, how do I get rid of that stuff?? section it >>> suggests defining some macros to disable alignment. Let me know if that >>> works. >>> >>> In the meantime, I can at least work around that pass-by-value build >>> issue. That function is pass-by-value because we intentionally want to >>> make a local copy of the camera object to modify. However, I can >>> explicitly make that copy inside the function instead. I?ve done this on >>> the release branch of MAP-Tk and made a pull request ( >>> https://github.com/Kitware/maptk/pull/88). Can you try to build this >>> branch and verify that it at least builds for you? >>> >>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>> git checkout dev/camera-pass-by-reference >>> >>> If that works, I?ll merge this change into the release and master >>> branches. Also let me know if the solution on the Eigen page helps. >>> >>> ?Matt >>> >>> >>> On Oct 5, 2015, at 1:24 PM, Michael Rosen >>> wrote: >>> >>> Hello Kwiver-folk, >>> >>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two >>> immediate difficulties: a compilation problem and a runtime assert. >>> >>> MapTK is version 0.6.0, Eigen is 3.2.6 >>> >>> I've worked through getting Boost and Eigen built. When I compile >>> maptk, the first problem is this: >>> >>> [ 98%] Building CXX object >>> tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>> >>> pos2krtd.cxx >>> >>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': >>> formal parameter with __declspec(align('16')) won't >>> >>> be aligned >>> >>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': >>> formal parameter with __declspec(align('16')) won't >>> >>> ? >>> >>> >>> I fixed these compilation errors by changing the signature of the >>> offending function from pass-by-value to pass-by-reference: >>> >>> >>> /// Convert a POS file to a KRTD file >>> >>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>> >>> const maptk::path_t& krtd_filename, >>> >>> maptk::local_geo_cs& cs, >>> >>> maptk::camera_d& base_camera, // msr. was >>> pass-by-value >>> >>> maptk::rotation_d const& ins_rot_offset = >>> maptk::rotation_d()) >>> >>> >>> >>> That allows everything to compile and link. The next problem was that I >>> got an Eigen Assert when I run any of the executables: >>> >>> >>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>> >>> ... >>> >>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this >>> assertion is explained here: " "http://eigen.tuxfamily.org/d >>> >>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB >>> PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>> >>> 3\eigen\src/Core/DenseStorage.h, line 86 >>> >>> >>> The web page says that classes which contain certain Eigen data >>> structures as members need to use the >>> >>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" >>> operator so that those members will be 16-byte aligned. I've done that but >>> am still seeing the assert. >>> >>> >>> Can anyone offer insight into any of this? >>> >>> >>> msr >>> >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Oct 14 09:42:01 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 14 Oct 2015 09:42:01 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> Message-ID: <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Michael, This is likely related persistent issues with OpenCV?s algorithm factory code on Windows. For whatever reason, the OpenCV team could never seem to work the kinks out of this on Windows, but it works fine on other platforms. I was really hoping they were going to fix it once and for all in OpenCV 3.0, but instead they decided it was too much hassle and they just removed algorithm factories altogether. So OpenCV no longer supports creating algorithms at run-time from string names. This makes me sad, because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be created and configured on the fly using the MAP-Tk configuration file. If we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set of algorithm choices and configuration parameters. The problem seems to mostly manifest itself when you use nested OpenCV algorithm on Windows. In this case, the example config file contains: ----------------------- feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended = false feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold = 100 feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers = 3 feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves = 4 feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright = true # The OpenCV cv::Algorithm type to use for 'detector'. feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 # The OpenCV cv::Algorithm type to use for 'detector'. feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid ----------------------- This might run if you remove the OpenCV grid adaptive detector layer like this: ----------------------- feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended = false feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold = 100 feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers = 3 feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves = 4 feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright = true # The OpenCV cv::Algorithm type to use for 'detector'. feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF ----------------------- I would expect this to run (hopefully), but it is likely that it may not produce ideal results. ?Matt > On Oct 14, 2015, at 9:13 AM, Michael Rosen wrote: > > Presentation and test data look great. Sadly, it's not working for me on Windows. maptk_track_features posts an AV. Can you provide some insight into what's wrong? > > Attempting to follow along with the example, I ran this: > > C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe -c clif_track.conf > > I think the debug spew below looks ok: > > [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically loading plugin impls > [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] Loading plugins in search paths > [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] Loading modules in directory: "C:/dev/maptk/lib/maptk" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib > /maptk\maptk_core_plugin.dll" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EE0000 > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis > ter_algo_impls > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EE1163 > [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_core' > [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:bad_frames_only' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation 'bad_frames_only' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:multi_method' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation 'compute_ref_homography:core' for def type 'compute_ref_homography' > [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'compute_ref_homography' > [DEBUG][maptk::registrar] Registering algo implementation 'convert_image:bypass' for def type 'convert_image' > [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def type 'convert_image' > [DEBUG][maptk::registrar] Registering algo implementation 'filter_features:magnitude' for def type 'filter_features' > [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for def type 'filter_features' > [DEBUG][maptk::registrar] Registering algo implementation 'bundle_adjust:hierarchical' for def type 'bundle_adjust' > [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' for def type 'bundle_adjust' > [DEBUG][maptk::registrar] Registering algo implementation 'match_features:homography_guided' for def type 'match_features' > [DEBUG][maptk::registrar] Registering algo implementation 'homography_guided' for def type 'match_features' > [DEBUG][maptk::registrar] Registering algo implementation 'track_features:core' for def type 'track_features' > [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'track_features' > [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] Registered 8 of 8 algorithms > (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> Successfully called registration func > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib > /maptk\maptk_ocv_plugin.dll" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EA0000 > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis > ter_algo_impls > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EA1163 > [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_ocv' > [DEBUG][maptk::registrar] Registering algo implementation 'analyze_tracks:ocv' for def type 'analyze_tracks' > [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def type 'analyze_tracks' > > But then right after that, I get an Access Violation with this call stack. What's happening? > > msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown > > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ > opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ > maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ > maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ > maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ > maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ > maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ > maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ > maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ > maptk_track_features.exe!__tmainCRTStartup() Line 626 C > maptk_track_features.exe!mainCRTStartup() Line 466 C > > > The offending code seems to be this: > /// create the default feature detector > static cv::Ptr default_detector() > { > cv::Ptr det; > // try the SURF detector first > det = cv::FeatureDetector::create("SURF"); //////// Access Violation here. > if( !det ) > { > // if SURF is not available (nonfree not built) use ORB > det = cv::FeatureDetector::create("ORB"); > } > return det; > } > > On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen > wrote: > Thanks very much. This looks really helpful. I'll give it a spin and let you know how it goes. > > msr > > On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta > wrote: > >> On Oct 6, 2015, at 3:38 PM, Michael Rosen > wrote: >> >> Thanks for this. It compiles and the assert is gone. >> >> To be clear, here's what I did: >> git clone https://github.com/Kitware/maptk.git >> cd .\maptk >> git fetch origin pull/88/head:dev/camera-pass-by-reference >> git checkout dev/camera-pass-by-reference >> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >> nmake >> nmake install > > > Interesting, so you didn?t need to do any of the defines to disable byte alignment for Eigen? Were you building master or release before? > > By the way, I have now merged that dev/camera-pass-by-reference branch into both the release and master branches of MAP-Tk, so you should be able to use one of the primary branches again. > > >> >> Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? > > I?ve been meaning to write up a tutorial on this, but haven?t gotten to it yet. Part of this is because there are big API changes coming soon as well as improvements in algorithms. There is a bunch of stuff building up that I can?t release yet until I get approval from AFRL. A preview of those changes is on the kwiver-integration branch. We are pulling a lot of core guts of MAP-Tk out into a new repository named VITAL (https://github.com/kitware/vital ) that is shared across KWIVER projects. I don?t recommend building that on Windows just yet. But Keith Fieldhouse is working on a KWIVER ?super build? that will use CMake to make the various projects build together easily. > > Anyway, the best I can do at this point is to point you to a tutorial I gave back in June at the CVPR conference: > > http://www.kitware.com/cvpr2015-tutorial.html > > This used a version of MAP-Tk similar to the current release branch. There are examples for applying MAP-Tk to a sample dataset. A Linux VM image is provided with all the software and data pre-installed, but you can also get the config files here: > > https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk > > and the sample data here: > > https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 > > and slides explaining what to do here: > > http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf > > FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it might not work well out of the box on arbitrary images. > > Good Luck, > Matt > > > >> >> msr >> >> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: >> Michael, >> >> Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. >> >> In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: >> >> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >> >> I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. >> >> In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? >> >> git fetch origin pull/88/head:dev/camera-pass-by-reference >> git checkout dev/camera-pass-by-reference >> >> If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. >> >> ?Matt >> >> >>> On Oct 5, 2015, at 1:24 PM, Michael Rosen > wrote: >>> >>> Hello Kwiver-folk, >>> >>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. >>> >>> MapTK is version 0.6.0, Eigen is 3.2.6 >>> >>> I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: >>> >>> [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>> >>> pos2krtd.cxx >>> >>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>> >>> be aligned >>> >>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>> >>> ? >>> >>> >>> I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: >>> >>> >>> /// Convert a POS file to a KRTD file >>> >>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>> >>> const maptk::path_t& krtd_filename, >>> >>> maptk::local_geo_cs& cs, >>> >>> maptk::camera_d& base_camera, // msr. was pass-by-value >>> >>> maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) >>> >>> >>> >>> That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: >>> >>> >>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>> >>> ... >>> >>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>> >>> 3\eigen\src/Core/DenseStorage.h, line 86 >>> >>> >>> The web page says that classes which contain certain Eigen data structures as members need to use the >>> >>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. >>> >>> >>> >>> Can anyone offer insight into any of this? >>> >>> >>> >>> msr >>> >>> >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Wed Oct 14 09:58:04 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Wed, 14 Oct 2015 06:58:04 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: I commented out lines from clif_track.conf as follows but it failed as before: # The OpenCV cv::Algorithm type to use for 'detector'. feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 I had previously tried building Kwiver on Linux but it failed to build Boost. Can you recommend a way forward for me? Thanks. msr On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta wrote: > Michael, > > This is likely related persistent issues with OpenCV?s algorithm factory > code on Windows. For whatever reason, the OpenCV team could never seem to > work the kinks out of this on Windows, but it works fine on other > platforms. I was really hoping they were going to fix it once and for all > in OpenCV 3.0, but instead they decided it was too much hassle and they > just removed algorithm factories altogether. So OpenCV no longer supports > creating algorithms at run-time from string names. This makes me sad, > because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be > created and configured on the fly using the MAP-Tk configuration file. If > we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set > of algorithm choices and configuration parameters. > > The problem seems to mostly manifest itself when you use nested OpenCV > algorithm on Windows. In this case, the example config file contains: > > ----------------------- > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended > = false > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold > = 100 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers > = 3 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves > = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright > = true > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type > = Feature2D.SURF > > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols > = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows > = 6 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints > = 1000 > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid > ----------------------- > > This might run if you remove the OpenCV grid adaptive detector layer like > this: > > ----------------------- > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended > = false > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold > = 100 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers > = 3 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves > = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright > = true > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF > ----------------------- > > I would expect this to run (hopefully), but it is likely that it may not > produce ideal results. > > ?Matt > > > On Oct 14, 2015, at 9:13 AM, Michael Rosen > wrote: > > Presentation and test data look great. Sadly, it's not working for me on > Windows. maptk_track_features posts an AV. Can you provide some insight > into what's wrong? > > Attempting to follow along with the example, I ran this: > > > C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe > -c clif_track.conf > > I think the debug spew below looks ok: > > [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically > loading plugin impls > [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] > Loading plugins in search paths > [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] > Loading modules in directory: "C:/dev/maptk/lib/maptk" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Starting plug-in interfacing for module file: "C:/dev/maptk/lib > /maptk\maptk_core_plugin.dll" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Loaded module: 73EE0000 > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Looking for algorithm impl registration function: private_regis > ter_algo_impls > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> > returned function address: 73EE1163 > [DEBUG][maptk::Implementation Registration] Registering algorithm > implementations from module 'maptk_core' > [DEBUG][maptk::registrar] Registering algo implementation > 'close_loops:bad_frames_only' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation > 'bad_frames_only' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation > 'close_loops:multi_method' for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' > for def type 'close_loops' > [DEBUG][maptk::registrar] Registering algo implementation > 'compute_ref_homography:core' for def type 'compute_ref_homography' > [DEBUG][maptk::registrar] Registering algo implementation 'core' for def > type 'compute_ref_homography' > [DEBUG][maptk::registrar] Registering algo implementation > 'convert_image:bypass' for def type 'convert_image' > [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def > type 'convert_image' > [DEBUG][maptk::registrar] Registering algo implementation > 'filter_features:magnitude' for def type 'filter_features' > [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for > def type 'filter_features' > [DEBUG][maptk::registrar] Registering algo implementation > 'bundle_adjust:hierarchical' for def type 'bundle_adjust' > [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' > for def type 'bundle_adjust' > [DEBUG][maptk::registrar] Registering algo implementation > 'match_features:homography_guided' for def type 'match_features' > [DEBUG][maptk::registrar] Registering algo implementation > 'homography_guided' for def type 'match_features' > [DEBUG][maptk::registrar] Registering algo implementation > 'track_features:core' for def type 'track_features' > [DEBUG][maptk::registrar] Registering algo implementation 'core' for def > type 'track_features' > [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] > Registered 8 of 8 algorithms > (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> > Successfully called registration func > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Starting plug-in interfacing for module file: "C:/dev/maptk/lib > /maptk\maptk_ocv_plugin.dll" > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Loaded module: 73EA0000 > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] > Looking for algorithm impl registration function: private_regis > ter_algo_impls > [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> > returned function address: 73EA1163 > [DEBUG][maptk::Implementation Registration] Registering algorithm > implementations from module 'maptk_ocv' > [DEBUG][maptk::registrar] Registering algo implementation > 'analyze_tracks:ocv' for def type 'analyze_tracks' > [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def > type 'analyze_tracks' > > But then right after that, I get an Access Violation with this call > stack. What's happening? > > msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned > long cnt) Line 101 Unknown > > opencv_features2d249.dll!std::basic_string,std::allocator > >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 > C++ > opencv_features2d249.dll!cv::FeatureDetector::create(const > std::basic_string,std::allocator > & > detectorType) Line 93 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() > Line 76 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ > maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ > maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar > & reg) Line 370 C++ > maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) > Line 70 C++ > maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 > C++ > maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & > reg) Line 59 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path > module_path) Line 293 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path > dir_path, > std::basic_string,std::allocator > name) > Line 198 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > > name) Line 146 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > > name) Line 409 C++ > maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line > 236 C++ > maptk_track_features.exe!main(int argc, const char * * argv) Line 489 > C++ > maptk_track_features.exe!__tmainCRTStartup() Line 626 C > maptk_track_features.exe!mainCRTStartup() Line 466 C > > > The offending code seems to be this: > /// create the default feature detector > static cv::Ptr default_detector() > { > cv::Ptr det; > // try the SURF detector first > det = cv::FeatureDetector::create("SURF"); //////// Access Violation > here. > if( !det ) > { > // if SURF is not available (nonfree not built) use ORB > det = cv::FeatureDetector::create("ORB"); > } > return det; > } > > On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen > wrote: > >> Thanks very much. This looks really helpful. I'll give it a spin and >> let you know how it goes. >> >> msr >> >> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta >> wrote: >> >>> >>> On Oct 6, 2015, at 3:38 PM, Michael Rosen >>> wrote: >>> >>> Thanks for this. It compiles and the assert is gone. >>> >>> To be clear, here's what I did: >>> >>> git clone https://github.com/Kitware/maptk.git >>> cd .\maptk >>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>> git checkout dev/camera-pass-by-reference >>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install >>> -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>> nmake >>> nmake install >>> >>> >>> >>> Interesting, so you didn?t need to do any of the defines to disable byte >>> alignment for Eigen? Were you building master or release before? >>> >>> By the way, I have now merged that dev/camera-pass-by-reference branch >>> into both the release and master branches of MAP-Tk, so you should be able >>> to use one of the primary branches again. >>> >>> >>> >>> Is there a simple workflow you can pass that will demonstrate use of >>> some of the utilities. For example, suppose I have a collection of >>> overlapping images, what can I do with them? >>> >>> >>> I?ve been meaning to write up a tutorial on this, but haven?t gotten to >>> it yet. Part of this is because there are big API changes coming soon as >>> well as improvements in algorithms. There is a bunch of stuff building up >>> that I can?t release yet until I get approval from AFRL. A preview of >>> those changes is on the kwiver-integration branch. We are pulling a lot of >>> core guts of MAP-Tk out into a new repository named VITAL ( >>> https://github.com/kitware/vital) that is shared across KWIVER >>> projects. I don?t recommend building that on Windows just yet. But Keith >>> Fieldhouse is working on a KWIVER ?super build? that will use CMake to make >>> the various projects build together easily. >>> >>> Anyway, the best I can do at this point is to point you to a tutorial I >>> gave back in June at the CVPR conference: >>> >>> http://www.kitware.com/cvpr2015-tutorial.html >>> >>> This used a version of MAP-Tk similar to the current release branch. >>> There are examples for applying MAP-Tk to a sample dataset. A Linux VM >>> image is provided with all the software and data pre-installed, but you can >>> also get the config files here: >>> >>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >>> >>> and the sample data here: >>> >>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >>> >>> and slides explaining what to do here: >>> >>> >>> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >>> >>> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so >>> it might not work well out of the box on arbitrary images. >>> >>> Good Luck, >>> Matt >>> >>> >>> >>> >>> msr >>> >>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta >> > wrote: >>> >>>> Michael, >>>> >>>> Thank you for reporting this issue. I?ll be upfront and warn you that >>>> I?m not a Windows developer and MAP-Tk is currently better tested on Linux >>>> and Mac. That said, we are working toward getting things better running on >>>> Windows more reliably. >>>> >>>> In this case, the issues are related to Eigen byte-alignment issues as >>>> explained on the Eigen website linked from your error message: >>>> >>>> >>>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>>> >>>> I have read this page before, and expected I would need to make changes >>>> at some point to work around these issues, but until now I had not come >>>> across a compiler that exhibited these symptoms. We should probably try to >>>> get a VisualStudio 2012 build up on our dashboard so I can work through >>>> those issues properly. I expect that will take some time. A shorter term >>>> solution is to try to disable alignment in your build. Can you try the >>>> solutions described at the bottom of the page at the above URL? In the "I >>>> don't care about vectorization, how do I get rid of that stuff?? section it >>>> suggests defining some macros to disable alignment. Let me know if that >>>> works. >>>> >>>> In the meantime, I can at least work around that pass-by-value build >>>> issue. That function is pass-by-value because we intentionally want to >>>> make a local copy of the camera object to modify. However, I can >>>> explicitly make that copy inside the function instead. I?ve done this on >>>> the release branch of MAP-Tk and made a pull request ( >>>> https://github.com/Kitware/maptk/pull/88). Can you try to build this >>>> branch and verify that it at least builds for you? >>>> >>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>> git checkout dev/camera-pass-by-reference >>>> >>>> If that works, I?ll merge this change into the release and master >>>> branches. Also let me know if the solution on the Eigen page helps. >>>> >>>> ?Matt >>>> >>>> >>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen >>>> wrote: >>>> >>>> Hello Kwiver-folk, >>>> >>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two >>>> immediate difficulties: a compilation problem and a runtime assert. >>>> >>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>> >>>> I've worked through getting Boost and Eigen built. When I compile >>>> maptk, the first problem is this: >>>> >>>> [ 98%] Building CXX object >>>> tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>> >>>> pos2krtd.cxx >>>> >>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': >>>> formal parameter with __declspec(align('16')) won't >>>> >>>> be aligned >>>> >>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': >>>> formal parameter with __declspec(align('16')) won't >>>> >>>> ? >>>> >>>> >>>> I fixed these compilation errors by changing the signature of the >>>> offending function from pass-by-value to pass-by-reference: >>>> >>>> >>>> /// Convert a POS file to a KRTD file >>>> >>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>> >>>> const maptk::path_t& krtd_filename, >>>> >>>> maptk::local_geo_cs& cs, >>>> >>>> maptk::camera_d& base_camera, // msr. was >>>> pass-by-value >>>> >>>> maptk::rotation_d const& ins_rot_offset = >>>> maptk::rotation_d()) >>>> >>>> >>>> >>>> That allows everything to compile and link. The next problem was that >>>> I got an Eigen Assert when I run any of the executables: >>>> >>>> >>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>> >>>> ... >>>> >>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this >>>> assertion is explained here: " "http://eigen.tuxfamily.org/d >>>> >>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB >>>> PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>> >>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>> >>>> >>>> The web page says that classes which contain certain Eigen data >>>> structures as members need to use the >>>> >>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" >>>> operator so that those members will be 16-byte aligned. I've done that but >>>> am still seeing the assert. >>>> >>>> >>>> Can anyone offer insight into any of this? >>>> >>>> >>>> msr >>>> >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Oct 14 10:09:13 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 14 Oct 2015 10:09:13 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: It?s not just commenting out lines that is needed. You also have to modify the other lines to remove the Features2D.Grid wrapper around the Features2D.SURF. I?ve illustrated what needs to change in my previous e-mail. That said, if you can use Linux that?s a better solution. There are a few options for the Linux route: 1) Keith or someone else can provide guidance on using Kwiver to build boost and other dependencies. I think a lot of that has been cleaned up in the last couple of weeks. 2) You can use the pre-built VM that comes with the CVPR tutorial. That has MAP-Tk pre-built and ready to run. You can either download the VM image or use Vagrant to reproduce it yourself. 3) Depending on your Linux distro, you may be able to install system packages for boost and other dependencies. For example, the VM mentioned above does this using Ubuntu 14.04. If you happen to be using Ubuntu, you can look through the Vagrant setup scripts to see exactly how to install all dependencies and build MAP-Tk. ?Matt > On Oct 14, 2015, at 9:58 AM, Michael Rosen wrote: > > I commented out lines from clif_track.conf as follows but it failed as before: > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF > > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 > > I had previously tried building Kwiver on Linux but it failed to build Boost. Can you recommend a way forward for me? > > Thanks. > > msr > > On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta > wrote: > Michael, > > This is likely related persistent issues with OpenCV?s algorithm factory code on Windows. For whatever reason, the OpenCV team could never seem to work the kinks out of this on Windows, but it works fine on other platforms. I was really hoping they were going to fix it once and for all in OpenCV 3.0, but instead they decided it was too much hassle and they just removed algorithm factories altogether. So OpenCV no longer supports creating algorithms at run-time from string names. This makes me sad, because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be created and configured on the fly using the MAP-Tk configuration file. If we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set of algorithm choices and configuration parameters. > > The problem seems to mostly manifest itself when you use nested OpenCV algorithm on Windows. In this case, the example config file contains: > > ----------------------- > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended = false > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold = 100 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers = 3 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright = true > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF > > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid > ----------------------- > > This might run if you remove the OpenCV grid adaptive detector layer like this: > > ----------------------- > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended = false > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold = 100 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers = 3 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves = 4 > feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright = true > > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF > ----------------------- > > I would expect this to run (hopefully), but it is likely that it may not produce ideal results. > > ?Matt > > >> On Oct 14, 2015, at 9:13 AM, Michael Rosen > wrote: >> >> Presentation and test data look great. Sadly, it's not working for me on Windows. maptk_track_features posts an AV. Can you provide some insight into what's wrong? >> >> Attempting to follow along with the example, I ran this: >> >> C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe -c clif_track.conf >> >> I think the debug spew below looks ok: >> >> [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically loading plugin impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] Loading plugins in search paths >> [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] Loading modules in directory: "C:/dev/maptk/lib/maptk" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >> /maptk\maptk_core_plugin.dll" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EE0000 >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >> ter_algo_impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EE1163 >> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_core' >> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:bad_frames_only' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation 'bad_frames_only' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:multi_method' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation 'compute_ref_homography:core' for def type 'compute_ref_homography' >> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'compute_ref_homography' >> [DEBUG][maptk::registrar] Registering algo implementation 'convert_image:bypass' for def type 'convert_image' >> [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def type 'convert_image' >> [DEBUG][maptk::registrar] Registering algo implementation 'filter_features:magnitude' for def type 'filter_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for def type 'filter_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'bundle_adjust:hierarchical' for def type 'bundle_adjust' >> [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' for def type 'bundle_adjust' >> [DEBUG][maptk::registrar] Registering algo implementation 'match_features:homography_guided' for def type 'match_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'homography_guided' for def type 'match_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'track_features:core' for def type 'track_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'track_features' >> [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] Registered 8 of 8 algorithms >> (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> Successfully called registration func >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >> /maptk\maptk_ocv_plugin.dll" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EA0000 >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >> ter_algo_impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EA1163 >> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_ocv' >> [DEBUG][maptk::registrar] Registering algo implementation 'analyze_tracks:ocv' for def type 'analyze_tracks' >> [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def type 'analyze_tracks' >> >> But then right after that, I get an Access Violation with this call stack. What's happening? >> >> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown >> > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ >> opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ >> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ >> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ >> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ >> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ >> maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ >> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ >> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >> maptk_track_features.exe!mainCRTStartup() Line 466 C >> >> >> The offending code seems to be this: >> /// create the default feature detector >> static cv::Ptr default_detector() >> { >> cv::Ptr det; >> // try the SURF detector first >> det = cv::FeatureDetector::create("SURF"); //////// Access Violation here. >> if( !det ) >> { >> // if SURF is not available (nonfree not built) use ORB >> det = cv::FeatureDetector::create("ORB"); >> } >> return det; >> } >> >> On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen > wrote: >> Thanks very much. This looks really helpful. I'll give it a spin and let you know how it goes. >> >> msr >> >> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta > wrote: >> >>> On Oct 6, 2015, at 3:38 PM, Michael Rosen > wrote: >>> >>> Thanks for this. It compiles and the assert is gone. >>> >>> To be clear, here's what I did: >>> git clone https://github.com/Kitware/maptk.git >>> cd .\maptk >>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>> git checkout dev/camera-pass-by-reference >>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>> nmake >>> nmake install >> >> >> Interesting, so you didn?t need to do any of the defines to disable byte alignment for Eigen? Were you building master or release before? >> >> By the way, I have now merged that dev/camera-pass-by-reference branch into both the release and master branches of MAP-Tk, so you should be able to use one of the primary branches again. >> >> >>> >>> Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? >> >> I?ve been meaning to write up a tutorial on this, but haven?t gotten to it yet. Part of this is because there are big API changes coming soon as well as improvements in algorithms. There is a bunch of stuff building up that I can?t release yet until I get approval from AFRL. A preview of those changes is on the kwiver-integration branch. We are pulling a lot of core guts of MAP-Tk out into a new repository named VITAL (https://github.com/kitware/vital ) that is shared across KWIVER projects. I don?t recommend building that on Windows just yet. But Keith Fieldhouse is working on a KWIVER ?super build? that will use CMake to make the various projects build together easily. >> >> Anyway, the best I can do at this point is to point you to a tutorial I gave back in June at the CVPR conference: >> >> http://www.kitware.com/cvpr2015-tutorial.html >> >> This used a version of MAP-Tk similar to the current release branch. There are examples for applying MAP-Tk to a sample dataset. A Linux VM image is provided with all the software and data pre-installed, but you can also get the config files here: >> >> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >> >> and the sample data here: >> >> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >> >> and slides explaining what to do here: >> >> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >> >> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it might not work well out of the box on arbitrary images. >> >> Good Luck, >> Matt >> >> >> >>> >>> msr >>> >>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: >>> Michael, >>> >>> Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. >>> >>> In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: >>> >>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>> >>> I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. >>> >>> In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? >>> >>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>> git checkout dev/camera-pass-by-reference >>> >>> If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. >>> >>> ?Matt >>> >>> >>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen > wrote: >>>> >>>> Hello Kwiver-folk, >>>> >>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. >>>> >>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>> >>>> I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: >>>> >>>> [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>> >>>> pos2krtd.cxx >>>> >>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>> >>>> be aligned >>>> >>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>> >>>> ? >>>> >>>> >>>> I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: >>>> >>>> >>>> /// Convert a POS file to a KRTD file >>>> >>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>> >>>> const maptk::path_t& krtd_filename, >>>> >>>> maptk::local_geo_cs& cs, >>>> >>>> maptk::camera_d& base_camera, // msr. was pass-by-value >>>> >>>> maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) >>>> >>>> >>>> >>>> That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: >>>> >>>> >>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>> >>>> ... >>>> >>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>> >>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>> >>>> >>>> The web page says that classes which contain certain Eigen data structures as members need to use the >>>> >>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. >>>> >>>> >>>> >>>> Can anyone offer insight into any of this? >>>> >>>> >>>> >>>> msr >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Wed Oct 14 18:42:40 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Wed, 14 Oct 2015 15:42:40 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: Ah. I missed the change. Did that ... and it did help but then it does the same thing somewhere else: msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ > opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ maptk_track_features.exe!__tmainCRTStartup() Line 626 C maptk_track_features.exe!mainCRTStartup() Line 466 C Ptr FeatureDetector::create( const string& detectorType ) { if( detectorType.find("Grid") == 0 ) /// AV here. { return new GridAdaptedFeatureDetector(FeatureDetector::create( detectorType.substr(strlen("Grid")))); } Thanks very much for the Linux pointers. I'll try those. At some point, I'll need to speak to the prospects for making this work on Windows. Can you point me to a ticket for the "OpenCV?s algorithm factory code on Windows" issue you mentioned or otherwise comment on the prospects for a fix? msr On Wed, Oct 14, 2015 at 7:09 AM, Matthew Leotta wrote: > It?s not just commenting out lines that is needed. You also have to > modify the other lines to remove the Features2D.Grid wrapper around the > Features2D.SURF. I?ve illustrated what needs to change in my previous > e-mail. That said, if you can use Linux that?s a better solution. > > There are a few options for the Linux route: > > 1) Keith or someone else can provide guidance on using Kwiver to build > boost and other dependencies. I think a lot of that has been cleaned up in > the last couple of weeks. > > 2) You can use the pre-built VM that comes with the CVPR tutorial. That > has MAP-Tk pre-built and ready to run. You can either download the VM > image or use Vagrant to reproduce it yourself. > > 3) Depending on your Linux distro, you may be able to install system > packages for boost and other dependencies. For example, the VM mentioned > above does this using Ubuntu 14.04. If you happen to be using Ubuntu, you > can look through the Vagrant setup scripts to see exactly how to install > all dependencies and build MAP-Tk. > > ?Matt > > > > On Oct 14, 2015, at 9:58 AM, Michael Rosen > wrote: > > I commented out lines from clif_track.conf as follows but it failed as > before: > # The OpenCV cv::Algorithm type to use for 'detector'. > feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type > = Feature2D.SURF > > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols > = 4 > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows > = 6 > #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints > = 1000 > > I had previously tried building Kwiver on Linux but it failed to build > Boost. Can you recommend a way forward for me? > > Thanks. > > msr > > On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta > wrote: > >> Michael, >> >> This is likely related persistent issues with OpenCV?s algorithm factory >> code on Windows. For whatever reason, the OpenCV team could never seem to >> work the kinks out of this on Windows, but it works fine on other >> platforms. I was really hoping they were going to fix it once and for all >> in OpenCV 3.0, but instead they decided it was too much hassle and they >> just removed algorithm factories altogether. So OpenCV no longer supports >> creating algorithms at run-time from string names. This makes me sad, >> because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be >> created and configured on the fly using the MAP-Tk configuration file. If >> we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set >> of algorithm choices and configuration parameters. >> >> The problem seems to mostly manifest itself when you use nested OpenCV >> algorithm on Windows. In this case, the example config file contains: >> >> ----------------------- >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended >> = false >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold >> = 100 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers >> = 3 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves >> = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright >> = true >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type >> = Feature2D.SURF >> >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols >> = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows >> = 6 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints >> = 1000 >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid >> ----------------------- >> >> This might run if you remove the OpenCV grid adaptive detector layer like >> this: >> >> ----------------------- >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended >> = false >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold >> = 100 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers >> = 3 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves >> = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright >> = true >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF >> ----------------------- >> >> I would expect this to run (hopefully), but it is likely that it may not >> produce ideal results. >> >> ?Matt >> >> >> On Oct 14, 2015, at 9:13 AM, Michael Rosen >> wrote: >> >> Presentation and test data look great. Sadly, it's not working for me on >> Windows. maptk_track_features posts an AV. Can you provide some insight >> into what's wrong? >> >> Attempting to follow along with the example, I ran this: >> >> >> C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe >> -c clif_track.conf >> >> I think the debug spew below looks ok: >> >> [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically >> loading plugin impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] >> Loading plugins in search paths >> [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] >> Loading modules in directory: "C:/dev/maptk/lib/maptk" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Starting plug-in interfacing for module file: "C:/dev/maptk/lib >> /maptk\maptk_core_plugin.dll" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Loaded module: 73EE0000 >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Looking for algorithm impl registration function: private_regis >> ter_algo_impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >> returned function address: 73EE1163 >> [DEBUG][maptk::Implementation Registration] Registering algorithm >> implementations from module 'maptk_core' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'close_loops:bad_frames_only' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'bad_frames_only' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'close_loops:multi_method' for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' >> for def type 'close_loops' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'compute_ref_homography:core' for def type 'compute_ref_homography' >> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def >> type 'compute_ref_homography' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'convert_image:bypass' for def type 'convert_image' >> [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for >> def type 'convert_image' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'filter_features:magnitude' for def type 'filter_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for >> def type 'filter_features' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'bundle_adjust:hierarchical' for def type 'bundle_adjust' >> [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' >> for def type 'bundle_adjust' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'match_features:homography_guided' for def type 'match_features' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'homography_guided' for def type 'match_features' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'track_features:core' for def type 'track_features' >> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def >> type 'track_features' >> [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] >> Registered 8 of 8 algorithms >> (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >> Successfully called registration func >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Starting plug-in interfacing for module file: "C:/dev/maptk/lib >> /maptk\maptk_ocv_plugin.dll" >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Loaded module: 73EA0000 >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >> Looking for algorithm impl registration function: private_regis >> ter_algo_impls >> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >> returned function address: 73EA1163 >> [DEBUG][maptk::Implementation Registration] Registering algorithm >> implementations from module 'maptk_ocv' >> [DEBUG][maptk::registrar] Registering algo implementation >> 'analyze_tracks:ocv' for def type 'analyze_tracks' >> [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def >> type 'analyze_tracks' >> >> But then right after that, I get an Access Violation with this call >> stack. What's happening? >> >> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned >> long cnt) Line 101 Unknown >> > opencv_features2d249.dll!std::basic_string,std::allocator >> >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 >> C++ >> opencv_features2d249.dll!cv::FeatureDetector::create(const >> std::basic_string,std::allocator > & >> detectorType) Line 93 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() >> Line 76 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 >> C++ >> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar >> & reg) Line 370 C++ >> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) >> Line 70 C++ >> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line >> 44 C++ >> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & >> reg) Line 59 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path >> module_path) Line 293 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path >> dir_path, >> std::basic_string,std::allocator > name) >> Line 198 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator >> > name) Line 146 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator >> > name) Line 409 C++ >> maptk_track_features.exe!maptk_main(int argc, const char * * argv) >> Line 236 C++ >> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 >> C++ >> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >> maptk_track_features.exe!mainCRTStartup() Line 466 C >> >> >> The offending code seems to be this: >> /// create the default feature detector >> static cv::Ptr default_detector() >> { >> cv::Ptr det; >> // try the SURF detector first >> det = cv::FeatureDetector::create("SURF"); //////// Access Violation >> here. >> if( !det ) >> { >> // if SURF is not available (nonfree not built) use ORB >> det = cv::FeatureDetector::create("ORB"); >> } >> return det; >> } >> >> On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen >> wrote: >> >>> Thanks very much. This looks really helpful. I'll give it a spin and >>> let you know how it goes. >>> >>> msr >>> >>> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta >>> wrote: >>> >>>> >>>> On Oct 6, 2015, at 3:38 PM, Michael Rosen >>>> wrote: >>>> >>>> Thanks for this. It compiles and the assert is gone. >>>> >>>> To be clear, here's what I did: >>>> >>>> git clone https://github.com/Kitware/maptk.git >>>> cd .\maptk >>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>> git checkout dev/camera-pass-by-reference >>>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install >>>> -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>>> nmake >>>> nmake install >>>> >>>> >>>> >>>> Interesting, so you didn?t need to do any of the defines to disable >>>> byte alignment for Eigen? Were you building master or release before? >>>> >>>> By the way, I have now merged that dev/camera-pass-by-reference branch >>>> into both the release and master branches of MAP-Tk, so you should be able >>>> to use one of the primary branches again. >>>> >>>> >>>> >>>> Is there a simple workflow you can pass that will demonstrate use of >>>> some of the utilities. For example, suppose I have a collection of >>>> overlapping images, what can I do with them? >>>> >>>> >>>> I?ve been meaning to write up a tutorial on this, but haven?t gotten to >>>> it yet. Part of this is because there are big API changes coming soon as >>>> well as improvements in algorithms. There is a bunch of stuff building up >>>> that I can?t release yet until I get approval from AFRL. A preview of >>>> those changes is on the kwiver-integration branch. We are pulling a lot of >>>> core guts of MAP-Tk out into a new repository named VITAL ( >>>> https://github.com/kitware/vital) that is shared across KWIVER >>>> projects. I don?t recommend building that on Windows just yet. But Keith >>>> Fieldhouse is working on a KWIVER ?super build? that will use CMake to make >>>> the various projects build together easily. >>>> >>>> Anyway, the best I can do at this point is to point you to a tutorial I >>>> gave back in June at the CVPR conference: >>>> >>>> http://www.kitware.com/cvpr2015-tutorial.html >>>> >>>> This used a version of MAP-Tk similar to the current release branch. >>>> There are examples for applying MAP-Tk to a sample dataset. A Linux VM >>>> image is provided with all the software and data pre-installed, but you can >>>> also get the config files here: >>>> >>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >>>> >>>> and the sample data here: >>>> >>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >>>> >>>> and slides explaining what to do here: >>>> >>>> >>>> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >>>> >>>> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so >>>> it might not work well out of the box on arbitrary images. >>>> >>>> Good Luck, >>>> Matt >>>> >>>> >>>> >>>> >>>> msr >>>> >>>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta < >>>> matt.leotta at kitware.com> wrote: >>>> >>>>> Michael, >>>>> >>>>> Thank you for reporting this issue. I?ll be upfront and warn you that >>>>> I?m not a Windows developer and MAP-Tk is currently better tested on Linux >>>>> and Mac. That said, we are working toward getting things better running on >>>>> Windows more reliably. >>>>> >>>>> In this case, the issues are related to Eigen byte-alignment issues as >>>>> explained on the Eigen website linked from your error message: >>>>> >>>>> >>>>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>>>> >>>>> I have read this page before, and expected I would need to make >>>>> changes at some point to work around these issues, but until now I had not >>>>> come across a compiler that exhibited these symptoms. We should probably >>>>> try to get a VisualStudio 2012 build up on our dashboard so I can work >>>>> through those issues properly. I expect that will take some time. A >>>>> shorter term solution is to try to disable alignment in your build. Can >>>>> you try the solutions described at the bottom of the page at the above >>>>> URL? In the "I don't care about vectorization, how do I get rid of that >>>>> stuff?? section it suggests defining some macros to disable alignment. Let >>>>> me know if that works. >>>>> >>>>> In the meantime, I can at least work around that pass-by-value build >>>>> issue. That function is pass-by-value because we intentionally want to >>>>> make a local copy of the camera object to modify. However, I can >>>>> explicitly make that copy inside the function instead. I?ve done this on >>>>> the release branch of MAP-Tk and made a pull request ( >>>>> https://github.com/Kitware/maptk/pull/88). Can you try to build this >>>>> branch and verify that it at least builds for you? >>>>> >>>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>>> git checkout dev/camera-pass-by-reference >>>>> >>>>> If that works, I?ll merge this change into the release and master >>>>> branches. Also let me know if the solution on the Eigen page helps. >>>>> >>>>> ?Matt >>>>> >>>>> >>>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen >>>>> wrote: >>>>> >>>>> Hello Kwiver-folk, >>>>> >>>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two >>>>> immediate difficulties: a compilation problem and a runtime assert. >>>>> >>>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>>> >>>>> I've worked through getting Boost and Eigen built. When I compile >>>>> maptk, the first problem is this: >>>>> >>>>> [ 98%] Building CXX object >>>>> tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>>> >>>>> pos2krtd.cxx >>>>> >>>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': >>>>> formal parameter with __declspec(align('16')) won't >>>>> >>>>> be aligned >>>>> >>>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': >>>>> formal parameter with __declspec(align('16')) won't >>>>> >>>>> ? >>>>> >>>>> >>>>> I fixed these compilation errors by changing the signature of the >>>>> offending function from pass-by-value to pass-by-reference: >>>>> >>>>> >>>>> /// Convert a POS file to a KRTD file >>>>> >>>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>>> >>>>> const maptk::path_t& krtd_filename, >>>>> >>>>> maptk::local_geo_cs& cs, >>>>> >>>>> maptk::camera_d& base_camera, // msr. was >>>>> pass-by-value >>>>> >>>>> maptk::rotation_d const& ins_rot_offset = >>>>> maptk::rotation_d()) >>>>> >>>>> >>>>> >>>>> That allows everything to compile and link. The next problem was that >>>>> I got an Eigen Assert when I run any of the executables: >>>>> >>>>> >>>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>>> >>>>> ... >>>>> >>>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && >>>>> "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>>>> >>>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB >>>>> PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>>> >>>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>>> >>>>> >>>>> The web page says that classes which contain certain Eigen data >>>>> structures as members need to use the >>>>> >>>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" >>>>> operator so that those members will be 16-byte aligned. I've done that but >>>>> am still seeing the assert. >>>>> >>>>> >>>>> Can anyone offer insight into any of this? >>>>> >>>>> >>>>> msr >>>>> >>>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Oct 14 22:49:29 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 14 Oct 2015 22:49:29 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: Michael, Can you confirm that ?Grid? no longer appears anywhere in your config? I?m not sure how this code path would be reached if you are no longer configured to use the GridAdaptedFeatureDetector. The most relevant OpenCV ticket is this one: http://code.opencv.org/issues/2700 You can see the solution is ?ok, we removed this feature from 3.0?, so they no longer need to address the problem. Another related ticket is here: http://code.opencv.org/issues/4129 This one suggests that going forward (starting in OpenCV 3.0) one needs to explicitly call create functions on the class instance, instead of creating by name. This means that when we update MAP-Tk to use OpenCV 3.0 we will also need reproduce this lookup by name on the MAP-Tk side. Also, it seems that the GridAdaptiveFeatureDetector itself (and all the other adaptive feature detector modifiers) have gone missing in OpenCV 3.0 as noted here: http://answers.opencv.org/question/42490/gridadaptedfeaturedetector-missing-in-opencv-30/ I started a branch to upgrade to OpenCV 3.0, but got stuck with these issues. In summary, there doesn?t appear to be a simple fix here. I?d be happy to have someone volunteer to tackle this issue. ?Matt > On Oct 14, 2015, at 6:42 PM, Michael Rosen wrote: > > Ah. I missed the change. Did that ... and it did help but then it does the same thing somewhere else: > > msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ > > opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ > maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ > maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ > maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ > maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ > maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ > maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ > maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ > maptk_track_features.exe!__tmainCRTStartup() Line 626 C > maptk_track_features.exe!mainCRTStartup() Line 466 C > > Ptr FeatureDetector::create( const string& detectorType ) > { > if( detectorType.find("Grid") == 0 ) /// AV here. > { > return new GridAdaptedFeatureDetector(FeatureDetector::create( > detectorType.substr(strlen("Grid")))); > } > > > Thanks very much for the Linux pointers. I'll try those. > > At some point, I'll need to speak to the prospects for making this work on Windows. Can you point me to a ticket for the "OpenCV?s algorithm factory code on Windows" issue you mentioned or otherwise comment on the prospects for a fix? > > msr > > On Wed, Oct 14, 2015 at 7:09 AM, Matthew Leotta > wrote: > It?s not just commenting out lines that is needed. You also have to modify the other lines to remove the Features2D.Grid wrapper around the Features2D.SURF. I?ve illustrated what needs to change in my previous e-mail. That said, if you can use Linux that?s a better solution. > > There are a few options for the Linux route: > > 1) Keith or someone else can provide guidance on using Kwiver to build boost and other dependencies. I think a lot of that has been cleaned up in the last couple of weeks. > > 2) You can use the pre-built VM that comes with the CVPR tutorial. That has MAP-Tk pre-built and ready to run. You can either download the VM image or use Vagrant to reproduce it yourself. > > 3) Depending on your Linux distro, you may be able to install system packages for boost and other dependencies. For example, the VM mentioned above does this using Ubuntu 14.04. If you happen to be using Ubuntu, you can look through the Vagrant setup scripts to see exactly how to install all dependencies and build MAP-Tk. > > ?Matt > > > >> On Oct 14, 2015, at 9:58 AM, Michael Rosen > wrote: >> >> I commented out lines from clif_track.conf as follows but it failed as before: >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF >> >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 >> >> I had previously tried building Kwiver on Linux but it failed to build Boost. Can you recommend a way forward for me? >> >> Thanks. >> >> msr >> >> On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta > wrote: >> Michael, >> >> This is likely related persistent issues with OpenCV?s algorithm factory code on Windows. For whatever reason, the OpenCV team could never seem to work the kinks out of this on Windows, but it works fine on other platforms. I was really hoping they were going to fix it once and for all in OpenCV 3.0, but instead they decided it was too much hassle and they just removed algorithm factories altogether. So OpenCV no longer supports creating algorithms at run-time from string names. This makes me sad, because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be created and configured on the fly using the MAP-Tk configuration file. If we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set of algorithm choices and configuration parameters. >> >> The problem seems to mostly manifest itself when you use nested OpenCV algorithm on Windows. In this case, the example config file contains: >> >> ----------------------- >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended = false >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold = 100 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers = 3 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright = true >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF >> >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid >> ----------------------- >> >> This might run if you remove the OpenCV grid adaptive detector layer like this: >> >> ----------------------- >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended = false >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold = 100 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers = 3 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves = 4 >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright = true >> >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF >> ----------------------- >> >> I would expect this to run (hopefully), but it is likely that it may not produce ideal results. >> >> ?Matt >> >> >>> On Oct 14, 2015, at 9:13 AM, Michael Rosen > wrote: >>> >>> Presentation and test data look great. Sadly, it's not working for me on Windows. maptk_track_features posts an AV. Can you provide some insight into what's wrong? >>> >>> Attempting to follow along with the example, I ran this: >>> >>> C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe -c clif_track.conf >>> >>> I think the debug spew below looks ok: >>> >>> [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically loading plugin impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] Loading plugins in search paths >>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] Loading modules in directory: "C:/dev/maptk/lib/maptk" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>> /maptk\maptk_core_plugin.dll" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EE0000 >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >>> ter_algo_impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EE1163 >>> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_core' >>> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:bad_frames_only' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation 'bad_frames_only' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:multi_method' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation 'compute_ref_homography:core' for def type 'compute_ref_homography' >>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'compute_ref_homography' >>> [DEBUG][maptk::registrar] Registering algo implementation 'convert_image:bypass' for def type 'convert_image' >>> [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def type 'convert_image' >>> [DEBUG][maptk::registrar] Registering algo implementation 'filter_features:magnitude' for def type 'filter_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for def type 'filter_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'bundle_adjust:hierarchical' for def type 'bundle_adjust' >>> [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' for def type 'bundle_adjust' >>> [DEBUG][maptk::registrar] Registering algo implementation 'match_features:homography_guided' for def type 'match_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'homography_guided' for def type 'match_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'track_features:core' for def type 'track_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'track_features' >>> [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] Registered 8 of 8 algorithms >>> (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> Successfully called registration func >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>> /maptk\maptk_ocv_plugin.dll" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EA0000 >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >>> ter_algo_impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EA1163 >>> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_ocv' >>> [DEBUG][maptk::registrar] Registering algo implementation 'analyze_tracks:ocv' for def type 'analyze_tracks' >>> [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def type 'analyze_tracks' >>> >>> But then right after that, I get an Access Violation with this call stack. What's happening? >>> >>> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown >>> > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ >>> opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ >>> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ >>> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ >>> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ >>> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ >>> maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ >>> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ >>> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >>> maptk_track_features.exe!mainCRTStartup() Line 466 C >>> >>> >>> The offending code seems to be this: >>> /// create the default feature detector >>> static cv::Ptr default_detector() >>> { >>> cv::Ptr det; >>> // try the SURF detector first >>> det = cv::FeatureDetector::create("SURF"); //////// Access Violation here. >>> if( !det ) >>> { >>> // if SURF is not available (nonfree not built) use ORB >>> det = cv::FeatureDetector::create("ORB"); >>> } >>> return det; >>> } >>> >>> On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen > wrote: >>> Thanks very much. This looks really helpful. I'll give it a spin and let you know how it goes. >>> >>> msr >>> >>> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta > wrote: >>> >>>> On Oct 6, 2015, at 3:38 PM, Michael Rosen > wrote: >>>> >>>> Thanks for this. It compiles and the assert is gone. >>>> >>>> To be clear, here's what I did: >>>> git clone https://github.com/Kitware/maptk.git >>>> cd .\maptk >>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>> git checkout dev/camera-pass-by-reference >>>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>>> nmake >>>> nmake install >>> >>> >>> Interesting, so you didn?t need to do any of the defines to disable byte alignment for Eigen? Were you building master or release before? >>> >>> By the way, I have now merged that dev/camera-pass-by-reference branch into both the release and master branches of MAP-Tk, so you should be able to use one of the primary branches again. >>> >>> >>>> >>>> Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? >>> >>> I?ve been meaning to write up a tutorial on this, but haven?t gotten to it yet. Part of this is because there are big API changes coming soon as well as improvements in algorithms. There is a bunch of stuff building up that I can?t release yet until I get approval from AFRL. A preview of those changes is on the kwiver-integration branch. We are pulling a lot of core guts of MAP-Tk out into a new repository named VITAL (https://github.com/kitware/vital ) that is shared across KWIVER projects. I don?t recommend building that on Windows just yet. But Keith Fieldhouse is working on a KWIVER ?super build? that will use CMake to make the various projects build together easily. >>> >>> Anyway, the best I can do at this point is to point you to a tutorial I gave back in June at the CVPR conference: >>> >>> http://www.kitware.com/cvpr2015-tutorial.html >>> >>> This used a version of MAP-Tk similar to the current release branch. There are examples for applying MAP-Tk to a sample dataset. A Linux VM image is provided with all the software and data pre-installed, but you can also get the config files here: >>> >>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >>> >>> and the sample data here: >>> >>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >>> >>> and slides explaining what to do here: >>> >>> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >>> >>> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it might not work well out of the box on arbitrary images. >>> >>> Good Luck, >>> Matt >>> >>> >>> >>>> >>>> msr >>>> >>>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: >>>> Michael, >>>> >>>> Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. >>>> >>>> In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: >>>> >>>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>>> >>>> I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. >>>> >>>> In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? >>>> >>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>> git checkout dev/camera-pass-by-reference >>>> >>>> If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. >>>> >>>> ?Matt >>>> >>>> >>>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen > wrote: >>>>> >>>>> Hello Kwiver-folk, >>>>> >>>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. >>>>> >>>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>>> >>>>> I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: >>>>> >>>>> [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>>> >>>>> pos2krtd.cxx >>>>> >>>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>>> >>>>> be aligned >>>>> >>>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>>> >>>>> ? >>>>> >>>>> >>>>> I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: >>>>> >>>>> >>>>> /// Convert a POS file to a KRTD file >>>>> >>>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>>> >>>>> const maptk::path_t& krtd_filename, >>>>> >>>>> maptk::local_geo_cs& cs, >>>>> >>>>> maptk::camera_d& base_camera, // msr. was pass-by-value >>>>> >>>>> maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) >>>>> >>>>> >>>>> >>>>> That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: >>>>> >>>>> >>>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>>> >>>>> ... >>>>> >>>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>>> >>>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>>> >>>>> >>>>> The web page says that classes which contain certain Eigen data structures as members need to use the >>>>> >>>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. >>>>> >>>>> >>>>> >>>>> Can anyone offer insight into any of this? >>>>> >>>>> >>>>> >>>>> msr >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rosen at gmail.com Thu Oct 15 00:52:04 2015 From: michael.rosen at gmail.com (Michael Rosen) Date: Wed, 14 Oct 2015 21:52:04 -0700 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: Umm, yes, there's no "Grid" in the config (all commented out), but I misspoke about it failing somewhere else. It fails in the same place. Looks like the OCV plugin is asking CV for a "SURF" FeatureDetector, the implementation in CV is the "different" error I mentioned. Sorry for the confusion. Sounds like to get a Windows Port we need to either fix the obscure bug in CV2 or migrate MapTK to CV3. I downloaded the VM you mentioned and was able to walk through the tutorial ... thanks for taking the effort to do that. Is there a way to use the existing MapTK tools or SDK to create a rectified image from the overlapping collection? msr On Wed, Oct 14, 2015 at 7:49 PM, Matthew Leotta wrote: > Michael, > > Can you confirm that ?Grid? no longer appears anywhere in your config? > I?m not sure how this code path would be reached if you are no longer > configured to use the GridAdaptedFeatureDetector. > > The most relevant OpenCV ticket is this one: > > http://code.opencv.org/issues/2700 > > You can see the solution is ?ok, we removed this feature from 3.0?, so > they no longer need to address the problem. Another related ticket is here: > > http://code.opencv.org/issues/4129 > > This one suggests that going forward (starting in OpenCV 3.0) one needs to > explicitly call create functions on the class instance, instead of creating > by name. This means that when we update MAP-Tk to use OpenCV 3.0 we will > also need reproduce this lookup by name on the MAP-Tk side. > > Also, it seems that the GridAdaptiveFeatureDetector itself (and all the > other adaptive feature detector modifiers) have gone missing in OpenCV 3.0 > as noted here: > > > http://answers.opencv.org/question/42490/gridadaptedfeaturedetector-missing-in-opencv-30/ > > I started a branch to upgrade to OpenCV 3.0, but got stuck with these > issues. In summary, there doesn?t appear to be a simple fix here. I?d be > happy to have someone volunteer to tackle this issue. > > ?Matt > > > > On Oct 14, 2015, at 6:42 PM, Michael Rosen > wrote: > > Ah. I missed the change. Did that ... and it did help but then it does > the same thing somewhere else: > > msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned > long cnt) Line 101 Unknown > opencv_features2d249.dll!std::basic_string,std::allocator > >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 > C++ > > opencv_features2d249.dll!cv::FeatureDetector::create(const > std::basic_string,std::allocator > & > detectorType) Line 93 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() > Line 76 C++ > maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ > maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ > maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar > & reg) Line 370 C++ > maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) > Line 70 C++ > maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 > C++ > maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & > reg) Line 59 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path > module_path) Line 293 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path > dir_path, > std::basic_string,std::allocator > name) > Line 198 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > > name) Line 146 C++ > maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > > name) Line 409 C++ > maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line > 236 C++ > maptk_track_features.exe!main(int argc, const char * * argv) Line 489 > C++ > maptk_track_features.exe!__tmainCRTStartup() Line 626 C > maptk_track_features.exe!mainCRTStartup() Line 466 C > > Ptr FeatureDetector::create( const string& detectorType ) > { > if( detectorType.find("Grid") == 0 ) /// AV here. > { > return new GridAdaptedFeatureDetector(FeatureDetector::create( > detectorType.substr(strlen("Grid")))); > } > > > Thanks very much for the Linux pointers. I'll try those. > > At some point, I'll need to speak to the prospects for making this work on > Windows. Can you point me to a ticket for the "OpenCV?s algorithm > factory code on Windows" issue you mentioned or otherwise comment on the > prospects for a fix? > > msr > > On Wed, Oct 14, 2015 at 7:09 AM, Matthew Leotta > wrote: > >> It?s not just commenting out lines that is needed. You also have to >> modify the other lines to remove the Features2D.Grid wrapper around the >> Features2D.SURF. I?ve illustrated what needs to change in my previous >> e-mail. That said, if you can use Linux that?s a better solution. >> >> There are a few options for the Linux route: >> >> 1) Keith or someone else can provide guidance on using Kwiver to build >> boost and other dependencies. I think a lot of that has been cleaned up in >> the last couple of weeks. >> >> 2) You can use the pre-built VM that comes with the CVPR tutorial. That >> has MAP-Tk pre-built and ready to run. You can either download the VM >> image or use Vagrant to reproduce it yourself. >> >> 3) Depending on your Linux distro, you may be able to install system >> packages for boost and other dependencies. For example, the VM mentioned >> above does this using Ubuntu 14.04. If you happen to be using Ubuntu, you >> can look through the Vagrant setup scripts to see exactly how to install >> all dependencies and build MAP-Tk. >> >> ?Matt >> >> >> >> On Oct 14, 2015, at 9:58 AM, Michael Rosen >> wrote: >> >> I commented out lines from clif_track.conf as follows but it failed as >> before: >> # The OpenCV cv::Algorithm type to use for 'detector'. >> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type >> = Feature2D.SURF >> >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols >> = 4 >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows >> = 6 >> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints >> = 1000 >> >> I had previously tried building Kwiver on Linux but it failed to build >> Boost. Can you recommend a way forward for me? >> >> Thanks. >> >> msr >> >> On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta >> wrote: >> >>> Michael, >>> >>> This is likely related persistent issues with OpenCV?s algorithm factory >>> code on Windows. For whatever reason, the OpenCV team could never seem to >>> work the kinks out of this on Windows, but it works fine on other >>> platforms. I was really hoping they were going to fix it once and for all >>> in OpenCV 3.0, but instead they decided it was too much hassle and they >>> just removed algorithm factories altogether. So OpenCV no longer supports >>> creating algorithms at run-time from string names. This makes me sad, >>> because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be >>> created and configured on the fly using the MAP-Tk configuration file. If >>> we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set >>> of algorithm choices and configuration parameters. >>> >>> The problem seems to mostly manifest itself when you use nested OpenCV >>> algorithm on Windows. In this case, the example config file contains: >>> >>> ----------------------- >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended >>> = false >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold >>> = 100 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers >>> = 3 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves >>> = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright >>> = true >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type >>> = Feature2D.SURF >>> >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols >>> = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows >>> = 6 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints >>> = 1000 >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid >>> ----------------------- >>> >>> This might run if you remove the OpenCV grid adaptive detector layer >>> like this: >>> >>> ----------------------- >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended >>> = false >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold >>> = 100 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers >>> = 3 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves >>> = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright >>> = true >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF >>> ----------------------- >>> >>> I would expect this to run (hopefully), but it is likely that it may not >>> produce ideal results. >>> >>> ?Matt >>> >>> >>> On Oct 14, 2015, at 9:13 AM, Michael Rosen >>> wrote: >>> >>> Presentation and test data look great. Sadly, it's not working for me >>> on Windows. maptk_track_features posts an AV. Can you provide some >>> insight into what's wrong? >>> >>> Attempting to follow along with the example, I ran this: >>> >>> >>> C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe >>> -c clif_track.conf >>> >>> I think the debug spew below looks ok: >>> >>> [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically >>> loading plugin impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] >>> Loading plugins in search paths >>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] >>> Loading modules in directory: "C:/dev/maptk/lib/maptk" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>> /maptk\maptk_core_plugin.dll" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Loaded module: 73EE0000 >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Looking for algorithm impl registration function: private_regis >>> ter_algo_impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >>> returned function address: 73EE1163 >>> [DEBUG][maptk::Implementation Registration] Registering algorithm >>> implementations from module 'maptk_core' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'close_loops:bad_frames_only' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'bad_frames_only' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'close_loops:multi_method' for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' >>> for def type 'close_loops' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'compute_ref_homography:core' for def type 'compute_ref_homography' >>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def >>> type 'compute_ref_homography' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'convert_image:bypass' for def type 'convert_image' >>> [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for >>> def type 'convert_image' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'filter_features:magnitude' for def type 'filter_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' >>> for def type 'filter_features' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'bundle_adjust:hierarchical' for def type 'bundle_adjust' >>> [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' >>> for def type 'bundle_adjust' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'match_features:homography_guided' for def type 'match_features' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'homography_guided' for def type 'match_features' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'track_features:core' for def type 'track_features' >>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def >>> type 'track_features' >>> [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] >>> Registered 8 of 8 algorithms >>> (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >>> Successfully called registration func >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>> /maptk\maptk_ocv_plugin.dll" >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Loaded module: 73EA0000 >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] >>> Looking for algorithm impl registration function: private_regis >>> ter_algo_impls >>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> >>> returned function address: 73EA1163 >>> [DEBUG][maptk::Implementation Registration] Registering algorithm >>> implementations from module 'maptk_ocv' >>> [DEBUG][maptk::registrar] Registering algo implementation >>> 'analyze_tracks:ocv' for def type 'analyze_tracks' >>> [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def >>> type 'analyze_tracks' >>> >>> But then right after that, I get an Access Violation with this call >>> stack. What's happening? >>> >>> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned >>> long cnt) Line 101 Unknown >>> > opencv_features2d249.dll!std::basic_string,std::allocator >>> >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 >>> C++ >>> opencv_features2d249.dll!cv::FeatureDetector::create(const >>> std::basic_string,std::allocator > & >>> detectorType) Line 93 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() >>> Line 76 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >>> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 >>> C++ >>> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar >>> & reg) Line 370 C++ >>> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) >>> Line 70 C++ >>> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line >>> 44 C++ >>> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & >>> reg) Line 59 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path >>> module_path) Line 293 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path >>> dir_path, >>> std::basic_string,std::allocator > name) >>> Line 198 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator >>> > name) Line 146 C++ >>> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator >>> > name) Line 409 C++ >>> maptk_track_features.exe!maptk_main(int argc, const char * * argv) >>> Line 236 C++ >>> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 >>> C++ >>> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >>> maptk_track_features.exe!mainCRTStartup() Line 466 C >>> >>> >>> The offending code seems to be this: >>> /// create the default feature detector >>> static cv::Ptr default_detector() >>> { >>> cv::Ptr det; >>> // try the SURF detector first >>> det = cv::FeatureDetector::create("SURF"); //////// Access Violation >>> here. >>> if( !det ) >>> { >>> // if SURF is not available (nonfree not built) use ORB >>> det = cv::FeatureDetector::create("ORB"); >>> } >>> return det; >>> } >>> >>> On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen >>> wrote: >>> >>>> Thanks very much. This looks really helpful. I'll give it a spin and >>>> let you know how it goes. >>>> >>>> msr >>>> >>>> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta >>> > wrote: >>>> >>>>> >>>>> On Oct 6, 2015, at 3:38 PM, Michael Rosen >>>>> wrote: >>>>> >>>>> Thanks for this. It compiles and the assert is gone. >>>>> >>>>> To be clear, here's what I did: >>>>> >>>>> git clone https://github.com/Kitware/maptk.git >>>>> cd .\maptk >>>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>>> git checkout dev/camera-pass-by-reference >>>>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install >>>>> -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>>>> nmake >>>>> nmake install >>>>> >>>>> >>>>> >>>>> Interesting, so you didn?t need to do any of the defines to disable >>>>> byte alignment for Eigen? Were you building master or release before? >>>>> >>>>> By the way, I have now merged that dev/camera-pass-by-reference branch >>>>> into both the release and master branches of MAP-Tk, so you should be able >>>>> to use one of the primary branches again. >>>>> >>>>> >>>>> >>>>> Is there a simple workflow you can pass that will demonstrate use of >>>>> some of the utilities. For example, suppose I have a collection of >>>>> overlapping images, what can I do with them? >>>>> >>>>> >>>>> I?ve been meaning to write up a tutorial on this, but haven?t gotten >>>>> to it yet. Part of this is because there are big API changes coming soon >>>>> as well as improvements in algorithms. There is a bunch of stuff building >>>>> up that I can?t release yet until I get approval from AFRL. A preview of >>>>> those changes is on the kwiver-integration branch. We are pulling a lot of >>>>> core guts of MAP-Tk out into a new repository named VITAL ( >>>>> https://github.com/kitware/vital) that is shared across KWIVER >>>>> projects. I don?t recommend building that on Windows just yet. But Keith >>>>> Fieldhouse is working on a KWIVER ?super build? that will use CMake to make >>>>> the various projects build together easily. >>>>> >>>>> Anyway, the best I can do at this point is to point you to a tutorial >>>>> I gave back in June at the CVPR conference: >>>>> >>>>> http://www.kitware.com/cvpr2015-tutorial.html >>>>> >>>>> This used a version of MAP-Tk similar to the current release branch. >>>>> There are examples for applying MAP-Tk to a sample dataset. A Linux VM >>>>> image is provided with all the software and data pre-installed, but you can >>>>> also get the config files here: >>>>> >>>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >>>>> >>>>> and the sample data here: >>>>> >>>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >>>>> >>>>> and slides explaining what to do here: >>>>> >>>>> >>>>> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >>>>> >>>>> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, >>>>> so it might not work well out of the box on arbitrary images. >>>>> >>>>> Good Luck, >>>>> Matt >>>>> >>>>> >>>>> >>>>> >>>>> msr >>>>> >>>>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta < >>>>> matt.leotta at kitware.com> wrote: >>>>> >>>>>> Michael, >>>>>> >>>>>> Thank you for reporting this issue. I?ll be upfront and warn you >>>>>> that I?m not a Windows developer and MAP-Tk is currently better tested on >>>>>> Linux and Mac. That said, we are working toward getting things better >>>>>> running on Windows more reliably. >>>>>> >>>>>> In this case, the issues are related to Eigen byte-alignment issues >>>>>> as explained on the Eigen website linked from your error message: >>>>>> >>>>>> >>>>>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>>>>> >>>>>> I have read this page before, and expected I would need to make >>>>>> changes at some point to work around these issues, but until now I had not >>>>>> come across a compiler that exhibited these symptoms. We should probably >>>>>> try to get a VisualStudio 2012 build up on our dashboard so I can work >>>>>> through those issues properly. I expect that will take some time. A >>>>>> shorter term solution is to try to disable alignment in your build. Can >>>>>> you try the solutions described at the bottom of the page at the above >>>>>> URL? In the "I don't care about vectorization, how do I get rid of that >>>>>> stuff?? section it suggests defining some macros to disable alignment. Let >>>>>> me know if that works. >>>>>> >>>>>> In the meantime, I can at least work around that pass-by-value build >>>>>> issue. That function is pass-by-value because we intentionally want to >>>>>> make a local copy of the camera object to modify. However, I can >>>>>> explicitly make that copy inside the function instead. I?ve done this on >>>>>> the release branch of MAP-Tk and made a pull request ( >>>>>> https://github.com/Kitware/maptk/pull/88). Can you try to build >>>>>> this branch and verify that it at least builds for you? >>>>>> >>>>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>>>> git checkout dev/camera-pass-by-reference >>>>>> >>>>>> If that works, I?ll merge this change into the release and master >>>>>> branches. Also let me know if the solution on the Eigen page helps. >>>>>> >>>>>> ?Matt >>>>>> >>>>>> >>>>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen >>>>>> wrote: >>>>>> >>>>>> Hello Kwiver-folk, >>>>>> >>>>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two >>>>>> immediate difficulties: a compilation problem and a runtime assert. >>>>>> >>>>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>>>> >>>>>> I've worked through getting Boost and Eigen built. When I compile >>>>>> maptk, the first problem is this: >>>>>> >>>>>> [ 98%] Building CXX object >>>>>> tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>>>> >>>>>> pos2krtd.cxx >>>>>> >>>>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': >>>>>> formal parameter with __declspec(align('16')) won't >>>>>> >>>>>> be aligned >>>>>> >>>>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': >>>>>> formal parameter with __declspec(align('16')) won't >>>>>> >>>>>> ? >>>>>> >>>>>> >>>>>> I fixed these compilation errors by changing the signature of the >>>>>> offending function from pass-by-value to pass-by-reference: >>>>>> >>>>>> >>>>>> /// Convert a POS file to a KRTD file >>>>>> >>>>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>>>> >>>>>> const maptk::path_t& krtd_filename, >>>>>> >>>>>> maptk::local_geo_cs& cs, >>>>>> >>>>>> maptk::camera_d& base_camera, // msr. was >>>>>> pass-by-value >>>>>> >>>>>> maptk::rotation_d const& ins_rot_offset = >>>>>> maptk::rotation_d()) >>>>>> >>>>>> >>>>>> >>>>>> That allows everything to compile and link. The next problem was >>>>>> that I got an Eigen Assert when I run any of the executables: >>>>>> >>>>>> >>>>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>>>> >>>>>> ... >>>>>> >>>>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && >>>>>> "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>>>>> >>>>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB >>>>>> PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>>>> >>>>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>>>> >>>>>> >>>>>> The web page says that classes which contain certain Eigen data >>>>>> structures as members need to use the >>>>>> >>>>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" >>>>>> operator so that those members will be 16-byte aligned. I've done that but >>>>>> am still seeing the assert. >>>>>> >>>>>> >>>>>> Can anyone offer insight into any of this? >>>>>> >>>>>> >>>>>> msr >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-users mailing list >>>>>> Kwiver-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Thu Oct 15 09:10:28 2015 From: matt.leotta at kitware.com (Matthew Leotta) Date: Thu, 15 Oct 2015 09:10:28 -0400 Subject: [Kwiver-users] MapTK issues on Windows In-Reply-To: References: <44A5E918-93D5-457F-A9AC-94D8AB9F0BE8@kitware.com> <36409760-05D0-44BA-A5EE-B7F45822E7F6@kitware.com> <676BFECD-1E65-41BF-B6BE-F0F3A841CAAB@kitware.com> Message-ID: <6306A7B6-E4C4-4738-9F9D-9D6051CF2BF0@kitware.com> > On Oct 15, 2015, at 12:52 AM, Michael Rosen wrote: > > Umm, yes, there's no "Grid" in the config (all commented out), but I misspoke about it failing somewhere else. It fails in the same place. Looks like the OCV plugin is asking CV for a "SURF" FeatureDetector, the implementation in CV is the "different" error I mentioned. Sorry for the confusion. Thanks for the clarification. I?ve never run into that issue when not using Grid. One other possibility is that your OpenCV was built without the ?Non-Free? components turned on. SURF is part of ?non-free? because of patent issues. > > Sounds like to get a Windows Port we need to either fix the obscure bug in CV2 or migrate MapTK to CV3. Yes, but fixing the OpenCV 2.4.X bug and getting is accepted upstream is unlikely because the OpenCV team didn?t fix it for 2 years and then decided to remove the feature in 3.0. We could actually work around this issue in a way that would work with both OpenCV 2.4.X and 3.0, but it involves a bit of reworking our current code and hard coding a list of OpenCV algorithms that MAP-Tk knows about. It?s not as elegant as our current approach, but it might be the direction we need to take. > > I downloaded the VM you mentioned and was able to walk through the tutorial ... thanks for taking the effort to do that. > > Is there a way to use the existing MapTK tools or SDK to create a rectified image from the overlapping collection? Using only MAP-Tk code there is not currently code to warp all of the images to a common image plane and create a mosaic (I?m assuming that?s what you are asking about). However there is code in another KWIVER project that I?ve been using for this: https://github.com/Kitware/vibrant/blob/master/tools/warp_video.cxx It uses the homographies produced by the MAP-Tk feature tracking tool to warp all of the images. The ultimate plan is to move a version of this tool into MAP-Tk. In fact, I could probably write a very simple version of this tool as a Python script using OpenCV, I just haven?t gotten to it yet. ?Matt > > msr > > > > On Wed, Oct 14, 2015 at 7:49 PM, Matthew Leotta > wrote: > Michael, > > Can you confirm that ?Grid? no longer appears anywhere in your config? I?m not sure how this code path would be reached if you are no longer configured to use the GridAdaptedFeatureDetector. > > The most relevant OpenCV ticket is this one: > > http://code.opencv.org/issues/2700 > > You can see the solution is ?ok, we removed this feature from 3.0?, so they no longer need to address the problem. Another related ticket is here: > > http://code.opencv.org/issues/4129 > > This one suggests that going forward (starting in OpenCV 3.0) one needs to explicitly call create functions on the class instance, instead of creating by name. This means that when we update MAP-Tk to use OpenCV 3.0 we will also need reproduce this lookup by name on the MAP-Tk side. > > Also, it seems that the GridAdaptiveFeatureDetector itself (and all the other adaptive feature detector modifiers) have gone missing in OpenCV 3.0 as noted here: > > http://answers.opencv.org/question/42490/gridadaptedfeaturedetector-missing-in-opencv-30/ > > I started a branch to upgrade to OpenCV 3.0, but got stuck with these issues. In summary, there doesn?t appear to be a simple fix here. I?d be happy to have someone volunteer to tackle this issue. > > ?Matt > > > >> On Oct 14, 2015, at 6:42 PM, Michael Rosen > wrote: >> >> Ah. I missed the change. Did that ... and it did help but then it does the same thing somewhere else: >> >> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown >> opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ >> > opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ >> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ >> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ >> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ >> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ >> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ >> maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ >> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ >> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >> maptk_track_features.exe!mainCRTStartup() Line 466 C >> >> Ptr FeatureDetector::create( const string& detectorType ) >> { >> if( detectorType.find("Grid") == 0 ) /// AV here. >> { >> return new GridAdaptedFeatureDetector(FeatureDetector::create( >> detectorType.substr(strlen("Grid")))); >> } >> >> >> Thanks very much for the Linux pointers. I'll try those. >> >> At some point, I'll need to speak to the prospects for making this work on Windows. Can you point me to a ticket for the "OpenCV?s algorithm factory code on Windows" issue you mentioned or otherwise comment on the prospects for a fix? >> >> msr >> >> On Wed, Oct 14, 2015 at 7:09 AM, Matthew Leotta > wrote: >> It?s not just commenting out lines that is needed. You also have to modify the other lines to remove the Features2D.Grid wrapper around the Features2D.SURF. I?ve illustrated what needs to change in my previous e-mail. That said, if you can use Linux that?s a better solution. >> >> There are a few options for the Linux route: >> >> 1) Keith or someone else can provide guidance on using Kwiver to build boost and other dependencies. I think a lot of that has been cleaned up in the last couple of weeks. >> >> 2) You can use the pre-built VM that comes with the CVPR tutorial. That has MAP-Tk pre-built and ready to run. You can either download the VM image or use Vagrant to reproduce it yourself. >> >> 3) Depending on your Linux distro, you may be able to install system packages for boost and other dependencies. For example, the VM mentioned above does this using Ubuntu 14.04. If you happen to be using Ubuntu, you can look through the Vagrant setup scripts to see exactly how to install all dependencies and build MAP-Tk. >> >> ?Matt >> >> >> >>> On Oct 14, 2015, at 9:58 AM, Michael Rosen > wrote: >>> >>> I commented out lines from clif_track.conf as follows but it failed as before: >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF >>> >>> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 >>> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 >>> #feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 >>> >>> I had previously tried building Kwiver on Linux but it failed to build Boost. Can you recommend a way forward for me? >>> >>> Thanks. >>> >>> msr >>> >>> On Wed, Oct 14, 2015 at 6:42 AM, Matthew Leotta > wrote: >>> Michael, >>> >>> This is likely related persistent issues with OpenCV?s algorithm factory code on Windows. For whatever reason, the OpenCV team could never seem to work the kinks out of this on Windows, but it works fine on other platforms. I was really hoping they were going to fix it once and for all in OpenCV 3.0, but instead they decided it was too much hassle and they just removed algorithm factories altogether. So OpenCV no longer supports creating algorithms at run-time from string names. This makes me sad, because we had a nice system in MAP-Tk of allowing OpenCV algorithms to be created and configured on the fly using the MAP-Tk configuration file. If we upgrade MAP-Tk to use OpenCV 3.0 we will have to hard code a fixed set of algorithm choices and configuration parameters. >>> >>> The problem seems to mostly manifest itself when you use nested OpenCV algorithm on Windows. In this case, the example config file contains: >>> >>> ----------------------- >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:extended = false >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:hessianThreshold = 100 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaveLayers = 3 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:nOctaves = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:Feature2D.SURF:upright = true >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:detector:type = Feature2D.SURF >>> >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridCols = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:gridRows = 6 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.Grid:maxTotalKeypoints = 1000 >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.Grid >>> ----------------------- >>> >>> This might run if you remove the OpenCV grid adaptive detector layer like this: >>> >>> ----------------------- >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:extended = false >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:hessianThreshold = 100 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaveLayers = 3 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:nOctaves = 4 >>> feature_tracker:core:feature_detector:ocv:detector:Feature2D.SURF:upright = true >>> >>> # The OpenCV cv::Algorithm type to use for 'detector'. >>> feature_tracker:core:feature_detector:ocv:detector:type = Feature2D.SURF >>> ----------------------- >>> >>> I would expect this to run (hopefully), but it is likely that it may not produce ideal results. >>> >>> ?Matt >>> >>> >>>> On Oct 14, 2015, at 9:13 AM, Michael Rosen > wrote: >>>> >>>> Presentation and test data look great. Sadly, it's not working for me on Windows. maptk_track_features posts an AV. Can you provide some insight into what's wrong? >>>> >>>> Attempting to follow along with the example, I ran this: >>>> >>>> C:\dev\cvpr2015-opensfm-master\Exercises\maptk>C:\dev\maptk\bin\maptk_track_features.exe -c clif_track.conf >>>> >>>> I think the debug spew below looks ok: >>>> >>>> [DEBUG][maptk::algorithm_plugin_manager::register_plugins] Dynamically loading plugin impls >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_from_search_paths] Loading plugins in search paths >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::load_modules_in_directory] Loading modules in directory: "C:/dev/maptk/lib/maptk" >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>>> /maptk\maptk_core_plugin.dll" >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EE0000 >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >>>> ter_algo_impls >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EE1163 >>>> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_core' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:bad_frames_only' for def type 'close_loops' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'bad_frames_only' for def type 'close_loops' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'close_loops:multi_method' for def type 'close_loops' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'multi_method' for def type 'close_loops' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'compute_ref_homography:core' for def type 'compute_ref_homography' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'compute_ref_homography' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'convert_image:bypass' for def type 'convert_image' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'bypass' for def type 'convert_image' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'filter_features:magnitude' for def type 'filter_features' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'magnitude' for def type 'filter_features' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'bundle_adjust:hierarchical' for def type 'bundle_adjust' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'hierarchical' for def type 'bundle_adjust' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'match_features:homography_guided' for def type 'match_features' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'homography_guided' for def type 'match_features' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'track_features:core' for def type 'track_features' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'core' for def type 'track_features' >>>> [DEBUG][maptk::algorithm_plugin_interface_macros::REGISTRATION_SUMMARY] Registered 8 of 8 algorithms >>>> (@C:\dev\maptk\maptk\plugins\core\register_algorithms.cxx) >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> Successfully called registration func >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Starting plug-in interfacing for module file: "C:/dev/maptk/lib >>>> /maptk\maptk_ocv_plugin.dll" >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Loaded module: 73EA0000 >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] Looking for algorithm impl registration function: private_regis >>>> ter_algo_impls >>>> [DEBUG][maptk::algorithm_plugin_manager::impl::register_from_module] -> returned function address: 73EA1163 >>>> [DEBUG][maptk::Implementation Registration] Registering algorithm implementations from module 'maptk_ocv' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'analyze_tracks:ocv' for def type 'analyze_tracks' >>>> [DEBUG][maptk::registrar] Registering algo implementation 'ocv' for def type 'analyze_tracks' >>>> >>>> But then right after that, I get an Access Violation with this call stack. What's happening? >>>> >>>> msvcr120.dll!memchr(unsigned char * buf, unsigned char chr, unsigned long cnt) Line 101 Unknown >>>> > opencv_features2d249.dll!std::basic_string,std::allocator >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908 C++ >>>> opencv_features2d249.dll!cv::FeatureDetector::create(const std::basic_string,std::allocator > & detectorType) Line 93 C++ >>>> maptk_ocv.dll!maptk::ocv::detect_features::priv::default_detector() Line 76 C++ >>>> maptk_ocv.dll!maptk::ocv::detect_features::priv::priv() Line 63 C++ >>>> maptk_ocv.dll!maptk::ocv::detect_features::detect_features() Line 94 C++ >>>> maptk_ocv.dll!maptk::algo::algorithm_impl::register_self(maptk::registrar & reg) Line 370 C++ >>>> maptk_ocv.dll!maptk::ocv::register_algorithms(maptk::registrar & reg) Line 70 C++ >>>> maptk_ocv_plugin.dll!register_algo_impls(maptk::registrar & reg) Line 44 C++ >>>> maptk_ocv_plugin.dll!private_register_algo_impls(maptk::registrar & reg) Line 59 C++ >>>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::register_from_module(boost::filesystem::path module_path) Line 293 C++ >>>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_modules_in_directory(boost::filesystem::path dir_path, std::basic_string,std::allocator > name) Line 198 C++ >>>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string,std::allocator > name) Line 146 C++ >>>> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string,std::allocator > name) Line 409 C++ >>>> maptk_track_features.exe!maptk_main(int argc, const char * * argv) Line 236 C++ >>>> maptk_track_features.exe!main(int argc, const char * * argv) Line 489 C++ >>>> maptk_track_features.exe!__tmainCRTStartup() Line 626 C >>>> maptk_track_features.exe!mainCRTStartup() Line 466 C >>>> >>>> >>>> The offending code seems to be this: >>>> /// create the default feature detector >>>> static cv::Ptr default_detector() >>>> { >>>> cv::Ptr det; >>>> // try the SURF detector first >>>> det = cv::FeatureDetector::create("SURF"); //////// Access Violation here. >>>> if( !det ) >>>> { >>>> // if SURF is not available (nonfree not built) use ORB >>>> det = cv::FeatureDetector::create("ORB"); >>>> } >>>> return det; >>>> } >>>> >>>> On Tue, Oct 6, 2015 at 2:47 PM, Michael Rosen > wrote: >>>> Thanks very much. This looks really helpful. I'll give it a spin and let you know how it goes. >>>> >>>> msr >>>> >>>> On Tue, Oct 6, 2015 at 2:01 PM, Matthew Leotta > wrote: >>>> >>>>> On Oct 6, 2015, at 3:38 PM, Michael Rosen > wrote: >>>>> >>>>> Thanks for this. It compiles and the assert is gone. >>>>> >>>>> To be clear, here's what I did: >>>>> git clone https://github.com/Kitware/maptk.git >>>>> cd .\maptk >>>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>>> git checkout dev/camera-pass-by-reference >>>>> cmake -G "NMake Makefiles" -DBOOST_ROOT=C:\dev\fletch\install -DEIGEN3_INCLUDE_DIR="C:\Program Files (x86)\Eigen\include\eigen3" >>>>> nmake >>>>> nmake install >>>> >>>> >>>> Interesting, so you didn?t need to do any of the defines to disable byte alignment for Eigen? Were you building master or release before? >>>> >>>> By the way, I have now merged that dev/camera-pass-by-reference branch into both the release and master branches of MAP-Tk, so you should be able to use one of the primary branches again. >>>> >>>> >>>>> >>>>> Is there a simple workflow you can pass that will demonstrate use of some of the utilities. For example, suppose I have a collection of overlapping images, what can I do with them? >>>> >>>> I?ve been meaning to write up a tutorial on this, but haven?t gotten to it yet. Part of this is because there are big API changes coming soon as well as improvements in algorithms. There is a bunch of stuff building up that I can?t release yet until I get approval from AFRL. A preview of those changes is on the kwiver-integration branch. We are pulling a lot of core guts of MAP-Tk out into a new repository named VITAL (https://github.com/kitware/vital ) that is shared across KWIVER projects. I don?t recommend building that on Windows just yet. But Keith Fieldhouse is working on a KWIVER ?super build? that will use CMake to make the various projects build together easily. >>>> >>>> Anyway, the best I can do at this point is to point you to a tutorial I gave back in June at the CVPR conference: >>>> >>>> http://www.kitware.com/cvpr2015-tutorial.html >>>> >>>> This used a version of MAP-Tk similar to the current release branch. There are examples for applying MAP-Tk to a sample dataset. A Linux VM image is provided with all the software and data pre-installed, but you can also get the config files here: >>>> >>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Exercises/maptk >>>> >>>> and the sample data here: >>>> >>>> https://github.com/mleotta/cvpr2015-opensfm/tree/master/Data/CLIF_2007 >>>> >>>> and slides explaining what to do here: >>>> >>>> http://midas3.kitware.com/midas/download/item/317119/Hands_on_with_MAP-Tk.pdf >>>> >>>> FYI, MAP-Tk is (for the moment) a bit specialized to aerial imagery, so it might not work well out of the box on arbitrary images. >>>> >>>> Good Luck, >>>> Matt >>>> >>>> >>>> >>>>> >>>>> msr >>>>> >>>>> On Tue, Oct 6, 2015 at 10:36 AM, Matthew Leotta > wrote: >>>>> Michael, >>>>> >>>>> Thank you for reporting this issue. I?ll be upfront and warn you that I?m not a Windows developer and MAP-Tk is currently better tested on Linux and Mac. That said, we are working toward getting things better running on Windows more reliably. >>>>> >>>>> In this case, the issues are related to Eigen byte-alignment issues as explained on the Eigen website linked from your error message: >>>>> >>>>> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html >>>>> >>>>> I have read this page before, and expected I would need to make changes at some point to work around these issues, but until now I had not come across a compiler that exhibited these symptoms. We should probably try to get a VisualStudio 2012 build up on our dashboard so I can work through those issues properly. I expect that will take some time. A shorter term solution is to try to disable alignment in your build. Can you try the solutions described at the bottom of the page at the above URL? In the "I don't care about vectorization, how do I get rid of that stuff?? section it suggests defining some macros to disable alignment. Let me know if that works. >>>>> >>>>> In the meantime, I can at least work around that pass-by-value build issue. That function is pass-by-value because we intentionally want to make a local copy of the camera object to modify. However, I can explicitly make that copy inside the function instead. I?ve done this on the release branch of MAP-Tk and made a pull request (https://github.com/Kitware/maptk/pull/88 ). Can you try to build this branch and verify that it at least builds for you? >>>>> >>>>> git fetch origin pull/88/head:dev/camera-pass-by-reference >>>>> git checkout dev/camera-pass-by-reference >>>>> >>>>> If that works, I?ll merge this change into the release and master branches. Also let me know if the solution on the Eigen page helps. >>>>> >>>>> ?Matt >>>>> >>>>> >>>>>> On Oct 5, 2015, at 1:24 PM, Michael Rosen > wrote: >>>>>> >>>>>> Hello Kwiver-folk, >>>>>> >>>>>> I'm building MapTK on Windows 7/64 using VStudio 12 and having two immediate difficulties: a compilation problem and a runtime assert. >>>>>> >>>>>> MapTK is version 0.6.0, Eigen is 3.2.6 >>>>>> >>>>>> I've worked through getting Boost and Eigen built. When I compile maptk, the first problem is this: >>>>>> >>>>>> [ 98%] Building CXX object tools/CMakeFiles/maptk_pos2krtd.dir/pos2krtd.cxx.obj >>>>>> >>>>>> pos2krtd.cxx >>>>>> >>>>>> C:\dev\maptk\tools\pos2krtd.cxx(220) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>>>> >>>>>> be aligned >>>>>> >>>>>> C:\dev\maptk\tools\pos2krtd.cxx(238) : error C2719: 'base_camera': formal parameter with __declspec(align('16')) won't >>>>>> >>>>>> ? >>>>>> >>>>>> >>>>>> I fixed these compilation errors by changing the signature of the offending function from pass-by-value to pass-by-reference: >>>>>> >>>>>> >>>>>> /// Convert a POS file to a KRTD file >>>>>> >>>>>> bool convert_pos2krtd(const maptk::path_t& pos_filename, >>>>>> >>>>>> const maptk::path_t& krtd_filename, >>>>>> >>>>>> maptk::local_geo_cs& cs, >>>>>> >>>>>> maptk::camera_d& base_camera, // msr. was pass-by-value >>>>>> >>>>>> maptk::rotation_d const& ins_rot_offset = maptk::rotation_d()) >>>>>> >>>>>> >>>>>> >>>>>> That allows everything to compile and link. The next problem was that I got an Eigen Assert when I run any of the executables: >>>>>> >>>>>> >>>>>> C:\Program Files (x86)\MAPTK\bin>maptk_analyze_tracks.exe >>>>>> >>>>>> ... >>>>>> >>>>>> Assertion failed: (reinterpret_cast(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/d >>>>>> ox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****", file c:\program files (x86)\eigen\include\eigen >>>>>> >>>>>> 3\eigen\src/Core/DenseStorage.h, line 86 >>>>>> >>>>>> >>>>>> The web page says that classes which contain certain Eigen data structures as members need to use the >>>>>> >>>>>> EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro to override the "new" operator so that those members will be 16-byte aligned. I've done that but am still seeing the assert. >>>>>> >>>>>> >>>>>> >>>>>> Can anyone offer insight into any of this? >>>>>> >>>>>> >>>>>> >>>>>> msr >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-users mailing list >>>>>> Kwiver-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: