none
Frame Number RRS feed

  • Question

  • Hi,

    Sorry if this is an obvious question but I couldn't find the answer. I am attempting to save the skeleton, the depth map and the RGB images out. When I look at the display it appears that I'm dropping frames, yet the file names (saved as 1.png, 2.png etc etc) are all consecutive (i.e. non-missing). They are named using the framenumber provided by the kinect. So my question is.....

    If an image is dropped from the buffer because I was too slow doing I/O, is the frame number still incremented or not?

    Or more specifically...

    If I name the saved files using the framenumber and this is consecutive for the entire sequence, i.e. no missing numbers, can I assume no files have been dropped?

    Thanks

    Ben

    Tuesday, September 20, 2011 4:10 PM

Answers

  • If you had dropped a frame, you would indeed see a gap in the number sequence. I'm guessing that you're writing data to file as part of main UI thread, so the I/O work is blocking the UI thread for a longer time than is ideal for a smooth UI refresh to happen.

    When you register for videoFrameReady, depthFrameReady and skeletonFrameReady events, they are sent to your main thread to be processed, and if you do a lot of work in response to them, then smoothness of UI will be compromised.

    Alternatively, you could not register for events and spin your own thread to do polling for depth, video and skeleton frames in the background, every 30 milliseconds or so, then asynchronously (non-blocking) post this data to the UI thread to refresh UI, while the background thread does the blocking file I/O.

    Hope this helps,
    Eddy


    I'm here to help
    Tuesday, September 20, 2011 5:50 PM

All replies

  • If you had dropped a frame, you would indeed see a gap in the number sequence. I'm guessing that you're writing data to file as part of main UI thread, so the I/O work is blocking the UI thread for a longer time than is ideal for a smooth UI refresh to happen.

    When you register for videoFrameReady, depthFrameReady and skeletonFrameReady events, they are sent to your main thread to be processed, and if you do a lot of work in response to them, then smoothness of UI will be compromised.

    Alternatively, you could not register for events and spin your own thread to do polling for depth, video and skeleton frames in the background, every 30 milliseconds or so, then asynchronously (non-blocking) post this data to the UI thread to refresh UI, while the background thread does the blocking file I/O.

    Hope this helps,
    Eddy


    I'm here to help
    Tuesday, September 20, 2011 5:50 PM
  • OK, thanks for your help.

    Cheers,

    Ben

    Wednesday, September 21, 2011 8:41 AM