[Viame] VIAME build error

Linus Sherrill linus.sherrill at kitware.com
Tue Sep 6 19:12:46 EDT 2016


David,

I missed answering item number 3, but Matt addressed it in his reply.

3)      I assume my code will be used as “plugin”, and VIAME has a
sub-folder. I have used python as APIs to wrap around a bunch of lower
level c++ libraries.
Our intent is to present your "plugin" as one or more loadable algorithm
instances or, less desirably, processes. I'm sure we will need to extend
our set of algorithm interfaces to handle new requirements.


On Tue, Sep 6, 2016 at 7:06 PM, Matt Dawkins <matt.dawkins at kitware.com>
wrote:

> For item #1-3 while there is currently no python object_detector base
> class, you can still write a python sprokit process which takes in an image
> and processes it (an example is in packages/kwiver/sprokit/processes/python).
> The plugins folder is indeed where we intend for each group to put their
> modules, with each one having an enable flag in the above cmake to turn the
> module on and off. External projects (e.g. other gitlab projects) can be
> added to the packages directory, as a git submodule, or by downloading the
> package if not using git (there is a DownloadFile cmake macro in the repo).
>
> As of today (5 minutes ago in master) there is a VIAME_ENABLE_PYTHON and
> VIAME_ENABLE_DOCS flag that can be set in the repo. VIAME_ENABLE_PYTHON
> will build the Caffe and KWIVER/Sprokit python interfaces.
>
> Also there is now a setup_viame.sh script instead of a setup_KWIVER.sh in
> latest master in the installation dir, that will set the appropriate paths
> to run things on linux/mac.
>
> For items #4-5, if you want to disable all GPU support (in OpenCV, Caffe,
> KWIVER), you can set VIAME_DISABLE_GPU_SUPPORT to ON. If you want to set
> manual caffe build settings, you need to go down into
> [build/src/fletch-build/build/src/Caffe-build] and run "ccmake ." and
> then "make install". The current caffe version is from BLVC, just a
> slightly dated master (a couple months). If the current master supports the
> latest cuDNN we can update. Alternatively we can add an advanced higher
> level VIAME build flag that disables cuDNN support.
>
>
> On Tue, Sep 6, 2016 at 6:10 PM, Linus Sherrill <linus.sherrill at kitware.com
> > wrote:
>
>> David,
>>
>> I will address items 1, 2, 3 and leave the others for Matt.
>>
>> 1) We have Python bindings for some classes, but we have not yet had the
>> time to wrap the image detection related classes.
>>
>> 2) One way to test the system is to see if you can run a pipelined
>> application. There are some environment variables that need to be set up
>> before you can run. Most of these are set up by the install/setup_KWIVER.sh
>> script.
>> You will need to manually set SPROKIT_MODULE_PATH to point to the
>> VIAME/build/install/lib/sprokit directory. I hope to add this to the
>> setup script soon.
>>
>> A good initial test is to run the VIAME/build/bin/plugin_explorer
>> program. It will generate a prodigious number of log messages and then list
>> all the loadable algorithms. The output should look as follows:
>>
>> ---- Algorithm search path
>> /disk2/projects/NOAA/VIAME/build/install/lib/modules:
>>
>> ---- Registered module names:
>>    kwiver_algo_matlab_plugin
>>    kwiver_algo_ocv_plugin
>>    kwiver_algo_plugin
>>    kwiver_algo_vxl_plugin
>>    viame_scallop_tk_plugin
>>
>> ---- registered algorithms (type_name:impl_name)
>>    analyze_tracks:ocv
>>    bundle_adjust:hierarchical
>>    bundle_adjust:vxl
>>    close_loops:bad_frames_only
>>    close_loops:exhaustive
>>    close_loops:keyframe
>>    close_loops:multi_method
>>    close_loops:vxl_homography_guided
>>    compute_ref_homography:core
>>    convert_image:bypass
>>    detect_features:ocv_BRISK
>>    detect_features:ocv_FAST
>>    detect_features:ocv_GFTT
>>    detect_features:ocv_MSER
>>    detect_features:ocv_ORB
>>    detect_features:ocv_SIFT
>>    detect_features:ocv_STAR
>>    detect_features:ocv_SURF
>>    detect_features:ocv_simple_blob
>>    draw_tracks:ocv
>>    estimate_canonical_transform:core_pca
>>    estimate_canonical_transform:vxl_plane
>>    estimate_essential_matrix:vxl
>>    estimate_fundamental_matrix:ocv
>>    estimate_fundamental_matrix:vxl
>>    estimate_homography:ocv
>>    estimate_homography:vxl
>>    estimate_similarity_transform:vxl
>>    extract_descriptors:ocv_BRIEF
>>    extract_descriptors:ocv_BRISK
>>    extract_descriptors:ocv_FREAK
>>    extract_descriptors:ocv_ORB
>>    extract_descriptors:ocv_SIFT
>>    extract_descriptors:ocv_SURF
>>    filter_features:magnitude
>>    image_filter:matlab
>>    image_io:ocv
>>    image_io:vxl
>>    image_object_detector:hough_circle_detector
>>    image_object_detector:matlab
>>    image_object_detector:scallop_tk_detector
>>    initialize_cameras_landmarks:core
>>    match_features:fundamental_matrix_guided
>>    match_features:homography_guided
>>    match_features:ocv_brute_force
>>    match_features:ocv_flann_based
>>    match_features:vxl_constrained
>>    optimize_cameras:vxl
>>    track_features:core
>>    triangulate_landmarks:core
>>    triangulate_landmarks:vxl
>>    video_input:vxl
>>
>> These loadable algorithms are located using the KWIVER_PLUGIN_PATH which
>> is listed in the output. The modules loaded list represent the shared
>> objects that have been detected and loaded. Each shared object can contain
>> multiple algorithms. The algorithm list shows each concrete algorithm that
>> could be loaded. Check the log messages to see if there are any libraries
>> that could not be located.
>> The highlighted loadable algorithms are the sample detectors and matlab
>> support. You should see these in your output.
>> If you don't see the matlab entries, check to see if the Matlab libraries
>> are in your LD_LIBRARY_PATH.
>>
>> Each algorithm listed consists of two names. The first name is the type
>> of algorithm and the second is the actual implementation type. For example
>> the entry image_object_detector:hough_circle_detector
>> indicates that it implements the image_object_detector interface and it
>> is a hough_circle_detector.
>>
>> Algorithms can be instantiated in any program and use a configuration
>> based approach to select which concrete implementation to instantiate.
>>
>> The next thing to check is to verify the process loading environment by
>> running VIAME/install/bin/processopedia. This program will search for
>> and load sprokit processes.
>>
>> The output should appear as follows (omitting the log messages)
>>
>> collate: Collates data from multiple worker processes
>> compute_homography: Compute a frame to frame homography based on tracks
>> detect_features: Detect features in an image that will be used for
>> stabilization
>> distribute: Distributes data to multiple worker processes
>> draw_detected_object_boxes: Draw detected object boxes on images.
>> draw_tracks: Draw feature tracks on image
>> extract_descriptors: Extract descriptors from detected features
>> feature_matcher: Match extracted descriptors and detected features
>> frame_list_input: Reads a list of image file names and generates stream
>> of images and associated time stamps
>> image_filter: Apply selected image filter algorithm to incoming images.
>> image_object_detector: Apply selected image object detector algorithm to
>> incoming images.
>> image_viewer: Display input image and delay
>> image_writer: Write image to disk.
>> input_adapter: Source process for pipeline. Pushes data items into
>> pipeline ports.
>> kw_archive_writer: Write kw archives
>> matlab_bridge: Bridge to process written in Matlab
>> output_adapter: Sink process for pipeline. Accepts data items from
>> pipeline ports.
>> pass: Pass a data stream through
>> read_d_vector: Read vector of doubles
>> sink: Ignores incoming data
>> stabilize_image: Generate current-to-reference image homographies
>> template: Description of process. Make as long as necessary to fully
>> explain what the process does and how to use it. Explain specific
>> algorithms used, etc.
>> view_image: Display input image and delay. Legacy process and will be
>> removed in a future release. Convert to use "image_viewer" before it is too
>> late.
>>
>>
>> The highlighted process types should be in your list. The program has
>> other options, so feel free to experiment.
>>
>> We will be using the image_object_detector process type in a pipeline to
>> apply a detector to a stream of images. This process wraps the
>> image_object_detector  algorithm interface in a process. The process can
>> be configured to instantiate any available detector implementation.
>>
>> For a simple pipeline test, go to -
>>
>> $ cd VIAME/source/packages/kwiver/sprokit/pipelines/examples/houg
>> h_detector
>>
>> Unfortunately there are some minor problems that have to be fixed before
>> this example can be run. This patch is in the process of being included in
>> the master version, but for now, apply the following patch.
>>
>> diff --git a/sprokit/pipelines/examples/hough_detector/detect_circles_list.txt
>> b/sprokit/pipelines/examples/hough_detector/detect_circles_list.txt
>> index 177599c..3a6005e 100644
>> --- a/sprokit/pipelines/examples/hough_detector/detect_circles_list.txt
>> +++ b/sprokit/pipelines/examples/hough_detector/detect_circles_list.txt
>> @@ -1 +1 @@
>> -images/detect_circles_soda.jpg
>> +detect_circles_soda.jpg
>> diff --git a/sprokit/pipelines/examples/hough_detector/hough_detector.pipe
>> b/sprokit/pipelines/examples/hough_detector/hough_detector.pipe
>> index f757e80..58d6d7b 100644
>> --- a/sprokit/pipelines/examples/hough_detector/hough_detector.pipe
>> +++ b/sprokit/pipelines/examples/hough_detector/hough_detector.pipe
>> @@ -1,8 +1,7 @@
>>  # ================================================================
>>  process input
>>    :: frame_list_input
>> -  #:image_list_file    images/image_list_1.txt
>> -  :image_list_file    images/detect_circles_list.txt
>> +  :image_list_file    detect_circles_list.txt
>>    :frame_time          .3333
>>    :image_reader:type   ocv
>>
>> This patch just removes the directory name from the image file and image
>> list file.
>>
>> In that directory, run the following command (or look at run_pipe.sh)
>>
>> $ pipeline_runner -p hough_detector.pipe
>>
>> The results should be an image displayed with a box around each can end.
>>
>> This is a good checkout of the underlying components.
>>
>> Let me know if you have any problems.
>>
>> -Linus
>>
>>
>> On Tue, Sep 6, 2016 at 4:14 PM, David Zhang <david.zhang at sri.com> wrote:
>>
>>> Matt and Linus:
>>>
>>>
>>>
>>> First of all, thanks for all the emails. I had a successful build today
>>> based on the latest version. This is good news. Next are the few questions
>>> to move on:
>>>
>>>
>>>
>>> 1)      Is the build so far work for both c++ and python?
>>>
>>> 2)      What test codes can I run to reflect my build?
>>>
>>> 3)      I assume my code will be used as “plugin”, and VIAME has a
>>> sub-folder. I have used python as APIs to wrap around a bunch of lower
>>> level c++ libraries.
>>>
>>> 4)      How do I change caffe settings from cmake? For example, to
>>> disable cuDNN, disable GPU, etc.
>>>
>>> 5)      We start to build VIAME on a desktop with Nvidia GPU K20. It
>>> has Cuda SDK 7.5 and CuDNN 5.05 installed. So far, the build was broken in
>>> caffe that complains about cuDNN type definitions. (I did not build caffe
>>> with cuDNN on my laptop). What is the caffe version you are using in the
>>> build? Is it from BLVC /caffe?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> David
>>>
>>
>> --
>> *Linus Sherrill - *Staff R&D Engineer
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065-8662
>> E: linus.sherrill at kitware.com
>> P: 518.881.4400
>>
>
>
>
> --
> Matthew Dawkins
> 1-518-881-4416
> Senior R&D Engineer
> Kitware, Inc
>



-- 
*Linus Sherrill - *Staff R&D Engineer
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065-8662
E: linus.sherrill at kitware.com
P: 518.881.4400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/viame/attachments/20160906/bda3e765/attachment-0001.html>


More information about the Viame mailing list