The purpose of the model is to mask any assumptions about its implementation or nature of the relationships between parameters and output from the consuming application. As an example, the model could be implemented as a simple linearized version based on affine transformations, but it could also be a full physics simulation.
As a most general interface, the model could generate a very large, sparse correction matrix that maps an entire data set into a corrected physical parameter space. However, this correction matrix would be several times larger than the input data even in a sparse representation. Furthermore, it would mask many aspects from the calling application that might be of relevance, for example for user interaction.
As a proposed compromise solution that abstracts a way many "ugly" details, but still keeps the operation transparent and flexible, the model could distinguish between several "base models", such as "TEM" or "STEM" together with extensions such as "pixelated detector", "spectrometer", and so on.
The calling application can first initialize the model with the file metadata and the query the model about its base class and extensions to use.
For each base class and its extensions, there would be a well-defined list of corrections, together with clear instructions on how and in which order to apply them. It might be possible to combine corrections for efficiency, for example with a matrix product of correction tensors. This would be documented as well.
For debugging and verification there should be reference data sets. A consuming application can apply corrections to the reference data and verify that the correct result comes out.
With this API, the calling application has some flexibility on how to apply corrections, leaving steps out if that seems appropriate, and the correction would be transparent and to some degree composable. At the same time, the calling application doesn't have to know how these corrections are derived. Perhaps there could be convenience functions that help to apply all default corrections to a portion of the data.
Discussions with @sk1p:
The purpose of the model is to mask any assumptions about its implementation or nature of the relationships between parameters and output from the consuming application. As an example, the model could be implemented as a simple linearized version based on affine transformations, but it could also be a full physics simulation.
As a most general interface, the model could generate a very large, sparse correction matrix that maps an entire data set into a corrected physical parameter space. However, this correction matrix would be several times larger than the input data even in a sparse representation. Furthermore, it would mask many aspects from the calling application that might be of relevance, for example for user interaction.
As a proposed compromise solution that abstracts a way many "ugly" details, but still keeps the operation transparent and flexible, the model could distinguish between several "base models", such as "TEM" or "STEM" together with extensions such as "pixelated detector", "spectrometer", and so on.
The calling application can first initialize the model with the file metadata and the query the model about its base class and extensions to use.
For each base class and its extensions, there would be a well-defined list of corrections, together with clear instructions on how and in which order to apply them. It might be possible to combine corrections for efficiency, for example with a matrix product of correction tensors. This would be documented as well.
For debugging and verification there should be reference data sets. A consuming application can apply corrections to the reference data and verify that the correct result comes out.
With this API, the calling application has some flexibility on how to apply corrections, leaving steps out if that seems appropriate, and the correction would be transparent and to some degree composable. At the same time, the calling application doesn't have to know how these corrections are derived. Perhaps there could be convenience functions that help to apply all default corrections to a portion of the data.