[Kwiver-users] maptk_bundle_adjust_tracks and Vital Boost Filesystem Replacement Issues

[Kyle.Brooks at L-3Com.com]

Matt,

The images loaded fine for maptk_track_features but it used OpenCV, image_reader:type = ocv.  I changed the analyze configuration to do the same and it works now, thanks for the suggestion.

Thanks,
Kyle

From: Matthew Leotta [mailto:matt.leotta at kitware.com] 
Sent: Monday, February 01, 2016 1:30 PM
To: Brooks, Kyle @ ESG - ISS - CIN
Cc: kwiver-users at public.kitware.com; Puchala, Joseph @ ESG - ISS - CIN; Marin-McGee, Maider @ ESG - ISS - CIN; Dapore, Alex @ ESG - ISS - CIN
Subject: Re: [Kwiver-users] maptk_bundle_adjust_tracks and Vital Boost Filesystem Replacement Issues

Kyle,

I don’t have a solution off hand.  What file format are your images?  Did these same images load without complaint when you ran maptk_track_features?  Did your config file for maptk_track_features use OpenCV (ocv) to load the images instead of VXL?  You could try to use OpenCV to load the images in maptk_analyze_tracks, but that’s more of a workaround than a fix for the problem at hand.

—Matt


On Feb 1, 2016, at 12:42 PM, Kyle.Brooks at L-3Com.com wrote:

Thanks Matt,
 
I am also having issues with a segmentation fault in maptk_analyze_tracks, here is the backtrace:
 
maptk_analyze_tracks_debug [C/C++ Application]         
                maptk_analyze_tracks [8098] [cores: 2]
                                Thread [1] 8098 [core: 2] (Suspended : Signal : SIGSEGV:Segmentation fault)      
                                                kwiver::maptk::vxl::image_io::load_(std::string const&) const at 0x7fffdc98f4e4               
                                                kwiver::vital::algo::image_io::load(std::string const&) const at 0x7ffff74a9725    
                                                maptk_main() at analyze_tracks.cxx:347 0x40dfc4           
                                                main() at analyze_tracks.cxx:364 0x40eb99         
                gdb
 
It happens when it tries to load the first image in our input to generate the features images at this line in analyze_tracks.cxx:364:
 
kwiver::vital::image_container_sptr image = image_reader->load( image_paths[i] );
 
I checked and the paths in the image_paths vector look correct and are sorted.  I don’t have a debug version of libvital or vxl install so I don’t have the symbols to dige down beyond Map-TK.
 
I can build and install a debug version of VXL and Vital if we need it but I’m hoping you have another quick fix for this on too ☺.
 
Thanks,
Kyle
 
From: Matthew Leotta [mailto:matt.leotta at kitware.com] 
Sent: Monday, February 01, 2016 11:51 AM
To: Brooks, Kyle @ ESG - ISS - CIN
Cc: kwiver-users at public.kitware.com; Puchala, Joseph @ ESG - ISS - CIN; Marin-McGee, Maider @ ESG - ISS - CIN
Subject: Re: [Kwiver-users] maptk_bundle_adjust_tracks and Vital Boost Filesystem Replacement Issues
 
Kyle,
 
Yes, you are absolutely correct.  Thank you for reporting this issue.  This is a bug that was introduced as part of the conversion to use Vital.  We actually just discovered this bug a couple of weeks ago and made a fix in our internal development branch that is pending public release approval.  I had forgotten that this bug might also affect the public master branch.  I have rebased our internal fix and pushed it to Github.  The pull request is here:
 
https://github.com/Kitware/maptk/pull/135
 
I will merge this after the continuous integration tests pass.
 
—Matt
 
  
On Feb 1, 2016, at 11:20 AM, Kyle.Brooks at L-3Com.com wrote:
 
Hello,

When I run maptk_bundle_adjust_tracks I get this error message:

loading track file: clif_tracks.txt
loaded 251400 tracks
filtered down to 93717 long tracks
track filtering: 0.200000 sec CPU, 0.193117 sec wall
loading POS files
ERROR: No POS files from input set match input image frames. Check POS files!
Initializing cameras from POS files: 0.000000 sec CPU, 0.005963 sec wall
ERROR: Failed to load input cameras

An older version of Map-TK which was used for the CVPR 2015 tutorial did not have this issue.  I debugged the issue and I believe I tracked it down to this commit:

commit 22dcab9722c26ce299d7247bec9853d36709b497
Author: Linus Sherrill <linus.sherrill at kitware.com>
Date:   Mon Sep 14 12:35:49 2015 -0400

   Convert to use new vital without boost

   Convert use of boost file path to vital::path_t
   Use kwiversys support to replace boost file system calls

It looks like the intent of this commit was to replace boost::filesystem::path::stem() which returns the filename without the path or last extension with kwiver::SystemTools::GetFilenameWithoutExtension() which does a similar function but instead replaced it with kwiver::SystemTools::GetFilenamePath() which returns the path of the folder that contains the file but not the filename itself.  Is this correct?

I am going to attempt replacing the calls to kwiver::SystemTools::GetFilenamePath() with kwiver::SystemTools::GetFilenameWithoutExtension () and see if this fixes the issue.

Thanks,

Kyle Brooks, Member of the Technical Staff
L-3 Cincinnati Electronics
_______________________________________________
Kwiver-users mailing list
Kwiver-users at public.kitware.com
http://public.kitware.com/mailman/listinfo/kwiver-users