Skip to main content

Which part of the capture pipeline is the Chunk Data Timestamp based off?

Answered

Comments

3 comments

  • Official comment
    TDY_Demos
    Community team
    Expert (Gold)

    Hello Raymond,

    If you are seeing such long latency, it is likely on the driver/software side, to get the buffer into user level, converted to BGRU, and then displayed.

    The chunk data timestamp is the camera timestamp at the end of exposure.  Note though that this is not the same as PC timestamp, so to see "latency", I would read the TimestampLatchValue after you get your image to get the current "camera time", then you can see an approximate delay from end of exposure to having the data.

    More details on the TimestampLatchValue can be found in our manual at Device Control - BFS-U3-16S2 Version 1707.0.125.0 (flir.com).

    If you are using NewestOnly, and you are sitting in a blocking grab call, you should get your image as soon as the image is complete in memory.  I suggest to read the timestamp at that point to verify how much of the delay is post-image grab.

    Thank you,

    Demos

  • TDY_Demos
    Community team
    Expert (Gold)

    Hello Raymond.  I am just following up to see if the above feedback helped, or if you still have open questions about any unaccounted latency in your testing.

    Thanks,
    Demos

    0
  • r.castillo

    Hello Demos,

    Yes it did. Our measurements match your description. We believe that the 80 milliseconds delay that we are seeing is from the rendering side. Our configuration uses Linux and are using X11 and OpenGL to display the images. We have performance measurements on the OpenGL calls but it's hard to measure how long does an image takes to be displayed on screen after swapping buffers. Please let us know if you have any solutions on lowering display latency.

    Thank you,

    Raymond

    0

Please sign in to leave a comment.

Powered by Zendesk