Request: Option to output incremental frames - useful for tracking

[stevenlovegrove]

For robotics / visual tracking, the ability to process input with low latency can save computation time and reduce perceptual aliasing, as well as improve closed loop reaction time. In this regard, a rolling shutter (such as that used by the Kinect RGB and IR camera) can offer an advantage.

It would be great if the libfreenect driver additionally offered access to the underlying image frame chunks for sequential processing.

[RichardNewcombe]

We need to find out if the data is processed and ready as a chunk or if the chunks are just from an internal buffer -- if the data is being processed and made available we have the possibility of a camera that gives us 960Hz data (assuming a chunk is 16 lines of depth data).

[marcan]

We could provide an interface that hands over the iso packets as they come in, after header parsing and considering streaming issues, but without actually memcpying the data out into the frame buffer, instead handing it straight to the user with an offset into the frame. The user would be responsible for data conversion in this case (demosaicing for RGB and unpacking for depth), as well as responsible for buffering previous data as needed by those algorithms.

However, I'm not entirely convinced that this is going to provide a significant enough benefit. Can you hack the codebase and perform an experiment to see whether the gain is significant? If you can show that this actually works in practice I'll be happy to include an interface for it into the official API.

[piedar]

Implemented in #351.