Load probes

[alexbjorling]

The input probe is now resampled to match the real space pixel size of the experiment if needed. Also, Storage objects can be supplied as illumination.model.

Might have missed something important here as I was focused on making a specific application run. But take a look.

To see how it works, first reconstruct with minimal_prep_and_run.py, then modify it to use the reconstructed probe and a different shape, and see how the loaded probe changes size.

p.scans.MF.data.shape = 32 # for example

p.scans.MF.illumination = u.Param()
p.scans.MF.illumination.model = 'recon'
p.scans.MF.illumination.recon = u.Param()
p.scans.MF.illumination.recon.rfile = ('~/tmp/recon.ptyr') # or /tmp/ptypy/what-ever.ptyr
p.scans.MF.illumination.aperture = None

[alexbjorling]

Now you can pass a Storage to illumination.model as well, which is convenient because the pixel sizes get taken into account. Like this:

c = Container()
s = c.new_storage(psize=5.6e-8/10, shape=(1,128*10,128*10))
init_storage(storage=s, pars='moon')
s.data[0,:640,:640] = 0  # just to see the effect

# ...

p.scans.MF.data.shape = 128

# ...

p.scans.MF.illumination = u.Param()
p.scans.MF.illumination.model = s
p.scans.MF.illumination.aperture = None

[bjoernenders]

Hi Alex,
thank you for the commit. As you noticed from the comments in illumination.py, this is a feature we need. I have comments though on the implementation side of things.
First of all, we want all parameters that feed into the parameter tree to be standard types, which does not quite work with passing a Storage inillumination.model = s . Second I wonder if you want to just replace a probe or if you want to process it to become something different? In the first case, a nice side loading runtime that could even be part of classes.py could be a good option, like Storage.ingest(storage) and you could do it at runtime after model creation. The argument I want to make is that if you are using ptypy objects, you are in an environment that supports a Ptycho instance and our object tree and I want to move the package to a place where we tinker with the object tree instead of treating Ptycho(level=5) as a black box.

[alexbjorling]

thank you for the commit. As you noticed from the comments in illumination.py, this is a feature we need. I have comments though on the implementation side of things.

I expected no less!

First of all, we want all parameters that feed into the parameter tree to be standard types

Ok, if that's really a requirement then we can drop the storage param and only accept the 'recon' string, and whoever really wants to input a storage can just engineer the corresponding ptyr file.

Second I wonder if you want to just replace a probe or if you want to process it to become something different?

I think being able to process it with the illumination module makes sense. For example if I did a successful reconstruction at some distance from the focus, and I move the sample to a more challenging plane for some reason (to do Bragg ptycho in focus, perhaps), it would be nice to load it and then say parallel = -300e-6or what ever. But I have no strong opinion on this.

The argument I want to make is that if you are using ptypy objects, you are in an environment that supports a Ptycho instance and our object tree and I want to move the package to a place where we tinker with the object tree instead of treating Ptycho(level=5) as a black box.

I'm not sure I follow here, I use the illumination module as a utility library quite often, without using Ptycho. But again, I'm of no strong opinion here and just needed to get the pixel size scaling for some work that @susannahammarberg is currently doing...