For #167, it is looking like we may need to think about where the accelerating voltage / wavelength should go in the ImagePipeline pytree. TheAbstractScatteringPotential may need access to the wavelength. The wavelength is currently housed in the CTF class, however the CTF and scattering potential are unrelated.
(It is very important that we have no duplicate parameters in the ImagePipeline pytree. One way of testing this is with equinox.tree_check)
Whether or not this refactor is necessary for addressing #167, this will continue to come up, so wanted to mention now. For example, if we want to build out the model for the DQE in the AbstractDetector, it will also need the wavelength—as well as the dose rate. This is just one example. Many components of an image formation pipeline will specifically want to know about the wavelength and the dose rate.
It’s not completely clear how to address this in my mind, but something like the following skeleton is the best I have right now:
I’d like the CTF to continue to not need required parameters at call time besides a coordinate system. Therefore, we can keep the same API with CTF.voltage_in_kilovolts. However, we can mark the parameter with field(static=True) so that it is not treated as a pytree leaf. Then, we can provide an option to pass the CTF a voltage at call time that overwrites the voltage stored in the CTF (this is sadly a bit hacky).
Give the acceleration voltage to the ElectronDose. Now, similar to in AbstractDetector.__call__, we can pass the ElectronDose to AbstractOptics.__call__. Then, the voltage can just be passed to the CTF.
Now, we can probably just keep passing around the ElectronDose at call-time to methods that need it. For example, the ElectronDose can be passed to methods of the AbstractScatteringPotential or the AbstractSpecimen. This is similar to how the ImageConfig is currently used. This will make it a required object in the pytree, so we can change the Instrument.__init__ (currently it is optional).
We can look into if using equinox.nn.Shared might be appropriate for this task, but it seems to me the above is better.
This should also be general enough to handle future models of radiation damage, which will be housed in the ElectronDose :)
For #167, it is looking like we may need to think about where the accelerating voltage / wavelength should go in the
ImagePipeline
pytree. TheAbstractScatteringPotential
may need access to the wavelength. The wavelength is currently housed in theCTF
class, however the CTF and scattering potential are unrelated.(It is very important that we have no duplicate parameters in the
ImagePipeline
pytree. One way of testing this is withequinox.tree_check
)Whether or not this refactor is necessary for addressing #167, this will continue to come up, so wanted to mention now. For example, if we want to build out the model for the DQE in the
AbstractDetector
, it will also need the wavelength—as well as the dose rate. This is just one example. Many components of an image formation pipeline will specifically want to know about the wavelength and the dose rate.It’s not completely clear how to address this in my mind, but something like the following skeleton is the best I have right now:
CTF.voltage_in_kilovolts
. However, we can mark the parameter withfield(static=True)
so that it is not treated as a pytree leaf. Then, we can provide an option to pass the CTF a voltage at call time that overwrites the voltage stored in the CTF (this is sadly a bit hacky).ElectronDose
. Now, similar to inAbstractDetector.__call__
, we can pass theElectronDose
toAbstractOptics.__call__
. Then, the voltage can just be passed to the CTF.ElectronDose
at call-time to methods that need it. For example, theElectronDose
can be passed to methods of theAbstractScatteringPotential
or theAbstractSpecimen
. This is similar to how theImageConfig
is currently used. This will make it a required object in the pytree, so we can change theInstrument.__init__
(currently it is optional).We can look into if using
equinox.nn.Shared
might be appropriate for this task, but it seems to me the above is better.This should also be general enough to handle future models of radiation damage, which will be housed in the
ElectronDose
:)