[Kwiver-users] MapTK issues on Windows
Michael Rosen
michael.rosen at gmail.com
Thu Oct 15 00:52:04 EDT 2015
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 <matt.leotta at kitware.com>
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 <michael.rosen at gmail.com>
> 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<char,std::char_traits<char>,std::allocator<char>
> >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908
> C++
> > opencv_features2d249.dll!cv::FeatureDetector::create(const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
> 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<maptk::ocv::detect_features,maptk::algo::detect_features>::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<char,std::char_traits<char>,std::allocator<char> > name)
> Line 198 C++
> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > name) Line 146 C++
> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string<char,std::char_traits<char>,std::allocator<char>
> > 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> 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 <matt.leotta at kitware.com>
> 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 <michael.rosen at gmail.com>
>> 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 <matt.leotta at kitware.com>
>> 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 <michael.rosen at gmail.com>
>>> 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<char,std::char_traits<char>,std::allocator<char>
>>> >::find(const char * _Ptr, unsigned int _Off, unsigned int _Count) Line 1908
>>> C++
>>> opencv_features2d249.dll!cv::FeatureDetector::create(const
>>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
>>> 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<maptk::ocv::detect_features,maptk::algo::detect_features>::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<char,std::char_traits<char>,std::allocator<char> > name)
>>> Line 198 C++
>>> maptk_apm.dll!maptk::algorithm_plugin_manager::impl::load_from_search_paths(std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>> > name) Line 146 C++
>>> maptk_apm.dll!maptk::algorithm_plugin_manager::register_plugins(std::basic_string<char,std::char_traits<char>,std::allocator<char>
>>> > 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<cv::FeatureDetector> default_detector()
>>> {
>>> cv::Ptr<cv::FeatureDetector> 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 <michael.rosen at gmail.com>
>>> 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 <matt.leotta at kitware.com
>>>> > wrote:
>>>>
>>>>>
>>>>> On Oct 6, 2015, at 3:38 PM, Michael Rosen <michael.rosen at gmail.com>
>>>>> 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 <michael.rosen at gmail.com>
>>>>>> 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<size_t>(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: <http://public.kitware.com/pipermail/kwiver-users/attachments/20151014/7666936c/attachment-0001.html>
More information about the Kwiver-users
mailing list