Video/object track aggregation event #4
Conversation
Address review feedback
Addressed Bosch feedback
… scenes Added recommendation to enable object track data for sparsely crowded scenes
| <listitem> | ||
| <para> Final aggregation when the object is no longer visible in the field of view. </para> | ||
| </listitem> | ||
| </itemizedlist> |
There was a problem hiding this comment.
We think it would be beneficial to add more context describing this feature.
Things to consider are:
- Description of the general feature and how it relates to the scene description data described in, 5 Scene Description.
- Description of intended use.
- Describe limitations
- Give examples, some of interest are
- Given a set of scene description frames what is a possible ObjectTrackAggregation event
- Given a set of "unfiltered" and a set of rule parameters what is the expected output of "filtered" ObjectTrackAggregation events.
We are not sure if this is the correct place to add it given how other rules are described in Appendix A, but we suggest to make room for it in the specification.
As an example we could minimally add something like here:
<para>
Object track aggregation can be used as an alternative to the scene description. <Insert description of what it is and how it can be used as an alternative to the scene description>. Benefits can include reduction of transferred data and spending less resources aggregating data in the client.
</para>
There was a problem hiding this comment.
If you want to push this further can you please prepare the minimal example by resolving the <Insert description..> part?
As for the other parts, since you are not sure what is the correct place, I suggest not doing that now. If you have important details in the other parts, such as a limitation, it can be added to the minimal suggestion.
There was a problem hiding this comment.
In general I think this feature is unclear in its scope and intention. I have not been part in formulating this feature and I can not guess the thought process or intentions of those who did. Therefore I think it is better if someone involved with designing this feature as it currently stands tries to add some more context with above considerations. Don't you agree?
There was a problem hiding this comment.
Will propose to add the below text to the spec right at the start of the section
This event may be used to describe an object in the scene alternative or complementary to Scene description generated per frame by aggregating data collected per object for an object track. The process by which devices aggregate object track data for a given object is out of scope of this specification.
There was a problem hiding this comment.
Promised @dfahlen to generally comment on these: ( the comments shall not be added to the standard)
-
Description of the general feature and how it relates to the scene description data described in, 5 Scene Description.
Object track aggregation can be used as an alternative to the scene description. The object track contain an object appearance aggregated and consolidated over all frames that can be used in forensic search. An image can be provided to of the object to be used for subsequent automated analysis or manual operator verification on the client. Benefits can also include reduction of transferred data and spending less resources aggregating data in the client.
Scene description datatypes are reused but describe general appearance features rather than per frame appearance. -
Description of intended use.
Main use case is forensic search. See above. -
Describe limitations
When consolidating a track details are lost. Selected details can be offered by vendors in the object track attribute where needed.
There was a problem hiding this comment.
Could you describe in more detail what you mean by "object appearance aggregated and consolidated over all frames"? How does the data structure included in the ObjectTrack/Aggregation message support the representation this?
Additionally, tt:Object includes fields for more information than just visual feature of an object, such as bounding box, geo position, speed etc. Does those fields lack meaning in this context? If they have no clear interpretation this should be mentioned in the standard to avoid confusion.
| <para>It is recommended to enable ObjectTrack data in sparsely crowded scenes to optimize data produced from the device.</para> | ||
| <variablelist role="op"> | ||
| <varlistentry> | ||
| <term>Parameters</term> |
There was a problem hiding this comment.
Clarification of "A.1.2.1 Generic parameters" in https://www.onvif.org/specs/srv/analytics/ONVIF-Analytics-Service-Spec.pdf
It mentions some parameters for events defined in Appendex A. How should these be handled in the context of the Object Track aggregation rule.
- Is this a region based detection rule? I.e. should the field parameter be supported?
- Should this rule support the Armed parameter
There was a problem hiding this comment.
Ideally yes, region should be supported (not a MUST) otherwise we are opening up this event to include lot more objects if visible in scene, so its an additional filter like class to minimize what we send to client.
From PoC, we can say we did not have time to implement, let's see if WG objects to that.
Same for Armed, some rules even after creation needs an explict 'enable/disable' to actually trigger events and if our rules falls under such implementation pattern we may need to signal that support in options, for now we don't need to.
There was a problem hiding this comment.
If this is a region based rule this should be clarified as it is not obvious. In other "region based rules" e.g. "A.4 Loitering Detector" the field parameter has been explicitly added to the parameter list in "A.4 Loitering Detector".
If this is intended to support the armed this needs to be clarified as well. Also a general description of the workflow regarding armed/disarmed would be beneficial as it is not obvious what a client is expected to do with regards to the armed parameter.
Personally, I do not see a reason why the armed parameter is needed and I am not sure the region parameter is needed but that is besides the point. The point is that regardless of if the region and armed parameters should be included or not in the rule it sould al last be clear from the spec if they are or not.
Do you agree?
As a note: Neither "Filed" or "Armed" are currently supported in the PoC.
There was a problem hiding this comment.
Personally, I do not see a reason why the armed parameter is needed and I am not sure the region parameter is needed but that is besides the point. The point is that regardless of if the region and armed parameters should be included or not in the rule it sould al last be clear from the spec if they are or not.
This can be implementation dependent.
If vendor wants to provide client with additional option of configuring the field, they would respond the same in the GetRuleOptions for client to leverage such option in CreateRule.
If vendor implements the rule without any field support (missing field in GetRuleOptions) devices may trigger more events as its viewing more FOV.
For some rules having field explicitly, many of those specs are written years ago while the section "Generic parameters" section with field/armed is a bit newer update added to avoid adding field/armed into every new rule that gets included in the spec in future and hence also made 'rule should contain a parameter 'Field' ElementItem. ' (Note the should and not SHALL - to keep it open for vendor implementations/flavors)
| <variablelist role="op"> | ||
| <varlistentry> | ||
| <term>Parameters</term> | ||
| <listitem> |
There was a problem hiding this comment.
General comment:
It is not clear from reading the document what the meaning of mandatory/optional parameters in this context should be.
What is the interpretation of mandatory parameters?
mandatory to support by a device but optional for a user to set
or
mandatory to support by a device a and mandatory for a user to set
Similarly, what is the interpretation of optional parameters?
Mandatory for a device to support and optional for a user to set.
or
Optional to implement and optional for a user to set.
Given the text in 6.2.3.3 CreateRules
"The device shall accept adding of analytics rules with an empty Parameter definition"
The interpretation should probably be,
Mandatory - Mandatory for a device to support and optional for a user to set.
Optional - Optional to implement and optional for a user to set.
It may still be confusing when parameters that are optional support by a device specify default behavior. Does a device not supporting a specific parameter need to consider the default behavior or not? If not, it may be confusing that a device may function differently dependent on if an optional parameter is supported by the device or not.
This is exemplified by the similar comment regarding the parameter ReportTimeInterval.
It would be great to clarify this!
There was a problem hiding this comment.
Yes interpretation should be
- Mandatory - Mandatory for a device to support and optional for a user to set.
- Optional - Optional to implement and optional for a user to set.
This observation is true for Rule Parameters + payload description in spec.
There was a problem hiding this comment.
Do you agree this may be confusing? Do you think this can be clarified in the sepc?
There was a problem hiding this comment.
As a general guideline, ONVIF spec is always written from device perspective - unless explicitly stated otherwise.
-
So if parameter (in rule configuration) is mentioned as optional, its upto the device to support that option and hence optional for client to configure (subject to availability from device)
- Ref: 6.1.3.3 Occurence
- Configuration parameters may signal their allowed minimal occurrence using the minOccurs attribute. Setting the value to zero signals that the parameter is optional.
- Ref: 6.1.3.3 Occurence
-
So if a field in event payload is is mentioned as optional, its upto the device to include/exclude from the event payload.
| <para role="text">List of classes to be aggregated.</para> | ||
| <para role="param">ConfidenceLevel - optional [xs:float]</para> | ||
| <para role="text">Minimum confidence level of object classification for generating | ||
| aggregation event. </para> |
There was a problem hiding this comment.
If a class filter or confidence filter is used it is possible to get an Update event but no Final Event.
This makes it impossible for the user to distinguish between not ever receiving a final event and that the object is still in the scene.
Example:
Confidence Level = 0.5
Update event has {Human: 0.7} and is sent to the user.
Final event has {Human: 0.4 } and is not sent to the user.
When does the user know that the track is over?
There was a problem hiding this comment.
We need to add a clarification that says, irrespective of the filter - Final aggregation has to be sent when track ends, we can bring this up before 25.06.
There was a problem hiding this comment.
Ok, great, lets add this comment to the public pr.
There was a problem hiding this comment.
If an initial or intermediate aggregation is sent for an object, Final aggregation event for that object shall be sent even if final classification does not meet class or threshold filters in rule configuration.
update pushed into PR.
There was a problem hiding this comment.
We need to update the PoC to support this in order to follow updated spec.
| <para role="text">All aggregation events shall set object track start time as the | ||
| AggregationStart time. </para> | ||
| <para role="param">Object - mandatory [tt:Object]</para> | ||
| <para role="text">Track aggregation data of an object.</para> |
There was a problem hiding this comment.
How is this element intended to be interpreted and used?
tt:Object as described in "5.3.1 Objects" is intended to be used to describe the state of an object at a single point in time.
In this context the element description suggests that tt:Object should be used to describe an "aggregation" of data.
It is not clear from the description of the element nor the surrounding context what type of "aggregation" is to be expected. Furthermore since tt:Object was originally designed to describe the state of an object at a single point in time most of the elements in the data structure has no natural interpretation when representing some sort of "aggregate".
From this I am not convinced tt:Object is the correct data structure to use for the purpose of "aggregation".
Regardless of what data structure that is ultimately used, I think it needs to be further described what type of "aggregation" that is intended here as the word "aggregation" has a very broad interpretation and in isolation it does not describe the meaning or interpretation of some piece data.
There was a problem hiding this comment.
It is not clear from the description of the element nor the surrounding context what type of "aggregation" is to be expected.
- We tried to get into the details of what/how aggregation is and it did not fly enough and hence it is purposely left open to individual device capabilities of how thorough/compact/precise aggregation is done.
- Axis when implements on its products will have to explain what it means.
I am open to a recommendation/proposal text from you/team on the lines of "It is recommended to enable ObjectTrack data in sparsely crowded scenes to optimize data produced from the device." to explain what could be part of aggregation and we don't want want to get back to WG for details that they care less about.
Here is my proposal
- It is recommended that the methods by which devices construct and process object track aggregation data for a given object in a scene be left to the discretion of individual implementations.
There was a problem hiding this comment.
I also see it as a benefit of not locking down the the implementation details, in any large system not just onvif, since it allows us to change it using more advanced technology in the future. As long as the scope of the consolidation is known, time interval + object id + source/producer, it's sufficiently defined.
There was a problem hiding this comment.
I will collect all clarifications into a separate PR.
There was a problem hiding this comment.
I am not talking about implementation details. I am talking about the interface of this feature, that is not a detail nor is it technology dependent.
The tt:Object data structure is part of the interface. As that is the case it needs a clear interpretation and meaning. As I pointed out above I do not think it does as the original intention of the data structure is to represent the state of an object at a single point in time.
If tt:Object has no clear meaning that can be described in the standard I think it is better to leave it out and instead make clear that kind of data needs to be delivered as vendor extensions.
If we really want to standardize a data structure it needs a standard interpretation otherwise there is no point in standardizing it.
I am am asking for one of the following:
- Some effort to be put into describing what the interpretation of tt:Object should be in this context.
- If it is not possible to describe what the interpretation of tt:Object should be in this context, change the data structure into something that it is possible to describe the interpretation of.
- Remove tt:Object and make it clear that data of that kind is outside the scope of the standard and something that needs to be added as vendor extensions.
There was a problem hiding this comment.
Numerous discussions in WG did not yield much progress and tt:Object is the only option available for now, though we all know its not perfect, without that the whole event/feature has absolutely no base at all.
I don't see ONVIF inventing anything complementing tt:Object in near future (next 3-4 years)
In that context, I would say lets add more text about "interpretation of tt:Object should be in this context." in order to render what we did in last year little more meaningful.
There was a problem hiding this comment.
Proposed text
This event may be used to describe an object in the scene alternative or complementary to Scene description generated per frame by aggregating data collected per object for an object track. The process by which devices aggregate object track data for a given object is out of scope of this specification.
The Object Track Aggregation rule generates an object track aggregation event for below listed scenarios
Optionally, Initial aggregation after an object appears OR an Intermediate aggregation while the object is present in the field of view.
Final aggregation when the object is no longer visible in the field of view.
Optionally, device may include additional object track data for e.g. snapshot image as configured in ObjectTrackDataFilter parameter.
It is recommended to enable ObjectTrack data in sparsely crowded scenes to optimize data produced from the device.
There was a problem hiding this comment.
Ok, this is a start but I still think we need additional clarification.
The main issue is not that it is up to the vendor how "aggregation" is done, the specification does not need describe that. This is the same for other features. E.g. the standard describes how to represent the state of tracked object in a video frame with tt:Frame and tt:Object and how that data should be interpreted, but it says nothing about how the tracker should be implemented.
So, what is needed here is a description of how tt:Object should be interpreted in the context of "aggregation" not the process by which the aggregation is done by a vendor.
Additionally, the above suggested text mentions "object track". This is the first time in the standard that that term is used. I think it needs to be defined what "object track" mean in the context of the standard.
There was a problem hiding this comment.
A benchmark for a "good" description is that a human should be able to read the description on how the data should be represented and interpreted and then be able to annotate a video using that representation.
This way we can ensure representation is meaningful an possible to explain. It is also possible to develop benchmarks that measure how well a machine can perform the task by comparing the machine output to a human annotation.
doc/Analytics.xml
Outdated
| AggregationStart time. </para> | ||
| <para role="param">Object - mandatory [tt:Object]</para> | ||
| <para role="text">Track aggregation data of an object.</para> | ||
| <para role="param">ObjectTrack - optional, unbounded [tt:ObjectTrackData]</para> |
There was a problem hiding this comment.
We think having ObjectTrack element unbounded and with this definition of tt:ObjectTrackData
<xs:complexType name="ObjectTrackData">
<xs:complexContent>
<xs:extension base="tt:Object">
<xs:attribute name="CaptureTime" type="xs:dateTime"/>
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>is the wrong approach.
We suggest changing this line to:
| <para role="param">ObjectTrack - optional, unbounded [tt:ObjectTrackData]</para> | |
| <para role="param">ObjectTrack - optional [tt:ObjectTrack]</para> |
and adding a new type, tt:ObjectTrack, with the definition
<xs:complexType name="ObjectTrack">
<xs:sequence>
<xs:element name="Object" type="tt:ObjectTrackData" minOccurs="0"
</xs:sequence>
</xs:complexType>Regardless, of how the schema is structured our goal is to end up with a message that corresponds to this example:
<tt:MetadataStream xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:Event>
<wsnt:NotificationMessage ...>
...
<wsnt:Message>
<tt:Message UtcTime="2025-01-29T10:00:49.821306Z">
...
<tt:Data>
<tt:SimpleItem Name="Final" Value="1"/>
<tt:SimpleItem Name="AggregationStart" Value="2025-01-29T10:00:28.527782Z"/>
<tt:ElementItem Name="Object">
...
</tt:ElementItem>
<tt:ElementItem Name="ObjectTrack">
<tt:ObjectTrack>
<tt:Object CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45">
<tt:Appearance>
<tt:Shape>
<tt:BoundingBox bottom="0.82969999999999999" top="0.78600000000000003" right="0.69730000000000003" left="0.68300000000000005"/>
</tt:Shape>
</tt:Appearance>
</tt:Object>
<tt:Object CaptureTime="2025-01-29T10:00:28.627783Z" ObjectId="45">
<tt:Appearance>
<tt:Shape>
<tt:BoundingBox bottom="0.82809999999999995" top="0.77349999999999997" right="0.69640000000000002" left="0.68300000000000005"/>
</tt:Shape>
</tt:Appearance>
</tt:Object>
</tt:ObjectTrack>
</tt:ElementItem>
</tt:Data>
</tt:Message>
</wsnt:Message>
</wsnt:NotificationMessage>
</tt:Event>
</tt:MetadataStream>
There was a problem hiding this comment.
We had these discussions a few times earlier before we ended up with the current proposal and got WG approval and I would be quite hesitant to go back to do structural changes, unless what we have is incorrect.
There was a problem hiding this comment.
Can you given an example of the expected output with the proposal as it currently stands?
As it is currently formulated
ObjectTrack - optional, unbounded [tt:ObjectTrackData]
The "unbounded" and "optional", specifier is just an annotation to the "configuration description language" described in "6.1 Configuration description language".
It is unclear how this should be interpreted as there is no description of this anywhere we could find. A description of how "unbounded" and "optional" should be interpreted in this needs to be added somewhere or at least an example showing what it would look like.
Our suggestion was based on a desire to to keep the complexities of the schema in something that is formally defined. i.e. xml schema instead of the configuration description language "schema".
There was a problem hiding this comment.
<tt:Data>
<tt:ElementItem Name="ObjectTrack" CaptureTime="2025-01-27T10:57:41.587991Z">
<tt:Object>
<tt:Appearance>
<tt:Shape>
<tt:BoundingBox x="0.1" y="0.2" width="0.3" height="0.4"/>
<tt:Shape>
<tt:Appearance>
</tt:Object>
</tt:ElementItem>
<tt:ElementItem Name="ObjectTrack" CaptureTime="2025-01-27T10:57:42.587991Z">
<tt:Object>
<tt:Appearance>
<tt:Shape>
<tt:BoundingBox x="0.1" y="0.2" width="0.3" height="0.4"/>
<tt:Shape>
<tt:Appearance>
</tt:Object>
</tt:ElementItem>
</tt:Data>We can bring up for discussion for schema changes and may be we need to redo the PoC test with Genetec/Bosch, I am not sure, we can talk more in F2F.
There was a problem hiding this comment.
No additional changes done to schema, though not described clearly, there is a precedence of writing requirement like we did, its a textual explanation of XML. optional for element to be present or absent and unbounded relates to including multiple instances of that element.
AnalyticsModule – optional, unbounded [tan:MetadataInfo]
There was a problem hiding this comment.
I am no expert in XML Schema, but from how I understand it, the element name does matter regardless if the element type is extended or not.
Just to try it, I created a small dummy schema and validated some documents using it.
The schema was:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.onvif.org/ver10/schema"
xmlns:tt="http://www.onvif.org/ver10/schema"
elementFormDefault="qualified">
<xs:complexType name="Object">
<xs:attribute name="ObjectId" type="xs:integer" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
<xs:complexType name="ObjectState">
<xs:complexContent>
<xs:extension base="tt:Object">
<xs:attribute name="CaptureTime" type="xs:dateTime" />
<xs:anyAttribute processContents="lax" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ObjectTrack">
<xs:sequence>
<xs:element name="ObjectState" type="tt:ObjectState" minOccurs="1"
maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute processContents="lax" />
</xs:complexType>
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="ObjectTrack" type="tt:ObjectTrack" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>The first document was:
<tt:Root xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:ObjectTrack>
<tt:ObjectState CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
<tt:ObjectState CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
</tt:ObjectTrack>
</tt:Root>It validates OK.
The second document was:
<tt:Root xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:ObjectTrack>
<tt:Object CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
<tt:Object CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
</tt:ObjectTrack>
</tt:Root>And the validation returns this error:
cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://www.onvif.org/ver10/schema":Object}'. One of '{"http://www.onvif.org/ver10/schema":ObjectState}' is expected.
I used this online tool to test, https://www.liquid-technologies.com/online-xsd-validator
Am I correct that the element name does matter or did I get something wrong in the above example?
There was a problem hiding this comment.
I am not an expert too, Below instance is also passing validation even if attribute name is changed to 'Objectd' which is not what your example schema expects...?
<!-- Add XML Data -->
<tt:Root xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:ObjectTrack>
<tt:ObjectState CaptureTime="2025-01-29T10:00:28.527783Z" Objectd="45" />
<tt:ObjectState CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
</tt:ObjectTrack>
</tt:Root>There was a problem hiding this comment.
From what I read, some xml validators allow using the base type but more standard validators would need to have something like below if they cannot derive the implicit association based on schema.
<tt:Root xmlns:tt="http://www.onvif.org/ver10/schema">
<tt:ObjectTrack>
<tt:Object xsi:type="tt:ObjectState" CaptureTime="2025-01-29T10:00:28.527783Z" ObjectId="45" />
<tt:Object xsi:type="tt:ObjectState" CaptureTime="2025-01-29T10:00:30.123456Z" ObjectId="46" />
</tt:ObjectTrack>
</tt:Root>So I agree, sorry for the confusion, to avoid any such chance of failing validation, we will keep the structure we originally proposed.
There was a problem hiding this comment.
Objectrrack on the outside and objectstate inside will only add to more confusion unless we redefine track and state.objectrackdata seems generic enough in my opinion.
There was a problem hiding this comment.
I don't quite understand why it will add more confusion? What are the definitions of "track" and "state" that have been used in ONVIF so far?
The reasoning behind behind using object state is to make it more clear what the data represents. Form my perspective it is not just some generic data, is has has a specific meaning that should be made as clear as possible through the naming.
I would define object state and object track as follows.
ObjectState - The object state describes the condition or attributes of an object at a specific point in time. It typically includes properties such as, position, velocity, visual appearance features.
ObjectTrack - A track is a continuous sequence of object states, representing the changes in an object's state over some time period.
PR to facilitate an internal discussion with regards to "Video/object track aggregation event" PR in onvif/specs, targeting the official ONVIF repo.