What does camera.get_timestamp(sl.TIME_REFERENCE.IMAGE) represent on the ZedX cameras using a quad link capture card? I want to know, with the highest precision possible, when the end of the camera exposure occurred to properly calculate transforms and mask areas of the scene.
I’ve read Sensors Time Synchronization - Stereolabs and all the pages/posts on camera latency, but am still confused. Reading ZED Link Quad GPIO Triggering - Stereolabs “The output trigger signals are two square wave, with their rising edge synchronized with the end of the exposure phase of the CMOS sensors.” gives me optimism that the capture time can precisely be known. However, I’m unsure if that is exposed in the API or whether I need to create a setup involving the GPIO pins to know the exposure end time within a few milliseconds.
It’s the system time when the full sample has been received by the GMSL2 deserializer.
You can use this information to know the exact instant when the frame is ready.
The SDK cannot be aware of this information because there’s no link between the deserializer GPIO and the SDK.
The SDK cannot be aware of this information because there’s no link between the deserializer GPIO and the SDK.
Has there been any consideration around integrating this into the SDK? The setup I’m imagining is connecting the capture card GPIO pins to the Jetson’s GPIO pins. Would that allow for syncronizing the timestamps with the true exposure time? Is there any way to transmit this over the CSI port? Any information you can provide here is useful both in the context of potential future SDK features and just general knowledge as I may try to build this setup myself.
This is under investigation. I’m not sure it’s possible to send GPIO pin status over GMSL2 without introducing latency which will make this mechanism unuseful.
At 60FPS 1-2 frames of latency is 16-32ms of latency. At 30FPS 1-2 frames becomes 32-64ms of latency. It’s suspicious to me that a lower frame rate would result in a higher absolute latency.
This is under investigation. I’m not sure it’s possible to send GPIO pin status over GMSL2 without introducing latency which will make this mechanism unuseful.
I may be misunderstanding component names, but my goal isn’t to send anything over GMSL2. I want to connect the capture card pins to the Jetson’s GPIO pins. I would then poll on the Jetson for the voltage changes to get a more accurate timestamp. I’d pairwise match the nth frame capture to the timestamp of the nth voltage change.
Will the timestmap itself be delayed 1-2 frames on the image , or will the image be delivered -12 frames later but the timestamp is correct
Regading the 1-2 frame latency due to buffering - if its only buffreing then wehere does the stochasticity orginate from - int he sense that why is not not 1 frame
Overall given a timestamp of a image - is there anyway to back calculate the exact time the exposure ended for that image
Okay, in that case can you please clarify which of the following is the case with respcet to zed sdk
the image is timestampped at the moment it is captured (exposure time ends) but it is only avaible after 1-2 frmaes to be grabbed - essentially the timestamp is correct with repest to the image, and the overall frame (image + timestamp) is 1-2 frames stale/delayed
The image is timestamped after it is available in the memory. The image is avaible in memory only after the 1-2 frames. In that case the image timestamp is ahead of the actual time of capture of the image by 1-2 frames
Something else - If yes, please clarify how th efollwonig are realted to each other - a) end of exposure time (true image capture time) b) timestamp on the image c) when the frame is available to be grabbed
