Full Information about detector in Optics

Registered by Tom Dimiduk

Should the Optics class contain full information about the detector (so that for example you could compute a hologram given only an Optics object)? Currently the only information the optics is lacking is the pixel size of the detector (256x256 or 1024x1024 or whatever).

There are sort of two reasons this information has not been included in the optics so far:
(1) That information is already contained elsewhere (namely in hologram.shape) and keeping it it two places offers the chance for them to get out of sync. For example, hp.subimage would be modified to keep this value up to date, but if a user uses generic numpy slicing on a hologram this value could become wrong unless we override those functions.

(2) At the time you create an optics file it is not always obvious what the pixel count you will want is, even though it may become obvious shortly later (like after you load a hologram). Forcing the user to guess at this early point is unfortunate.

I think with a little bit of thought about our workflows we can get around most if not all of these objections. We can make the shape (or whatever we want to call it) argument to optics optional and then have the various functions fill it in when they know the information. hp.load can take an optics object or optics yaml that does not specify a shape just fine because it will know the shape from the hologram it is loading. Fits can also take a shape agnostic optics because they will have a data hologram they can harvast a shape from.

The only case where the user will have to specify the shape when making an Optics is when they are computing a hologram in by itself (with scatterpy), but in this case they were going to have to specify one somewhere anyway. It is perhaps a little more cumbersome here because they need to make a new optics file if they want to change the size of the computed hologram.

hp.load can figure out pixel sizes when it loads the hologram,

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Tom Dimiduk

Related branches

Sprints

Whiteboard

Schema are essentially a better implementation of what this was discussing

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.