After discussion with the Odin instrument scientist, some things were clarified about normalizing Orca images.
Exposure time
We probably do not need to know the camera exposure time after all. The assumption is that for every run, the dark frame, open beam and sample will all be recorded with the same FPS on the camera. So the exposure time factor should cancel out everywhere.
We could still read the exposure time as a safety check, to make sure we are not combining data that were recorded using different FPS.
Normalizing by proton charge
Currently, the implementation of the proton charge normalization is wrong. We need to normalize each recorded frame by the corresponding proton charge.
For every single frame (before we do any mean or sum of the dark/open frames), we need to find the pulse that corresponds to the time trigger coordinate in the orca 2d array, and use that to normalize the frame. Only once this is done can we average dark and open beam frames together.
Recording modes
There seems to be two main recording modes for the camera:
- Start/stop: most probably synchronized with a pulse trigger; rotate sample > take a frame > rotate sample again > take new frame
- Continuous: goes out of sync with the pulse at either 30, 60 or 100 fps?; rotate continuously and record at high frame rate
What do we do for frames that end up between pulses? It is currently not clear what the data will even look like in the nexus files, as currently the time axis is controlled by the pulses. How will it look when wer record continuously at 100 fps?
To get some more information on this, the Odin team will carry out some tests with the orca camera in the coming weeks.
After discussion with the Odin instrument scientist, some things were clarified about normalizing Orca images.
Exposure time
We probably do not need to know the camera exposure time after all. The assumption is that for every run, the dark frame, open beam and sample will all be recorded with the same FPS on the camera. So the exposure time factor should cancel out everywhere.
We could still read the exposure time as a safety check, to make sure we are not combining data that were recorded using different FPS.
Normalizing by proton charge
Currently, the implementation of the proton charge normalization is wrong. We need to normalize each recorded frame by the corresponding proton charge.
For every single frame (before we do any mean or sum of the dark/open frames), we need to find the pulse that corresponds to the
timetrigger coordinate in the orca 2d array, and use that to normalize the frame. Only once this is done can we average dark and open beam frames together.Recording modes
There seems to be two main recording modes for the camera:
What do we do for frames that end up between pulses? It is currently not clear what the data will even look like in the nexus files, as currently the time axis is controlled by the pulses. How will it look when wer record continuously at 100 fps?
To get some more information on this, the Odin team will carry out some tests with the orca camera in the coming weeks.