fujiisoup
Understanding the metadata from SIF file
Hi,
After importing and opening the SIF file using this 'sif_parser', I want to acquire the timestamps, but in the Fast Kinetics Mode, the timestamps are recorded as 0. But there are a few raw data which is recorded as shown below:
I need to confirm that these raw data numbers correspond to the timestamps of the frames acquired. Can you help me with this?
Sincerely, Sabyasachi
Just to not confuse you the file I sent is different from the image though :).
Hi @sabyasachiph
The number in 'tile' attribute is not the timestamp. This is the location of particular frame in the file.
Unfortunately, the time stamp of each frame is not stored in the sif file. Probably because in the fast kinetic mode, there are no well-defined 'time' of the exposure (this is my guess).
What accuracy do you need? There is 'CycleTime' attribute. In this case, 36.2 us. Can we use this cycle time as the time stamp? For the overall experiment time is stored as 'ExperimentTime' (with the accuracy of second), where we can read
>>> np.datetime64(info['ExperimentTime'], 's')
numpy.datetime64('2024-03-14T11:29:56')
Hi @fujiisoup,
Thank you for looking this up. That's quite unfortunate that timestamps are not recorded in the fast kinetics mode.
If I understand you correct, the accuracy for the timstamps that I need is in 10s of microseconds.
If I use the cycle time to back calculate the timestamps, that would be under the assumption that each of these frames are equally spaced in time. But do you think this is a reasonable assumption?
If I use the cycle time to back calculate the timestamps, that would be under the assumption that each of these frames are equally spaced in time. But do you think this is a reasonable assumption?
I think so. A vertical shift in the CCD is driven by an internal clock, which is usually very precise. If you just need a relative timestamp from the first frame, I think the CycleTime * n would be precise enough.
I see. So that should also imply that the readout is equally spaced I guess?
Yes, the readout time is usually equally spaced (you can specify the readout speed in the SOLIS software). But I believe in the fast kinetic mode, the readout is done after all the exposure is completed. So we may care only the vertical shifting speed for this case.
Hi @fujiisoup,
I am still confused as to why the cycle time is 36.2 us. My exposure time was 10 us and the vertical shift time was 0.6 us.
So, shouldn't the cycle time be (exposure time + vertical shift time) 10+0.6 = 10.6 us. Do you know from where this extra 25.6 us comes? My first guess would be the readout time associated with each frame, but I am not sure.
Would be nice to have your input on it.
Best, Sabyasachi
The vertical shift time is the time to shift charges for 1 pixel. As you have 8-pixel height for each image, (10 + 0.6 * 8) = 14.8 us is the number I would expect for your setting. Are you sure the vertical shift time of 0.6 us? (it seems this is the fastest setting, but you can change in SOLIS).
Since the maximum readout rate of the camera is 30MHz, reading 1 frame (1024x8 pixels) requires 273us. The camera is not reading out the image during the series of exposures.
I guess then I don't completely understand what exactly cycle time refer to. I thought it referred to the rate at which each frame is acquired as depicted in the figure below:
Do you think this is a correct representation?
Yes, this is exactly how I understood. Then weird. I tried to open your file with Andor SOLIS, and it does not state anything about the cycle time, but only the exposure time and vertical shift time.
Another file that was taken in Kinetics mode shows the cycle time.
My current guess is that the CycleTime does not have meanings for the fast kinetics mode, and we may need to consider the exposure time and vertical shift time to derive the actual "CycleTime"?
Is it possible for you to do some experiments with different exposure time, and vertical shift time, so that we can check the above hypothesis?
If it seems correct, I will overwrite the CycleTime in sif_parser.
(Scientifically, there should be a better experiment. For example, we may connect an LED to a function generator and make it blink with for example 10kHz frequency. Then we can measure the blink of the LED and calibrate / check the cycle time we believe)
I shall check that and let you know. Most probably that should be possible. But this is what I understand from the proposed experiment: The blinking time should co-incide with the exposure time? Logically: (Acquisition time 1 frame = Exposure time (blink on) + Vertical Shift time (blink off))
If it does not, then the delay (extra time taken for the particular frame acquisition) is probably a dead time in this sense: (Acquisition time 1 frame = Exposure time (blink on) + Vertical Shift time (blink off) + Dead time (delay)) ?
The blinking time should coincide with the exposure time?
I propose to have longer blinking time. If our expected cycle time is ~30us, let's have ~5kHz blinking, so that we can see on and off in the image sequence. Then we can calculate the cycle time from the sequence.
If it does not, then the delay (extra time taken for the particular frame acquisition) is probably a dead time in this sense: (Acquisition time 1 frame = Exposure time (blink on) + Vertical Shift time (blink off) + Dead time (delay)) ?
I am not sure. I don't think a dead time makes sense... Even if there is a dead time, the sensor is exposed to the light during the dead time, which essentially is the exposure time.
Or probably the easiest way is to ask Andor for the cycle time, or find the section in the manual.
Hi @fujiisoup,
I have an update about the Fast Kinetics Mode. So, in this mode, we get an extra 20.71 us for every configuration.
What I mean by this is: assuming we have an exposure time of 1 us, and vertical shift time of 0.6, 1.13, 2.2, or 4.33 us, the acquisition cycle time will always have an excess dead time of 20.71 us. This dead time figure is constant.
For instance, Exposure time = 1 us vertical shift time = 0.6 us acquisition cycle time = 1 + (0.6 x 8) + 20.71 us = 26.51 us
Similarly, Exposure time = 1 us vertical shift time = 4.33 us acquisition cycle time = 1 + (4.33 x 8) + 20.71 us = 56.35 us
The following image depicts the situation for both the example cases above:
For 0.6 us:
For 4.33 us:
This means that we might be able to reliably use the accumulation time as timestamp for our frames in the FKM, assuming that there will always be a dead time of 20.71 us, along with the dead time for vertical shift.
@sabyasachiph Thank you for the investigation. This is consistent, but I feel it is still weird. I don't see any reason that Andor sets up 20.71-us deadtime for FastKinetic mode. There should not be deadtime.
I read the manual for iXon Ultra, and it seems that the camera outputs the fire signal corresponding to the exposure time.
By connecting an oscilloscope to the fire signal, we can make sure whether the deadtime is there or not.
(This explanations is for 1024 x 8 pixel strip and 0.6 us vertical shift speed. Also, the vertical shift clock voltage was kept at +4 V)
I think you are right. I guess the acquisition cycle time refers to the point of time when the first frame of the series is capture and for that, it takes around 20.71 us additional amount. After a certain number of frames are captured, the time difference between the arrival of subsequent frames probably goes down to around 6.28 us, as show in the figure below (just a schematic representation).
Might also be the case the readout happens 20.71 us after entire series has been acquired.
I think this is the case because when I viewed the time lapse, I saw that for the first few frames, the particles I imaged were moving vertically. It might either be that the image acquisition time is different for each acquisition cycle, or might be a problem of the clocking of the pixels vertically.
Do let me know if you need the file to verify.