From matt.brown at kitware.com Mon Sep 4 11:32:50 2017 From: matt.brown at kitware.com (Matt Brown) Date: Mon, 4 Sep 2017 11:32:50 -0400 Subject: [Kwiver-users] Testing Message-ID: Surveying the tests currently in KWIVER, I see a lot of tests in the arrows and tests of the generic functionality of Sprokit (i.e., sprokit/tests dir), but I don't really see any at the specific process level (e.g., under sprokit/processes/core or sprokit/processes/ocv). I suppose there isn't much to test in processes that mostly just dispatch to arrow(s). However, processes like 'processes/ocv' do all of the implementation within. Also, most of the test examples for arrows are able to synthesize a simple instantiation of the source data (e.g., a bounding box, a homography, ...) to run the tests. However, testing something like video stabilization really demands a sequence of test images. Is there any guidance on how to go about this, specifically what data to use? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Mon Sep 4 12:35:36 2017 From: matt.brown at kitware.com (Matt Brown) Date: Mon, 4 Sep 2017 12:35:36 -0400 Subject: [Kwiver-users] Testing In-Reply-To: References: Message-ID: I see that some of some of the core arrow tests point to arrows/core/tests/data/images, but the images there are all zero bytes. On Mon, Sep 4, 2017 at 11:32 AM, Matt Brown wrote: > Surveying the tests currently in KWIVER, I see a lot of tests in the > arrows and tests of the generic functionality of Sprokit (i.e., > sprokit/tests dir), but I don't really see any at the specific process > level (e.g., under sprokit/processes/core or sprokit/processes/ocv). I > suppose there isn't much to test in processes that mostly just dispatch to > arrow(s). However, processes like 'processes/ocv' do all of the > implementation within. > > Also, most of the test examples for arrows are able to synthesize a simple > instantiation of the source data (e.g., a bounding box, a homography, ...) > to run the tests. However, testing something like video stabilization > really demands a sequence of test images. Is there any guidance on how to > go about this, specifically what data to use? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Wed Sep 6 10:38:00 2017 From: matt.brown at kitware.com (Matt Brown) Date: Wed, 6 Sep 2017 10:38:00 -0400 Subject: [Kwiver-users] Save vital type to disk Message-ID: My current interest is in reading/writing a vital/homography from/to disk. Note, this is the simpler homography without other metadata in it (i.e., not homography_f2f). I would like to create a base class methods save_to_file and read_from_file, but I have a few questions: - Should this go in the base class or in homography_? - It seems to me that this might be a useful generic facility across all vital types, so maybe we should take a moment and consider what the member function names should be and their scope. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Sep 6 10:51:23 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 6 Sep 2017 10:51:23 -0400 Subject: [Kwiver-users] Save vital type to disk In-Reply-To: References: Message-ID: <2E178604-00A0-47D4-BCD3-8D98667A5DE1@kitware.com> I would not add any file I/O fuactions directly to the Vital type classes. You can add stream operators (that is, >> and <<) along side the type classes. I believe homography already has those. Currently we are putting file I/O functions in separate files in "kwiver/vital/io?. Look at camera_io.h as an example. These I/O functions should mostly just validate file object and then call the stream operators. > On Sep 6, 2017, at 10:38 AM, Matt Brown wrote: > > My current interest is in reading/writing a vital/homography from/to disk. Note, this is the simpler homography without other metadata in it (i.e., not homography_f2f). I would like to create a base class methods save_to_file and read_from_file, but I have a few questions: > > Should this go in the base class or in homography_? > It seems to me that this might be a useful generic facility across all vital types, so maybe we should take a moment and consider what the member function names should be and their scope. > _______________________________________________ > 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 linus.sherrill at kitware.com Wed Sep 6 12:51:45 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Wed, 6 Sep 2017 12:51:45 -0400 Subject: [Kwiver-users] Save vital type to disk In-Reply-To: <2E178604-00A0-47D4-BCD3-8D98667A5DE1@kitware.com> References: <2E178604-00A0-47D4-BCD3-8D98667A5DE1@kitware.com> Message-ID: I agree. File I/O is not a property of the object but an operation on the object. On Wed, Sep 6, 2017 at 10:51 AM, Matthew Leotta wrote: > I would not add any file I/O fu actions directly to the Vital type > classes. You can add stream operators (that is, >> and <<) along side the > type classes. I believe homography already has those. Currently we are > putting file I/O functions in separate files in "kwiver/vital/io?. Look at > camera_io.h as an example. These I/O functions should mostly just validate > file object and then call the stream operators. > > On Sep 6, 2017, at 10:38 AM, Matt Brown wrote: > > My current interest is in reading/writing a vital/homography from/to disk. > Note, this is the simpler homography without other metadata in it (i.e., > not homography_f2f). I would like to create a base class methods > save_to_file and read_from_file, but I have a few questions: > > > - Should this go in the base class or in homography_? > - It seems to me that this might be a useful generic facility across > all vital types, so maybe we should take a moment and consider what the > member function names should be and their scope. > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *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: From matt.brown at kitware.com Fri Sep 8 10:44:17 2017 From: matt.brown at kitware.com (Matt Brown) Date: Fri, 8 Sep 2017 10:44:17 -0400 Subject: [Kwiver-users] Building Fletch/KWIVER on a Jetson TX1 with ARM processor Message-ID: I am trying to build Fletch/KWIVER on a Jetson TX1 running Ubuntu 16.04.3. I am running into troubles with Boost. The Fletch-provided Boost 1.55 runs into c++: error: unrecognized command line option ?-m64? errors when compiling, presumably due to the ARM processor. If I use a newer pre-built version of Boost, I run into this https://stackoverflow.com/questions/25395805/compile-error-with-boost-graph-1-56-0-and-g-4-6-4. I tried building from the standard release of Boost 1.55, but libboost_thread.so doesn't build properly. I am documenting my troubles here: https://docs.google.com/document/d/1Gq9aJI_PToAUOgbX1ABR5ZRJ08cXKnqI5RgrsALXHbc/edit?usp=sharing under Fletch Build Issues. Anyone have any advice? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Fri Sep 22 17:43:08 2017 From: matt.brown at kitware.com (Matt Brown) Date: Fri, 22 Sep 2017 17:43:08 -0400 Subject: [Kwiver-users] Python processes Message-ID: Does anyone know the status of the current functionality of launching a Python process with Sprokit? I am interested in making a histogram display with Python. I used the Pyhton example ProcessImage, but got the following: There is no such process of type 'ProcessImage' in the registry I made sure that it was built with KWIVER_ENABLE_PYTHON set to ON. Also, what should we do about naming Python processes in the registry? Should we prepend something to distinguish it? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Fri Sep 22 18:02:23 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Fri, 22 Sep 2017 18:02:23 -0400 Subject: [Kwiver-users] Python processes In-Reply-To: References: Message-ID: All registered processes can be listed with the plugin explorer. Those written in python have the attribute "_python" displayed so there is no need for a special naming convention. Python processes register themselves with a "__sprokit_register__()" function at the end of the source file. If the process is not in the registry, it could be that it was not installed or the installed location is not being searched. --Linus On Fri, Sep 22, 2017 at 5:43 PM, Matt Brown wrote: > Does anyone know the status of the current functionality of launching a > Python process with Sprokit? I am interested in making a histogram display > with Python. I used the Pyhton example ProcessImage, but got the following: > > There is no such process of type 'ProcessImage' in the registry > > I made sure that it was built with KWIVER_ENABLE_PYTHON set to ON. > > Also, what should we do about naming Python processes in the registry? > Should we prepend something to distinguish it? > > Thanks, > Matt > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *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: