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

[Matthew Leotta]

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 J.
>  
> 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 <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 <mailto: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 <mailto: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 <mailto:Kwiver-users at public.kitware.com>
> http://public.kitware.com/mailman/listinfo/kwiver-users <http://public.kitware.com/mailman/listinfo/kwiver-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/kwiver-users/attachments/20160201/a93fca55/attachment-0001.html>