From hmadjidi at gmail.com Wed Jan 6 11:07:09 2016 From: hmadjidi at gmail.com (Hossein Madjidi) Date: Wed, 6 Jan 2016 11:07:09 -0500 Subject: [Kwiver-users] Problem running maptk_track_features.exe Message-ID: I came across map-tk project when I was looking for an SfM solution, and I found it very promising based in its github page. Then, I tried to run the SfM workflow by downloading the Windows binary files and running maptk_track_features.exe as the first step. I used the sample configuration file as the start and just added the image list file as the input, and ran it with the other default parameters. However, I get the following message and it seems that "feature_tracker:type" doesn't accept "default" as the value: "..\MAP-Tk-0.7.1-Windows-AMD64\bin\maptk_track_features.exe" -c maptk_track_features.conf File parsed! Contained 57 k/v entries. Configuration Failure: invalid option feature_tracker:type = default valid options are Config Check Fail: feature_tracker configuration check failed Configuration Failure: invalid option image_reader:type = ocv valid options are Config Check Fail: image_reader configuration check failed Configuration Failure: invalid option convert_image:type = default valid options are Config Check Fail: convert_image configuration check failed ERROR: Configuration not valid. I would appreciate if you can help me to resolve the issue. Thanks Hossein -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Jan 6 16:12:59 2016 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 6 Jan 2016 16:12:59 -0500 Subject: [Kwiver-users] Problem running maptk_track_features.exe In-Reply-To: References: Message-ID: <2694B076-D284-44AE-9F04-8ECAF1BA1F21@kitware.com> Hossein, Thank you for your e-mail. This has exposed a few issues with our last release. 1) The sample configuration files shipped with the v0.7.1 release are outdated. The ?default" types were renamed to ?core?, but I didn?t update the same config. There are likely other issues as well. I?ll need to regenerate an updated config file and test it. 2) Based on your output (specifically, there are no options listed after ?valid options are?) it seems that your command line tool is not finding the MAP-Tk plugins. I?ve debugged this and found that the search path for plugins is incorrect in the executables and it?s not yet configurable in this release. 3) Even if the plugins are found, they include additional 3rd party DLLs that are missing from the installer package. This release, v0.7.1, is the first time a MAP-Tk release has come with an installer. In producing the installer packages for v0.7.1 I only tested the GUI application on Windows and not the command line tools. I should point out that Windows is not my primary development platform and MAP-Tk has been tested less on Windows than other platforms. That said, we support Windows and want to make it work. I will try to work through these issues and produce a new release. It may take some time because I?m currently busy with other projects. In the mean time, you can avoid problems 2 and 3 by building from source. You can work around problem 1 by generating a new config file from scratch using the instructions in the README. Thanks again for reporting these issues, Matt > On Jan 6, 2016, at 11:07 AM, Hossein Madjidi wrote: > > I came across map-tk project when I was looking for an SfM solution, and I found it very promising based in its github page. > Then, I tried to run the SfM workflow by downloading the Windows binary files and running maptk_track_features.exe as the first step. I used the sample configuration file as the start and just added the image list file as the input, and ran it with the other default parameters. > However, I get the following message and it seems that "feature_tracker:type" doesn't accept "default" as the value: > > > "..\MAP-Tk-0.7.1-Windows-AMD64\bin\maptk_track_features.exe" -c maptk_track_features.conf > > File parsed! Contained 57 k/v entries. > Configuration Failure: invalid option > feature_tracker:type = default > valid options are > Config Check Fail: feature_tracker configuration check failed > Configuration Failure: invalid option > image_reader:type = ocv > valid options are > Config Check Fail: image_reader configuration check failed > Configuration Failure: invalid option > convert_image:type = default > valid options are > Config Check Fail: convert_image configuration check failed > ERROR: Configuration not valid. > > > > I would appreciate if you can help me to resolve the issue. > > > Thanks > Hossein > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users From matt.leotta at kitware.com Fri Jan 15 09:22:15 2016 From: matt.leotta at kitware.com (Matthew Leotta) Date: Fri, 15 Jan 2016 09:22:15 -0500 Subject: [Kwiver-users] [Kwiver-announce] About map-tk software In-Reply-To: <486f20.33da8.152446f2185.Coremail.yangbiaoshy@163.com> References: <486f20.33da8.152446f2185.Coremail.yangbiaoshy@163.com> Message-ID: <0DDA8FF6-2D4A-4962-AC99-8CA1E4E7C817@kitware.com> (I have moved this discussion to the kwiver-users list. kwiver-users is the appropriate list for support questions. kwiver-announce is just for announcements.) Thank you for your interest in our MAP-Tk software. The GUI is a new addition to MAP-Tk. In the current release, the GUI is only used to visualize the results produced by the command line tools. The next minor release of MAP-Tk (v0.8.0 - expected in February or March) will add some processing capability to the GUI, but not yet end-to-end processing of video. Ultimately we plan to support end-to-end processing in the GUI, but it will take some time. MAP-Tk is still a relatively new project and is still considered ?pre-release? software. You can process video with the command line tools, but there are a few caveats to be aware of. First, direct support of video files is under development, so for now you will need to decode your video file into a sequence of image files (e.g. PNG or JPG). You can do this with ffmpeg or various other tools. Second, if you are using the precompiled binary packages for MAP-Tk v0.7.1 you should be aware of a known issue of missing libraries in the package (https://github.com/Kitware/maptk/issues/125 ). We hope to have this resolved in a week or two and then we will release new binaries with MAP-Tk v0.7.2. I?m planning to write a blog post in the future that provides a step-by-step tutorial for running MAP-Tk, so keep a look out for that. ?Matt > On Jan 15, 2016, at 3:36 AM, yangbiaoshy wrote: > > hi : > I download map-tk software , I want to process video data, but I can't import any video file to software ,the map-tk gui only support conf\ply\krtd\txt , my video file format like mp4\avi and so on, so how to import video file to map-tk software! > > thanks > > > 2016-01-15 > yangbiaoshy > _______________________________________________ > Kwiver-announce mailing list > Kwiver-announce at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpelapur at archlinux.info Sat Jan 16 15:00:51 2016 From: rpelapur at archlinux.info (R. Pelapur) Date: Sat, 16 Jan 2016 14:00:51 -0600 Subject: [Kwiver-users] [MapTk] : CMake Error : Missing include files Message-ID: <569AA173.5090606@archlinux.info> Hi, Getting CMake errors about vital and kwiver files (which are not present in the current subdirectories) CMake Error at CMakeLists.txt:50 (include): include could not find load file: kwiver-utils CMake Error at CMakeLists.txt:52 (include): include could not find load file: vital-flags CMake Error at maptk/CMakeLists.txt:65 (kwiver_install_headers): Unknown CMake command "kwiver_install_headers". Using CMake 3.4.20160112-gb5009 and MapTk (fef1ad996828039e72ff2dfe210cd3f7cf420784). Had to go back to a commit prior to the release merge : 0be1f318d969be880139b6403fbc83fd77add917 for now which builds successfully. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Mon Jan 18 09:07:18 2016 From: matt.leotta at kitware.com (Matthew Leotta) Date: Mon, 18 Jan 2016 09:07:18 -0500 Subject: [Kwiver-users] [MapTk] : CMake Error : Missing include files In-Reply-To: <569AA173.5090606@archlinux.info> References: <569AA173.5090606@archlinux.info> Message-ID: <28D5D19E-EC2C-46E0-9D33-7A1746F3537B@kitware.com> The current release branch (v0.7.1) is the last minor release that does not depend on the new Vital repository (https://github.com/kitware/vital ). Vital contains many of the core data structures and low-level functionality (logging, config file parsing, etc.) that have been factored out of the MAP-Tk code base for greater sharing across KWIVER projects. On the current master branch (to be release in v0.8.0) you now must build MAP-Tk against Vital. There should be a ?vital_DIR? CMake variable that you can point to your Vital build tree or install path. Vital provides kwiver-utils and vital-flags among other things. I would expect you should get an error that Vital is not found before you get more obscure errors like those reported. Are those errors from a clean configure/build of MAP-Tk on the master branch? Did CMake complain about Vital not being found? What operating system are you running? Thanks, Matt > On Jan 16, 2016, at 3:00 PM, R. Pelapur wrote: > > Hi, > Getting CMake errors about vital and kwiver files (which are not present in the current subdirectories) > > > CMake Error at CMakeLists.txt:50 (include): > include could not find load file: > > kwiver-utils > > CMake Error at CMakeLists.txt:52 (include): > include could not find load file: > > vital-flags > > > CMake Error at maptk/CMakeLists.txt:65 (kwiver_install_headers): > Unknown CMake command "kwiver_install_headers". > > Using CMake 3.4.20160112-gb5009 and MapTk (fef1ad996828039e72ff2dfe210cd3f7cf420784). > > Had to go back to a commit prior to the release merge : 0be1f318d969be880139b6403fbc83fd77add917 for now which builds successfully. > > _______________________________________________ > 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 rpelapur at archlinux.info Mon Jan 18 09:48:38 2016 From: rpelapur at archlinux.info (rpelapur at archlinux.info) Date: Mon, 18 Jan 2016 08:48:38 -0600 Subject: [Kwiver-users] [MapTk] : CMake Error : Missing include files In-Reply-To: <28D5D19E-EC2C-46E0-9D33-7A1746F3537B@kitware.com> References: <569AA173.5090606@archlinux.info> <28D5D19E-EC2C-46E0-9D33-7A1746F3537B@kitware.com> Message-ID: <4D16A9EE-C96C-4DF2-A97F-7771F4EFB9A7@archlinux.info> > Are those errors from a clean configure/build of MAP-Tk on the master branch? Yes. It is a clean build on the master branch commit #fef1ad996828039e72ff2dfe210cd3f7cf420784 where I am getting the error. > > Did CMake complain about Vital not being found? No. The first error is the "Kwiver-utils" not being found followed by "vital-flags" not being found. > What operating system are you running? Linux (x86_64). A rolling release Arch and CentOS 6 stable if that matters. Thanks for the reply. Sent from my iPhone > On Jan 18, 2016, at 8:07 AM, Matthew Leotta wrote: > > The current release branch (v0.7.1) is the last minor release that does not depend on the new Vital repository (https://github.com/kitware/vital). Vital contains many of the core data structures and low-level functionality (logging, config file parsing, etc.) that have been factored out of the MAP-Tk code base for greater sharing across KWIVER projects. On the current master branch (to be release in v0.8.0) you now must build MAP-Tk against Vital. There should be a ?vital_DIR? CMake variable that you can point to your Vital build tree or install path. Vital provides kwiver-utils and vital-flags among other things. I would expect you should get an error that Vital is not found before you get more obscure errors like those reported. Are those errors from a clean configure/build of MAP-Tk on the master branch? Did CMake complain about Vital not being found? What operating system are you running? > > Thanks, > Matt > > >> On Jan 16, 2016, at 3:00 PM, R. Pelapur wrote: >> >> Hi, >> Getting CMake errors about vital and kwiver files (which are not present in the current subdirectories) >> >> >> CMake Error at CMakeLists.txt:50 (include): >> include could not find load file: >> >> kwiver-utils >> >> CMake Error at CMakeLists.txt:52 (include): >> include could not find load file: >> >> vital-flags >> >> >> CMake Error at maptk/CMakeLists.txt:65 (kwiver_install_headers): >> Unknown CMake command "kwiver_install_headers". >> >> Using CMake 3.4.20160112-gb5009 and MapTk (fef1ad996828039e72ff2dfe210cd3f7cf420784). >> >> Had to go back to a commit prior to the release merge : 0be1f318d969be880139b6403fbc83fd77add917 for now which builds successfully. >> >> _______________________________________________ >> 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 Mon Jan 18 11:20:42 2016 From: matt.leotta at kitware.com (Matt Leotta) Date: Mon, 18 Jan 2016 11:20:42 -0500 Subject: [Kwiver-users] [MapTk] : CMake Error : Missing include files In-Reply-To: <4D16A9EE-C96C-4DF2-A97F-7771F4EFB9A7@archlinux.info> References: <569AA173.5090606@archlinux.info> <28D5D19E-EC2C-46E0-9D33-7A1746F3537B@kitware.com> <4D16A9EE-C96C-4DF2-A97F-7771F4EFB9A7@archlinux.info> Message-ID: Thanks for reporting this. I can confirm that I see those errors. However, before the errors you should have seen the following warning: CMake Warning at CMakeLists.txt:19 (find_package): By not providing "Findvital.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "vital", but CMake did not find one. Could not find a package configuration file provided by "vital" with any of the following names: vitalConfig.cmake vital-config.cmake Add the installation prefix of "vital" to CMAKE_PREFIX_PATH or set "vital_DIR" to a directory containing one of the above files. If "vital" provides a separate development package or SDK, be sure it has been installed. That warning should actually be an error because Vital is required. We will fix this by marking Vital as REQUIRED in CMake, so the above warning will become an error and you won't see those other errors. Either way, the solution is to build the Vital project and then specify the path to it in the "vital_DIR" CMake variable in MAP-Tk. --Matt On Mon, Jan 18, 2016 at 9:48 AM, rpelapur at archlinux.info < rpelapur at archlinux.info> wrote: > Are those errors from a clean configure/build of MAP-Tk on the master > branch? > > Yes. It is a clean build on the master branch commit #fef1ad996828039e72ff2dfe210cd3f7cf420784 > where I am getting the error. > > Did CMake complain about Vital not being found? > > No. The first error is the "Kwiver-utils" not being found followed by > "vital-flags" not being found. > > What operating system are you running? > > Linux (x86_64). A rolling release Arch and CentOS 6 stable if that matters. > > Thanks for the reply. > > > Sent from my iPhone > > On Jan 18, 2016, at 8:07 AM, Matthew Leotta > wrote: > > The current release branch (v0.7.1) is the last minor release that does > not depend on the new Vital repository (https://github.com/kitware/vital). > Vital contains many of the core data structures and low-level functionality > (logging, config file parsing, etc.) that have been factored out of the > MAP-Tk code base for greater sharing across KWIVER projects. On the > current master branch (to be release in v0.8.0) you now must build MAP-Tk > against Vital. There should be a ?vital_DIR? CMake variable that you can > point to your Vital build tree or install path. Vital provides > kwiver-utils and vital-flags among other things. I would expect you should > get an error that Vital is not found before you get more obscure errors > like those reported. Are those errors from a clean configure/build of > MAP-Tk on the master branch? Did CMake complain about Vital not being > found? What operating system are you running? > > Thanks, > Matt > > > On Jan 16, 2016, at 3:00 PM, R. Pelapur wrote: > > Hi, > Getting CMake errors about vital and kwiver files (which are not present > in the current subdirectories) > > > CMake Error at CMakeLists.txt:50 (include): include could not find load > file: kwiver-utils > CMake Error at CMakeLists.txt:52 (include): include could not find load > file: vital-flags > > > CMake Error at maptk/CMakeLists.txt:65 (kwiver_install_headers): Unknown > CMake command "kwiver_install_headers". > > Using CMake 3.4.20160112-gb5009 and MapTk ( > fef1ad996828039e72ff2dfe210cd3f7cf420784). > > > Had to go back to a commit prior to the release merge : > 0be1f318d969be880139b6403fbc83fd77add917 for now which builds successfully. > > > _______________________________________________ > 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 rpelapur at archlinux.info Mon Jan 18 14:42:20 2016 From: rpelapur at archlinux.info (R. Pelapur) Date: Mon, 18 Jan 2016 13:42:20 -0600 Subject: [Kwiver-users] [MapTk]: [SOLVED] : CMake Error : Missing include files In-Reply-To: References: <569AA173.5090606@archlinux.info> <28D5D19E-EC2C-46E0-9D33-7A1746F3537B@kitware.com> <4D16A9EE-C96C-4DF2-A97F-7771F4EFB9A7@archlinux.info> Message-ID: <569D401C.8040306@archlinux.info> Solution : Vital is now required. Thanks for the fix. commit 59472c9a13db56aee2fd162ae71cabd6e39e6792 : Built and works fine. Marking as solved. On 01/18/2016 10:20 AM, Matt Leotta wrote: > Thanks for reporting this. I can confirm that I see those errors. > However, before the errors you should have seen the following warning: > > CMake Warning at CMakeLists.txt:19 (find_package): > By not providing "Findvital.cmake" in CMAKE_MODULE_PATH this > project has > asked CMake to find a package configuration file provided by > "vital", but > CMake did not find one. > > Could not find a package configuration file provided by "vital" > with any of > the following names: > > vitalConfig.cmake > vital-config.cmake > > Add the installation prefix of "vital" to CMAKE_PREFIX_PATH or set > "vital_DIR" to a directory containing one of the above files. If > "vital" > provides a separate development package or SDK, be sure it has been > installed. > > That warning should actually be an error because Vital is required. > We will fix this by marking Vital as REQUIRED in CMake, so the above > warning will become an error and you won't see those other errors. > > Either way, the solution is to build the Vital project and then > specify the path to it in the "vital_DIR" CMake variable in MAP-Tk. > > --Matt > > > On Mon, Jan 18, 2016 at 9:48 AM, rpelapur at archlinux.info > > wrote: > >> Are those errors from a clean configure/build of MAP-Tk on the >> master branch? > Yes. It is a clean build on the master branch commit > #fef1ad996828039e72ff2dfe210cd3f7cf420784 where I am getting the > error. >> Did CMake complain about Vital not being found? > No. The first error is the "Kwiver-utils" not being found followed > by "vital-flags" not being found. >> What operating system are you running? > Linux (x86_64). A rolling release Arch and CentOS 6 stable if that > matters. > > Thanks for the reply. > > > Sent from my iPhone > > On Jan 18, 2016, at 8:07 AM, Matthew Leotta > > wrote: > >> The current release branch (v0.7.1) is the last minor release >> that does not depend on the new Vital repository >> (https://github.com/kitware/vital). Vital contains many of the >> core data structures and low-level functionality (logging, config >> file parsing, etc.) that have been factored out of the MAP-Tk >> code base for greater sharing across KWIVER projects. On the >> current master branch (to be release in v0.8.0) you now must >> build MAP-Tk against Vital. There should be a ?vital_DIR? CMake >> variable that you can point to your Vital build tree or install >> path. Vital provides kwiver-utils and vital-flags among other >> things. I would expect you should get an error that Vital is not >> found before you get more obscure errors like those reported. >> Are those errors from a clean configure/build of MAP-Tk on the >> master branch? Did CMake complain about Vital not being found? >> What operating system are you running? >> >> Thanks, >> Matt >> >> >>> On Jan 16, 2016, at 3:00 PM, R. Pelapur >> > wrote: >>> >>> Hi, >>> Getting CMake errors about vital and kwiver files (which are not >>> present in the current subdirectories) >>> >>> >>> CMake Error at CMakeLists.txt:50 (include): include could not >>> find load file: kwiver-utils >>> CMake Error at CMakeLists.txt:52 (include): include could not >>> find load file: vital-flags >>> >>> >>> CMake Error at maptk/CMakeLists.txt:65 (kwiver_install_headers): >>> Unknown CMake command "kwiver_install_headers". >>> >>> Using CMake 3.4.20160112-gb5009 and MapTk >>> (fef1ad996828039e72ff2dfe210cd3f7cf420784). >>> >>> Had to go back to a commit prior to the release merge : >>> 0be1f318d969be880139b6403fbc83fd77add917 for now which builds >>> successfully. >>> >>> _______________________________________________ >>> 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 rpelapur at archlinux.info Mon Jan 18 15:27:06 2016 From: rpelapur at archlinux.info (R. Pelapur) Date: Mon, 18 Jan 2016 14:27:06 -0600 Subject: [Kwiver-users] [MapTk] : Configuration File Errors Message-ID: <569D4A9A.6000501@archlinux.info> Hello, With the new build (commit #59472c9a13db56aee2fd162ae71cabd6e39e6792) now I am getting configuration file errors (config file is the same as the one from what I was running before which did work and is basically the same as the one under /tools/config/) 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): Configuration Failure: invalid option 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): output_homography_generator:type = 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): valid options are Config Check Fail: output_homography_generator configuration check failed 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): feature_tracker:type = core 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are Config Check Fail: feature_tracker configuration check failed 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): image_reader:type = ocv 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are Config Check Fail: image_reader configuration check failed 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): convert_image:type = bypass 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are Config Check Fail: convert_image configuration check failed ERROR: Configuration not valid. Weird part is that there are no 'valid options'. After using -c -o options to correct the config file iteratively the executable doesn't give any valid options for feature_tacker:type, image_reader:type and convert_image:type. MapTk has been linked against : 1: OpenCV ( 2.4.11) (MapTk use OpenCV) 2: vxl (commit #16dd9bd26af5d530aa2cb4a887b372a157bc4961 - Sat Jan 16 2016) (MapTk use vxl) 3: Vital (commit #f36957711d08be858e1c05ed170dae3fae75c7da - Tuesday Jan 5 2016) 4: ceres-solver (commit #e9420e7a0e4254337730f574a3242d7e056cbfe8 - Sun Jul 12 2015) (MapTk use CERES) Using GCC 4.9.2 (CentOS 6). Same build configuration and the attached config file but with an older MapTk commit works without problems. -------------- next part -------------- # Algorithm to use for 'convert_image'. # Must be one of the following options: # - bypass :: Performs no conversion and returns the given image container convert_image:type = bypass # A majority of the time, mask images are a single channel, however it is # feasibly possible that certain implementations may use multi-channel masks. If # this is true we will expect multiple-channel mask images, warning when a # single-channel mask is provided. If this is false we error upon seeing a # multi-channel mask image. expect_multichannel_masks = false feature_tracker:core:descriptor_extractor:ocv:extractor:Feature2D.SURF:extended = false feature_tracker:core:descriptor_extractor:ocv:extractor:Feature2D.SURF:hessianThreshold = 100 feature_tracker:core:descriptor_extractor:ocv:extractor:Feature2D.SURF:nOctaveLayers = 3 feature_tracker:core:descriptor_extractor:ocv:extractor:Feature2D.SURF:nOctaves = 4 feature_tracker:core:descriptor_extractor:ocv:extractor:Feature2D.SURF:upright = true # The OpenCV cv::Algorithm type to use for 'extractor'. feature_tracker:core:descriptor_extractor:ocv:extractor:type = Feature2D.SURF # Algorithm to use for 'descriptor_extractor'. # Must be one of the following options: # - ocv feature_tracker:core:descriptor_extractor:type = ocv 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 # Algorithm to use for 'feature_detector'. # Must be one of the following options: # - ocv feature_tracker:core:feature_detector:type = ocv # The OpenCV cv::Algorithm type to use for 'matcher'. feature_tracker:core:feature_matcher:homography_guided:feature_matcher1:ocv:matcher:type = DescriptorMatcher.FlannBasedMatcher # Algorithm to use for 'feature_matcher1'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:feature_matcher:homography_guided:feature_matcher1:type = ocv # Algorithm to use for 'feature_matcher2'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:feature_matcher:homography_guided:feature_matcher2:type = # Algorithm to use for 'filter_features'. # Must be one of the following options: # - magnitude feature_tracker:core:feature_matcher:homography_guided:filter_features:type = # Algorithm to use for 'homography_estimator'. # Must be one of the following options: # - ocv # - vxl feature_tracker:core:feature_matcher:homography_guided:homography_estimator:type = vxl # The acceptable error distance (in pixels) between warped and measured points # to be considered an inlier match. feature_tracker:core:feature_matcher:homography_guided:inlier_scale = 5 # The minimum required inlier point count. If there are less than this many # inliers, no matches will be output. feature_tracker:core:feature_matcher:homography_guided:min_required_inlier_count = 0 # The minimum required percentage of inlier points. If the percentage of points # considered inliers is less than this amount, no matches will be output. feature_tracker:core:feature_matcher:homography_guided:min_required_inlier_percent = 0 # Algorithm to use for 'feature_matcher'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:feature_matcher:type = homography_guided # Number of close loops methods we want to use. feature_tracker:core:loop_closer:multi_method:count = 2 # Should bad frame detection be enabled? This option will attempt to bridge the # gap between frames which don't meet certain criteria (percentage of feature # points tracked) and will instead attempt to match features on the current # frame against past frames to meet this criteria. This is useful when there can # be bad frames. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:enabled = true # The OpenCV cv::Algorithm type to use for 'matcher'. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:feature_matcher1:ocv:matcher:type = DescriptorMatcher.FlannBasedMatcher # Algorithm to use for 'feature_matcher1'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:feature_matcher1:type = ocv # Algorithm to use for 'feature_matcher2'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:feature_matcher2:type = feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:feature_matcher:ocv:matcher:type = DescriptorMatcher.FlannBasedMatcher feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:feature_matcher:type = ocv # Algorithm to use for 'filter_features'. # Must be one of the following options: # - magnitude feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:filter_features:type = # Algorithm to use for 'homography_estimator'. # Must be one of the following options: # - ocv # - vxl feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:homography_estimator:type = vxl # The acceptable error distance (in pixels) between warped and measured points # to be considered an inlier match. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:inlier_scale = 5 # The minimum required inlier point count. If there are less than this many # inliers, no matches will be output. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:min_required_inlier_count = 0 # The minimum required percentage of inlier points. If the percentage of points # considered inliers is less than this amount, no matches will be output. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:homography_guided:min_required_inlier_percent = 0 # Algorithm to use for 'feature_matcher'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:feature_matcher:type = homography_guided # Maximum number of frames to search in the past for matching to the end of the # last shot. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:max_search_length = 5 # Number of frames for a new shot to be considered valid before attempting to # stitch to prior shots. feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:new_shot_length = 2 # The required percentage of features needed to be matched for a stitch to be # considered successful (value must be between 0.0 and 1.0). feature_tracker:core:loop_closer:multi_method:method1:bad_frames_only:percent_match_req = 0.34999999999999998 # Algorithm to use for 'method1'. # Must be one of the following options: # - bad_frames_only :: Attempts short-term loop closure based on percentage of # feature points tracked. # - multi_method :: Iteratively run multiple loop closure algorithms # - vxl_homography_guided feature_tracker:core:loop_closer:multi_method:method1:type = bad_frames_only # Algorithm to use for 'method2'. # Must be one of the following options: # - bad_frames_only :: Attempts short-term loop closure based on percentage of # feature points tracked. # - multi_method :: Iteratively run multiple loop closure algorithms # - vxl_homography_guided feature_tracker:core:loop_closer:multi_method:method2:type = vxl_homography_guided # Term which controls when we make new loop closure checkpoints. Everytime the # percentage of tracked features drops below this threshold, we generate a new # checkpoint. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:checkpoint_percent_overlap = 0.69999999999999996 # Is long term loop closure enabled? feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:enabled = true # The OpenCV cv::Algorithm type to use for 'matcher'. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:feature_matcher1:ocv:matcher:type = DescriptorMatcher.FlannBasedMatcher # Algorithm to use for 'feature_matcher1'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:feature_matcher1:type = ocv # Algorithm to use for 'feature_matcher2'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:feature_matcher2:type = # Algorithm to use for 'filter_features'. # Must be one of the following options: # - magnitude feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:filter_features:type = # Algorithm to use for 'homography_estimator'. # Must be one of the following options: # - ocv # - vxl feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:homography_estimator:type = vxl # The acceptable error distance (in pixels) between warped and measured points # to be considered an inlier match. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:inlier_scale = 5 # The minimum required inlier point count. If there are less than this many # inliers, no matches will be output. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:min_required_inlier_count = 20 # The minimum required percentage of inlier points. If the percentage of points # considered inliers is less than this amount, no matches will be output. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:homography_guided:min_required_inlier_percent = 0.05 # Algorithm to use for 'feature_matcher'. # Must be one of the following options: # - homography_guided # - ocv # - vxl_constrained feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:feature_matcher:type = homography_guided # Optional output location for a homography text file. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:homography_filename = # Maximum past search distance in terms of number of checkpoints. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:max_checkpoint_frames = 10000 # Allow for the possibility of a frame, N, to have a reference frame, A, when a # frame M < N has a reference frame B > A (assuming frames were sequentially # iterated over with this algorithm). feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:allow_ref_frame_regression = true # Backprojection threshold in terms of L2 distance (number of pixels) feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:backproject_threshold = 4 # Algorithm to use for 'estimator'. # Must be one of the following options: # - ocv # - vxl feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:estimator:type = vxl # After how many frames should we forget all info about a track? feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:forget_track_threshold = 5 # The acceptable error distance (in pixels) between warped and measured points # to be considered an inlier match. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:inlier_scale = 2 # Minimum number of matches required between source and reference planes for # valid homography estimation. feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:min_matches_threshold = 4 # Minimum track length to use for homography regression feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:min_track_length = 1 # Should we remove extra points if the backproject error is high? feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:core:use_backproject_error = false # Algorithm to use for 'ref_computer'. # Must be one of the following options: # - core :: Default online sequential-frame reference homography estimator feature_tracker:core:loop_closer:multi_method:method2:vxl_homography_guided:ref_computer:type = core # Algorithm to use for 'loop_closer'. # Must be one of the following options: # - bad_frames_only :: Attempts short-term loop closure based on percentage of # feature points tracked. # - multi_method :: Iteratively run multiple loop closure algorithms # - vxl_homography_guided feature_tracker:core:loop_closer:type = multi_method # Algorithm to use for 'feature_tracker'. # Must be one of the following options: # - core feature_tracker:type = core # Path to an input file containing new-line separated paths to sequential image # files. image_list_file = abq_215_list.txt # Algorithm to use for 'image_reader'. # Must be one of the following options: # - ocv # - vxl image_reader:type = ocv # If true, all mask images will be inverted after loading. This is useful if # mask images read in use positive values to indicated masked areas instead of # non-masked areas. invert_masks = false # Optional path to an input file containing new-line separated paths to mask # images. This list should be parallel in association to files specified in # ``image_list_file``. Mask image must be the same size as the image they are # associated with. # # Leave this blank if no image masking is desired. mask_list_file = # Optional path to a file to write source-to-reference homographies for each # frame. Leave blank to disable this output. The output_homography_generator # algorithm type only needs to be set if this is set. output_homography_file = abq_215_another_test_homography.txt # Allow for the possibility of a frame, N, to have a reference frame, A, when a # frame M < N has a reference frame B > A (assuming frames were sequentially # iterated over with this algorithm). output_homography_generator:core:allow_ref_frame_regression = true # Backprojection threshold in terms of L2 distance (number of pixels) output_homography_generator:core:backproject_threshold = 4 # Algorithm to use for 'estimator'. # Must be one of the following options: # - ocv # - vxl output_homography_generator:core:estimator:type = vxl # After how many frames should we forget all info about a track? output_homography_generator:core:forget_track_threshold = 5 # The acceptable error distance (in pixels) between warped and measured points # to be considered an inlier match. output_homography_generator:core:inlier_scale = 2 # Minimum number of matches required between source and reference planes for # valid homography estimation. output_homography_generator:core:min_matches_threshold = 4 # Minimum track length to use for homography regression output_homography_generator:core:min_track_length = 1 # Should we remove extra points if the backproject error is high? output_homography_generator:core:use_backproject_error = false # Algorithm to use for 'output_homography_generator'. # Must be one of the following options: # - core :: Default online sequential-frame reference homography estimator output_homography_generator:type = core # Path to a file to write output tracks to. If this file exists, it will be # overwritten. output_tracks_file = abq_215_another_test_tracks.txt From matt.leotta at kitware.com Mon Jan 18 16:35:43 2016 From: matt.leotta at kitware.com (Matthew Leotta) Date: Mon, 18 Jan 2016 16:35:43 -0500 Subject: [Kwiver-users] [MapTk] : Configuration File Errors In-Reply-To: <569D4A9A.6000501@archlinux.info> References: <569D4A9A.6000501@archlinux.info> Message-ID: <456CF444-606C-407F-A664-012D92E3EA60@kitware.com> The symptom that you are seeing (no valid options listed) usually means that no plugins are being found. If you are running the tools out of the build directory and not installing them first, you?ll want to enable ?MAPTK_USE_BUILD_PLUGIN_DIR? in the CMake options. This tells the tools to also search the build directory when looking for plugins. Similarly there is a ?VITAL_USE_BUILD_PLUGIN_DIR? in Vital as well. If all else fails, you can specify the path to your plugins with the VITAL_PLUGIN_PATH environment variable. There is also a tool in Vital called ?plugin_explorer? that will print out info about which plugins around found. Note, however, that this tool only looks in the build/install directories for Vital. It will not find plugins in the MAP-Tk build directory unless VITAL_PLUGIN_PATH is set and points to them. ?Matt > On Jan 18, 2016, at 3:27 PM, R. Pelapur wrote: > > Hello, > With the new build (commit #59472c9a13db56aee2fd162ae71cabd6e39e6792) now I am getting configuration file errors (config file is the same as the one from what I was running before which did work and is basically the same as the one under /tools/config/) > > > 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): Configuration Failure: invalid option > 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): output_homography_generator:type = > 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): valid options are > Config Check Fail: output_homography_generator configuration check failed > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): feature_tracker:type = core > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are > Config Check Fail: feature_tracker configuration check failed > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): image_reader:type = ocv > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are > Config Check Fail: image_reader configuration check failed > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): convert_image:type = bypass > 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are > Config Check Fail: convert_image configuration check failed > ERROR: Configuration not valid. > > Weird part is that there are no 'valid options'. After using -c -o options to correct the config file iteratively the executable doesn't give any valid options for feature_tacker:type, image_reader:type and convert_image:type. > > MapTk has been linked against : > 1: OpenCV ( 2.4.11) (MapTk use OpenCV) > 2: vxl (commit #16dd9bd26af5d530aa2cb4a887b372a157bc4961 - Sat Jan 16 2016) (MapTk use vxl) > 3: Vital (commit #f36957711d08be858e1c05ed170dae3fae75c7da - Tuesday Jan 5 2016) > 4: ceres-solver (commit #e9420e7a0e4254337730f574a3242d7e056cbfe8 - Sun Jul 12 2015) (MapTk use CERES) > > > Using GCC 4.9.2 (CentOS 6). > > Same build configuration and the attached config file but with an older MapTk commit works without problems. > > > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users From rpelapur at archlinux.info Mon Jan 18 16:37:45 2016 From: rpelapur at archlinux.info (R. Pelapur) Date: Mon, 18 Jan 2016 15:37:45 -0600 Subject: [Kwiver-users] [MapTk]: [SOLVED] : Configuration File Errors In-Reply-To: <456CF444-606C-407F-A664-012D92E3EA60@kitware.com> References: <569D4A9A.6000501@archlinux.info> <456CF444-606C-407F-A664-012D92E3EA60@kitware.com> Message-ID: <569D5B29.4090800@archlinux.info> Yup. Needs the plugin directory. Works now. Just did an install. Thanks. Marking as solved. On 01/18/2016 03:35 PM, Matthew Leotta wrote: > The symptom that you are seeing (no valid options listed) usually means that no plugins are being found. If you are running the tools out of the build directory and not installing them first, you?ll want to enable ?MAPTK_USE_BUILD_PLUGIN_DIR? in the CMake options. This tells the tools to also search the build directory when looking for plugins. Similarly there is a ?VITAL_USE_BUILD_PLUGIN_DIR? in Vital as well. If all else fails, you can specify the path to your plugins with the VITAL_PLUGIN_PATH environment variable. There is also a tool in Vital called ?plugin_explorer? that will print out info about which plugins around found. Note, however, that this tool only looks in the build/install directories for Vital. It will not find plugins in the MAP-Tk build directory unless VITAL_PLUGIN_PATH is set and points to them. > > ?Matt > > >> On Jan 18, 2016, at 3:27 PM, R. Pelapur wrote: >> >> Hello, >> With the new build (commit #59472c9a13db56aee2fd162ae71cabd6e39e6792) now I am getting configuration file errors (config file is the same as the one from what I was running before which did work and is basically the same as the one under /tools/config/) >> >> >> 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): Configuration Failure: invalid option >> 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): output_homography_generator:type = >> 2016-01-18 14:11:41.322 WARN algorithm.cxx(237): valid options are >> Config Check Fail: output_homography_generator configuration check failed >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): feature_tracker:type = core >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are >> Config Check Fail: feature_tracker configuration check failed >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): image_reader:type = ocv >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are >> Config Check Fail: image_reader configuration check failed >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): Configuration Failure: invalid option >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): convert_image:type = bypass >> 2016-01-18 14:11:41.324 WARN algorithm.cxx(237): valid options are >> Config Check Fail: convert_image configuration check failed >> ERROR: Configuration not valid. >> >> Weird part is that there are no 'valid options'. After using -c -o options to correct the config file iteratively the executable doesn't give any valid options for feature_tacker:type, image_reader:type and convert_image:type. >> >> MapTk has been linked against : >> 1: OpenCV ( 2.4.11) (MapTk use OpenCV) >> 2: vxl (commit #16dd9bd26af5d530aa2cb4a887b372a157bc4961 - Sat Jan 16 2016) (MapTk use vxl) >> 3: Vital (commit #f36957711d08be858e1c05ed170dae3fae75c7da - Tuesday Jan 5 2016) >> 4: ceres-solver (commit #e9420e7a0e4254337730f574a3242d7e056cbfe8 - Sun Jul 12 2015) (MapTk use CERES) >> >> >> Using GCC 4.9.2 (CentOS 6). >> >> Same build configuration and the attached config file but with an older MapTk commit works without problems. >> >> >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users From rpelapur at archlinux.info Wed Jan 20 15:11:08 2016 From: rpelapur at archlinux.info (R. Pelapur) Date: Wed, 20 Jan 2016 14:11:08 -0600 Subject: [Kwiver-users] [MapTk] : maptk_track_features : vnl_matrix crashes : large datasets Message-ID: <569FE9DC.4010308@archlinux.info> While MapTk works well on smaller datasets (on the order of 200-300 frames with each frame around 6K x 4K) the homography estimation (i presume) is failing for larger datasets. One particular example is a crash on Frame # 423 (6K x 4K) : inlier ratio: 765/819 [INFO][maptk::compute_ref_homography_core] Inliers after estimation: 375 /vxl/core/vnl/vnl_matrix.txx: 1274: matrix has non-finite elements /vxl/core/vnl/vnl_matrix.txx: it is quite big (464x9) /vxl/core/vnl/vnl_matrix.txx: in the following picture '-' means finite and '*' means non-finite: **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** **----*** ---**-*** /vxl/core/vnl/vnl_matrix.txx: calling abort() I am currently debugging it to find how many inliers remained and to see if the frame has some kind of problem but any help in this regard would be helpful. Thanks, From matt.leotta at kitware.com Wed Jan 20 15:51:34 2016 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 20 Jan 2016 15:51:34 -0500 Subject: [Kwiver-users] [MapTk] : maptk_track_features : vnl_matrix crashes : large datasets In-Reply-To: <569FE9DC.4010308@archlinux.info> References: <569FE9DC.4010308@archlinux.info> Message-ID: I don?t expect that this particular failure is a results of the dataset size. This is a failure within VXL. If recall correctly there are certain degenerate cases that will cause NaN or Inf values during homography estimation. This can happen during a RANSAC loop if the selected minimal correspondence subset hits one of these degeneracies. Given that this is RANSAC it shouldn?t be a big issue. The algorithm should just ignore that sample and move on to the next one. The problem is that there are checks deep within the vnl_matrix class that find this behavior very problematic and abort. Really VXL should be throwing an exception and the RANSAC algorithm should catch the exception. However, VXL does not make heavy use of exceptions. In short, this is a VXL bug. I can think of two short term fixes: 1) Build VXL in release mode, this should disable the asserts. I believe the VXL code will actually work in this case. 2) Use a different homography estimation algorithm. You could use the OpenCV plugin for homography estimation instead of VXL. Good luck, Matt > On Jan 20, 2016, at 3:11 PM, R. Pelapur wrote: > > While MapTk works well on smaller datasets (on the order of 200-300 frames with each frame around 6K x 4K) the homography estimation (i presume) is failing for larger datasets. One particular example is a crash on Frame # 423 (6K x 4K) : > > inlier ratio: 765/819 > [INFO][maptk::compute_ref_homography_core] Inliers after estimation: 375 > > > /vxl/core/vnl/vnl_matrix.txx: 1274: matrix has non-finite elements > /vxl/core/vnl/vnl_matrix.txx: it is quite big (464x9) > /vxl/core/vnl/vnl_matrix.txx: in the following picture '-' means finite and '*' means non-finite: > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > **----*** > ---**-*** > /vxl/core/vnl/vnl_matrix.txx: calling abort() > > I am currently debugging it to find how many inliers remained and to see if the frame has some kind of problem but any help in this regard would be helpful. > > Thanks, > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users From rpelapur at archlinux.info Wed Jan 20 20:47:31 2016 From: rpelapur at archlinux.info (rpelapur at archlinux.info) Date: Wed, 20 Jan 2016 19:47:31 -0600 Subject: [Kwiver-users] [MapTk] : [SOLVED] : maptk_track_features : vnl_matrix crashes : large datasets In-Reply-To: References: <569FE9DC.4010308@archlinux.info> Message-ID: Thanks. That was it. Just disabled the asserts. Seems like I was encountering the fringe cases on only the larger datasets so I figured it was related. Seems to have worked after turning off the asserts. Just documenting it here for future reference. Solution : Very low number of inliers caused some NaNs which can be turned off by turning off the asserts or just building vxl in release. Error wasn't because of the datasets being large. Sent from my iPhone > On Jan 20, 2016, at 2:51 PM, Matthew Leotta wrote: > > I don?t expect that this particular failure is a results of the dataset size. This is a failure within VXL. If recall correctly there are certain degenerate cases that will cause NaN or Inf values during homography estimation. This can happen during a RANSAC loop if the selected minimal correspondence subset hits one of these degeneracies. Given that this is RANSAC it shouldn?t be a big issue. The algorithm should just ignore that sample and move on to the next one. The problem is that there are checks deep within the vnl_matrix class that find this behavior very problematic and abort. Really VXL should be throwing an exception and the RANSAC algorithm should catch the exception. However, VXL does not make heavy use of exceptions. > > In short, this is a VXL bug. I can think of two short term fixes: > > 1) Build VXL in release mode, this should disable the asserts. I believe the VXL code will actually work in this case. > > 2) Use a different homography estimation algorithm. You could use the OpenCV plugin for homography estimation instead of VXL. > > Good luck, > Matt > > >> On Jan 20, 2016, at 3:11 PM, R. Pelapur wrote: >> >> While MapTk works well on smaller datasets (on the order of 200-300 frames with each frame around 6K x 4K) the homography estimation (i presume) is failing for larger datasets. One particular example is a crash on Frame # 423 (6K x 4K) : >> >> inlier ratio: 765/819 >> [INFO][maptk::compute_ref_homography_core] Inliers after estimation: 375 >> >> >> /vxl/core/vnl/vnl_matrix.txx: 1274: matrix has non-finite elements >> /vxl/core/vnl/vnl_matrix.txx: it is quite big (464x9) >> /vxl/core/vnl/vnl_matrix.txx: in the following picture '-' means finite and '*' means non-finite: >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> **----*** >> ---**-*** >> /vxl/core/vnl/vnl_matrix.txx: calling abort() >> >> I am currently debugging it to find how many inliers remained and to see if the frame has some kind of problem but any help in this regard would be helpful. >> >> Thanks, >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >