viljarjf
commented
4 days ago Timeline-wise, the simple initial implementation is pretty much ready to go. I would like to add some more tests, and try it out some more, but I don't think expanding the initial scope is necessary. As stated, it should be fairly simple to expand, but the scope can be kept simple to start with.
Currently, the camera simulation is simply an API simulation, with the image being random noise. This is limiting, as e.g. the experiments cannot be tested properly with this; they require spatially defined crytstals capable of diffraction.
I started working on this in https://github.com/viljarjf/instamatic/tree/camera-simulation. There, I added a stage and a random crystal structure, randomly dispersed and oriented on a grid. I plan to support stage rotation, tilting, correct handling of beam shift/tilt ect. later. However, I am not entirely sure how all the microscope parameters affect the images (real and reciprocal), so to begin with, I plan to keep it simple and allow expansions at a later stage. Currently, the simulation supports a single crystal phase, random dispersion, any number of circular crystals of any size, and a copper grid. Tilting is mostly implemented, but not tested, so it will display a warning for now.
Expanding this to support more phases, tilting, magnification-induced image rotation and so on should not be too difficult programming-wise, however I'm not too confident that I'll do this correctly without input. Therefore, I'm opening this issue to hopefully have a discussion about what and how things should be simulated.
An improved camera simulation should dramatically expand the features of instamatic that can be properly tested. We can test the experiments, the GUI, calibration (if we implement an accurate simulation). Additionally, it should make further developments much easier, as testing algorithms would not strictly require access to a microscope (at least for initial development).
As for downsides, expanding the scope can easily get carried away. It will necessarily add more dependencies (as is already the case with my branch), which will only get worse with increased accuracy (hopefully! Complex imaging/diffraction simulations should be handled by external libraries). Handling inaccurate alignment, astigmatism ect is a good idea, but the added work of implementing this might not be worth it compared to how basic it is to compensate for by the operator.