Purpose of Delay objects

I am not clear why or how the user is going to use Delay objects (available in spec 1.0)
I get that they are like ring buffers. But I am still not clear what use a user would have of them. I’m also curious given that Delay objects are allowed to be written by multiple nodes in a graph. Would a delay object be automatically delayed after every write(s) by a node? If so, how would the user determine the order of the objects in the delay object? Also, couldn’t the user just create many virtual objects(e.g. n virtualimage objects) in an acyclic graph instead of creating a confusing cyclic graph with delay objects(containing the above n image objects).

Can someone please elaborate?

[QUOTE=tintiniitk;30823]I am not clear why or how the user is going to use Delay objects (available in spec 1.0)
I get that they are like ring buffers. But I am still not clear what use a user would have of them. I’m also curious given that Delay objects are allowed to be written by multiple nodes in a graph. Would a delay object be automatically delayed after every write(s) by a node? If so, how would the user determine the order of the objects in the delay object? Also, couldn’t the user just create many virtual objects(e.g. n virtualimage objects) in an acyclic graph instead of creating a confusing cyclic graph with delay objects(containing the above n image objects).

Can someone please elaborate?[/QUOTE]

One purpose of the delay node is to provide history to the graph without the user manually reconnecting objects, thus possibly causing the need for graph re-validations between executions. Some algos need to compute difference images from current and Nth previous images (depending on the algo and your tuning). Delays provide an abstract method of doing this.

Thanks Erik! So, now that I understand the purpose, there is the question of how i.e. how would a user use a Delay object?
In the current 40 kernel/function declarations, there is not a single Delay object parameter.
Is the user supposed to create a delay object and pass its various elements to successive nodes or are there going to be more kernels later which can read/write Delay objects as parameters. To me, the second makes more sense; the first just seems plain stupid.

To elaborate more on the delay subject:

> I am not clear why or how the user is going to use Delay objects (available in spec 1.0) I get that they are like ring buffers. But I am still not clear what use a user would have of them. I’m also curious given that Delay objects are allowed to be written by multiple nodes in a graph.

Only delay elements (or slots) are written by node, not the delay object as a whole. 2 different slots of the same delay objects can be written by different nodes in a graph.

> Would a delay object be automatically delayed after every write(s) by a node?

A delay object is not automatically delayed after each write (this is not a queue). The ‘aging’ of delays is controlled by the application with vxAgeDelay and the ‘slot’ of the delay that is read or written by a node is also controlled by the application (using vxGetReferenceFromDelay).

> If so, how would the user determine the order of the objects in the delay object?

About the ordering, each time the application ages the delay, the content of delay ‘slots’ is shifted. The content of slot 0 moves to slot -1, the content of slot -1 moves to slot -2, etc… A node that has been created with an image reference got from vxGetReferenceFromDelay will have its input automatically updated when the application ages the delay

> Also, couldn’t the user just create many virtual objects(e.g. n virtualimage objects) in an acyclic graph instead of creating a confusing cyclic graph with delay objects(containing the above n image objects).

You could replace a delay object by a set of virtual or real images and handle the aging manually by changing node parameters. But it would be much more work for you. Also, by changing nodes parameters, you take the risk of a graph re-verification since a parameter change of a node at the middle of a graph can be interpreted as a graph connectivity change.

[QUOTE=tintiniitk;30838]Thanks Erik! So, now that I understand the purpose, there is the question of how i.e. how would a user use a Delay object?
In the current 40 kernel/function declarations, there is not a single Delay object parameter.
Is the user supposed to create a delay object and pass its various elements to successive nodes or are there going to be more kernels later which can read/write Delay objects as parameters. To me, the second makes more sense; the first just seems plain stupid.[/QUOTE]

The delay object is a container, not a data object like an image. The since this API is C and that does not have overloading, we didn’t want to have to have multiple versions of the same Node API, one with Delays and the other with images/arrays, and/or combinations of Delays and other objects. This is just an issue of keeping the API simple and taylored to the language it’s in.

For OpenVX 1.0 (in C) the mechanism is to create a delay with an exemplar object, then get the time-delayed references, insert them in the correct parameters of the nodes you want and then verify/execute. Since you could use Age patterns of multiple types (N-1, N/2, etc) on different nodes (depending on frame rate, or other factors), the user should manually turn the crank on the delay aging. Future specs may add an aging semantic, but it may be nearly as complicated as just doing it yourself.