[essimaging] Orca normalization by proton charge per frame#663
Conversation
…both sample and open beam, then divide by open beam
…at covers the whole experiment range
| "ymir_lego_dark_run.hdf": "md5:c0ed089dd7663986042e29fb47514130", | ||
| "ymir_lego_openbeam_run.hdf": "md5:00375becd54d2ed3be096413dc30883c", | ||
| "ymir_lego_sample_run.hdf": "md5:ae56a335cf3d4e87ef090ec4e51da69c", | ||
| "ymir_lego_dark_run.hdf": "md5:2d9ae7d6f1d0502c17b0030bcb3dad1d", |
There was a problem hiding this comment.
I had to update the data because the proton charge in the old files started exactly at the start of the time axis for the camera data. However, when doing sc.lookup in 'previous' mode, the first data point was not found (probably because of numerical precision errors) and a NaN was returned.
So the first data slice in the dark lookup was NaN. We then took the mean which gave NaN, and then all data was NaN.
I now updated the proton charge logs to start a bit before the data starts.
| # not the same time as the proton charge (which is when the protons hit the | ||
| # target). We need to shift the proton charge time to account for the time it takes | ||
| # for neutrons to travel from the target to the detector. Does this mean we cannot | ||
| # do the normalization without computing time of flight? |
There was a problem hiding this comment.
Yes, I think that is what this implies. Or is ODIN short enough that we can just use the 'time' coord from the nexus data?
What is the 'time' coord in data here? Is that the time at the source?
| def subtract_background_openbeam( | ||
| data: FluxNormalizedDetector[OpenBeamRun], | ||
| background: FluxNormalizedDetector[DarkBackgroundRun], | ||
| background: MeanDarkFrame, |
There was a problem hiding this comment.
Note: Should we subtract the mean dark from each OB frame or should we subtract it from the mean OB? Are the resulting variances the same?
There was a problem hiding this comment.
It's also a question about the scales of float values. Are there significant truncation errors from subtracting the (large?) mean dark from each individual OB frame?
There was a problem hiding this comment.
I think we can safely assume that counts in the dark frame will always be lower than in open beam and sample. Open beam will probably have the highest counts.
There was a problem hiding this comment.
But is sum(open_beam) >> sum(dark_frame)? In that case, you might get better accuracy by subtracting frame by frame.
There was a problem hiding this comment.
I also think we expect the dark frame to be more stable than the open beam. The dark is the inherent noise of the chip which is always there. The open beam can fluctuate due to external factors. So I would vote to subtract the dark from each OB frame and then take the mean OB after that.
|
|
||
|
|
||
| def average_dark_frames( | ||
| dark_frames: FluxNormalizedDetector[DarkBackgroundRun], |
There was a problem hiding this comment.
Should we actually normalize the dark measurement by proton charge? If it never sees the neutrons, we could be introducing fluctuations that aren't actually there?
There was a problem hiding this comment.
If there is background from e.g. a neighouring instrument bleeding in through the cave walls, then fluctuations could be related to the proton charge after all?
-> assume to begin with that we don't need to normalize by proton charge but keep the option open to add it back in later.
There was a problem hiding this comment.
Sounds to me like you don't want to normalise by proton charge but by measurement duration. You need something that corresponds to an event rate, not a count. The proton charge norm does this but it depends on the source. So if you would measure a dark frame while the source is off, it wouldn't count under proton charge norm. But that makes no sense.
There was a problem hiding this comment.
For the measurement duration, the conclusion was that all 3 measurements will be recorded with the same frame rate (fps). So every frame has the exact same duration. That duration cancels out in the normalization so we actually don't need the exposure time of each frame.
There was a problem hiding this comment.
For my understanding: Does this mean that every frame is normalised by the duration such that sum(dark_frame) does not depend on the number of dark frames recorded?
2 participants
We change the way we use the proton charge to normalize the Orca data.
timedimension.(Sample - MeanDark) / (OpenBeam - MeanDark).mean('time')Fixes #636