-
Notifications
You must be signed in to change notification settings - Fork 83
Frequently Asked Questions
This page is intended to be a landing pad for questions from new users of KWIVER and the associated answers. It also should provide guidance as to what areas of the documentation are not clear or prominent enough and need bolstering. Questions without a good answer might indicate areas where the infrastructure can be improved. As the questions are intended to be populated by novice users, more-experienced users should feel free to edit and make the language more precise.
A: No
A: If a process is relatively simple and the option of selecting different algorithms to accomplish the processing is not needed, the processing can be implemented completely within the process definition. If the process uses only native KWIVER components (i.e., Vital), then it should be implemented undersprokit/processes/core. If the process implementation draws upon an external library (e.g., OpenCV), then the process definition will residue within a different sub-directory under sprokit/processes.
A: The log output for components can be individually controlled from the log4cplus.properties file. At the bottom of the file there are some example entries that control the log level for a specific logging entity. I don't recall exactly how each process logger is named, but that should be in the logger output right after the timestamp.
Add a line that starts with "log4cplus.logger." followed by the process logger name, then append "=WARN" to limit the output to warnings or greater.
The logger names are hierarchical with components separated by a dot. The line in the file log4cplus.logger.vital=WARN sets all vital.* loggers to only display warnings or worse. The output level for specific loggers can be overridden by specifying a lower level in the hierarchy.
log4cplus.logger.vital.foo=DEBUG
If you are not using one of the recommended logger back ends, the build-in logger can have its level adjusted with an environment variable Set KWIVER_DEFAULT_LOG_LEVEL as such:
$ export KWIVER_DEFAULT_LOG_LEVEL=trace
$ export KWIVER_DEFAULT_LOG_LEVEL=debug
$ export KWIVER_DEFAULT_LOG_LEVEL=warn
A: The process pushing data onto an edge blocks until the edge regains available capacity. If _non_blocking is set, that process will dump that data until capacity regains.
Q: It seems that Sprokit just ignores config parameters that it can't identify what to do with them. Can Sprokit alert you when unexpected config values are encountered?
A: There are some config-diff classes that can be used to validate a config block against the supplied config. This cannot be done automatically because the the valid config for a process can't be determined because of the loadable algorithms. With the dynamic character of KIWVER, it is not possible to verify a config file against a config block when the file is being read.
A: plugin_explorer --process -d --config
Q: When a process accepts an input for trait image and outputs on trait image, does it use the same image port?
A: Input ports are different than output ports so they can share the same name.
A: The origin depends on the writer's last code base they worked on. For my tastes, the leading underscore is too easy to go unnoticed, so I prefer the d-> approach. IIRC, the processes have a different convention for the priv class. Also, using a PIMPL pattern is more of a convention rather than a requirement. There may be cases where that does not work well, such as when you are expecting a class to be a base class for derived classes. Hiding all internal operations in the PIMPL class usually makes derived classes impossible if you are trying to specialize.
Q: Sometimes I see attach_logger( kwiver::vital::get_logger( name() ) ) and other times the name is explicitly written. What is the guidance for setting the logger name?
A: The common case in arrows is optional nested algorithms. An example is here https://github.com/Kitware/kwiver/blob/master/arrows/core/match_features_homography.cxx "filter_features" is an optional nested algorithm
Q: If I want to turn off different components defined in a pipe, what is the best way to do that. For example, is there a group comment like /* */?
A: There are no group comments. Only shell style comments. Everything after the # is a comment.
A: We are working toward removing all use of boost in KWIVER. Instead use KWIVERSYS which comes with Vital. It is a copy of a Kitware standard library called KWSYS that is also used in CMake, VTK, etc. for cross platform system operations, including file paths.
A: When defining inputs with declare_input_port_using_trait, you cannot use the same trait on more than one input port. For convenience, a number of commonly used traits are defined in sprokit/processes/kwiver_type_traits.h, including one for an image with concrete C++ type kwiver::vital::image_container_sptr. If you include that header in your process, you can define two new traits,
create_port_trait( image1, image, "First image" );
create_port_trait( image2, image, "Second image" );
to use to accept two different images.
Q: Can I commit data files (e.g., images and videos) to the repository for use in testing and examples?
A: Testing data is always an issue. We generally don’t want to check in any videos or other large files. The code repository should stay small to keep git cloning times fast. One small image is okay. Also, if the unit test will run on the dashboard, we try to keep those small so they run in under 10 seconds or so.
There is value in longer tests on larger data too. We don’t have any infrastructure setup in KWIVER for that yet. We may create a separate repository for large data files that can be optionally checked out.