Read events in WAMI Viewer using frameworks; support KPF #65
Conversation
Create vvEvent; a simple type for conveying events along the lines of vvTrack. This will be used as the base data type for creating a frameworks event source. (Note that, despite the pedigree of the vvData library, this new type reflects a modern vision of events, and not the old fixed-vector event descriptors from days of yore, a la vvDescriptor.)
Create the base interface for a framework data source that provides events. Right now this is just the bare interface, with no supporting or implementing code.
Create new vdfEventReader class for synchronously reading events from a frameworks data source, much the same as vdfTrackReader does for tracks.
Rename vdfTrackOracleTrackArchiveSource.{cxx,h} to correctly match the
class name (vdfTrackOracleTrackDataSource).
Modify vdfTrackOracleArchiveSourcePlugin.cxx to use new brace style and modern (C++11) code constructs.
| { | ||
| const auto end = this->GetNumberOfTypes(); | ||
| for (decltype(+end) i = 0; i < end; ++i) | ||
| { |
There was a problem hiding this comment.
C:\Vision\DIVA\vivia\Libraries\VtkVgCore\vtkVgEventTypeRegistry.cxx(49): error C2105: '++' needs l-value
There was a problem hiding this comment.
Lovely. That's a Visual Studio bug. It's fixed in 19.23. Pathetically, it works all the way back in GCC 4.8.1.
Do I need to work around, or can we put VS 2017 out of our misery?
There was a problem hiding this comment.
Not my misery - my working building system, so not inclined to put it out of our misery, for this. The work around here is minor, given that this is new code - what is the argument against using the existing code?
| { | ||
| int result = 0; | ||
| const auto end = this->GetNumberOfTypes(); | ||
| for (decltype(+end) i = 0; i < end; ++i) |
There was a problem hiding this comment.
C:\Vision\DIVA\vivia\Libraries\VtkVgCore\vtkVgEventTypeRegistry.cxx(64): error C2105: '++' needs l-value
| const auto end = this->GetNumberOfTypes(); | ||
| for (decltype(+end) i = 0; i < end; ++i) | ||
| { | ||
| result = std::max(result, this->GetType(i).GetId()); |
There was a problem hiding this comment.
C:\Vision\DIVA\vivia\Libraries\VtkVgCore\vtkVgEventTypeRegistry.cxx(66): error C2039: 'max': is not a member of 'std'
There was a problem hiding this comment.
That's either a bug, or missing <algorithm>. Does #include <algorithm> fix it?
There was a problem hiding this comment.
Yes, adding #include <algorithm> does fix it.
|
|
||
| for (const auto& i : event.TrackIntervals) | ||
| { | ||
| if (!out.IsValid() || i.Stop < out) |
There was a problem hiding this comment.
Yeah, looks like a copy-paste "oops" (being otherwise identical to startTime).
|
|
||
| // Description: | ||
| // Get index of registered track type or -1 if not found. | ||
| int GetTypeIndex(const char* id) const; |
There was a problem hiding this comment.
nit, but id here and name in definition
There was a problem hiding this comment.
Oh, I see what happened; vgTrackType overloads GetId() to return the name (literally, the body of the method is return this->GetName()), while vgEventType has int GetId(). The definition, accordingly, had to switch to name/GetName(), but the declaration (i.e. this) got moved straight from vtkVgTrackTypeRegistry and missed the change.
Nice catch! Will fix it...
| for (int i = 0, end = this->GetNumberOfTypes(); i < end; ++i) | ||
| { | ||
| const auto end = this->GetNumberOfTypes(); | ||
| for (decltype(+end) i = 0; i < end; ++i) |
There was a problem hiding this comment.
c:\vision\diva\vivia\libraries\vtkvgcore\vtkVgTypeRegistry.h(70): error C2105: '++' needs l-value
| int vtkVgTypeRegistry<T>::GetTypeIndex(const char* name) const | ||
| { | ||
| const auto end = this->GetNumberOfTypes(); | ||
| for (decltype(+end) i = 0; i < end; ++i) |
There was a problem hiding this comment.
c:\vision\diva\vivia\libraries\vtkvgcore\vtkVgTypeRegistry.h(119): error C2105: '++' needs l-value
| for (size_t i = 0, end = this->Types.size(); i < end; ++i) | ||
| { | ||
| const auto end = this->Types.size(); | ||
| for (decltype(+end) i = 0; i < end; ++i) |
There was a problem hiding this comment.
c:\vision\diva\vivia\libraries\vtkvgcore\vtkVgTypeRegistry.h(166): error C2105: '++' needs l-value
Create a new frameworks data source that reads events using track_oracle. This is added to the existing track_oracle frameworks data source plugin. In theory, this is fully functional; however, nothing is using it yet, and (as of writing) track_oracle does not have any file formats that actually implement the required schema. For now, also disable the "generic" track_oracle formats, as our current mechanism for determining if we want a track source or an event source has no feasible way of making that distinction for these formats.
In preparation for eventually creating a track_oracle sink plugin (in addition to the source plugin) which will want to reuse some of the track_oracle helper code (in particular, the schema definitions), move these bits to a new vvTrackOracle library.
Move functions to look up type indices to vtkVgTypeRegistry from the derived classes vtkVgTrackTypeRegistry and vtkVgEventTypeRegistry. This makes the ability to look up an index from either the type ID or type name available to users of all registry types. (Previously, lookup by name was supported only for track types, and lookup by ID was supported only for event types, which made for a bizarre inconsistency.)
Remove an unreachable logic branch. Use QDebug instead of std::cout for logging.
Rename homography variables to not talk about "vidtk coordinates". While this is not completely incorrect, vidtk is using "image" coordinates (i.e. origin is top left, +Y is down), which are hardly unique to vidtk, even in the context of our homographies (as our data can come from other sources these days, which also tend to use image coordinates). Accordingly, replace "vidtk" with "image", so that we are using the more general (and arguably more accurate) terminology, and have one fewer spurious reference to a completely internal toolkit which we are slowly excising.
Improve our frameworks-based WAMI Viewer I/O subsystem to also support reading events. This closely reflects earlier work using the data frameworks to read tracks.
Modify the track_oracle format listing logic to accept readers that have either a time value or a frame number (and not necessarily both), rather than requiring a time value. Our own code already supported this, except that, prior to this change, we wouldn't even consider formats that don't at least potentially provide a time value. This should increase the number of formats we potentially support.
Update vdfTrackOracleTrackDataSource.cxx to use new code style and to make use of modern C++11 practices as appropriate. Also, remove support for Qt < 4.8; since we are using Qt5 these days, it is no longer needed.
Add a helper function to vpTrackIO to estimate the location of a track point from the bounding box, in case it is not available. Modify vpVdfTrackIO to use this as needed. Modify vdfTrackOracleTrackDataSource to set the track point to NaN when not available so that consumers (i.e. vpVdfTrackIO) can tell that it is not available. Note that "estimation", here, is just the "center" of the bounding box, which is how we have derived these points as needed since time immemorial. However, depending on the type of data, we sometimes use the "true" center, and sometimes the middle of the bottom edge. The helper function provides a QSettings-controlled mechanism for selecting which method is used (defaulting to "true" center).
Modify vdfDataReader::failed to not crash if no source is set. Modify vdfDataReader users (vpVdfTrackIO, vpVdfEventIO) to check for failure of vdfSDataReader::setSource. Historically, we expected failure to "never" happen, but it can happen if we try to use a reader that does not provide a required interface (e.g. an event source with a track reader).
Add additional logic to vdfSourceService and vdfTrackOracleArchiveSource to allow users to specify a list of desired interfaces for the source to be created, and to use this list as a hint when deciding what source to create. Modify users to take advantage of this functionality. This works around a track_oracle limitation where the track and event sources both equally believe they can read each other's files.
Refactor some loops to avoid a Visual Studio bug (that was fixed in 19.23, but Rusty really doesn't want to upgrade yet). In particular, the somewhat odd-looking construct `decltype(+end)` is intended to strip const-ness off the type (`end` is const) by performing an operation that changing the expression from a reference to a prvalue (via the builtin unary `+` operator), which should result in a non-const type. This works in every compiler which implements C++11 (or even mostly does so; hello, GCC 4.8!)... EXCEPT for Visual Studio prior to 19.23. The work-around is slightly more verbose, but also less esoteric, and conforms to AAA whereas the old code did not. Also, add a missing include for std::max.
mwoehlke-kitware
force-pushed
the
vdf-event-source
branch
from
671bb59 to
cb6d27e
Compare
2 participants
Add ability to read events using the ViViA data frameworks. Add ability to use this to read events in WAMI Viewer. Add a data frameworks plugin that can read events using KWIVER track_oracle.
I believe this depends on Kitware/kwiver#856.