FrameGeometry shouldn't include certain routines
Jammy2211 opened this issue · comments
You've combined FrameGeommety from cti_image with CIFrame from ci_frame. This is fine for the most part, however there are routines which are specific to charge injection imaging (e.g. parallel_trail_from_y) which are not applicable to other imaging which may need to be a cti_image and thus have a FrameGeometry (e.g. science imaging data).
I would suggest we split the classes again and have CIFrameGeometry inherit from FrameGeometry.
It’s an ongoing refactor. The motivation was elimination of function duplication using the notion of a readout corner and exploiting symmetries between functions. It may be that a common parent class is more appropriate?
… On 16 Jan 2019, at 11:55, James Nightingale ***@***.***> wrote:
You've combined FrameGeommety from cti_image with CIFrame from ci_frame. This is fine for the most part, however there are routines which are specific to charge injection imaging (e.g. parallel_trail_from_y) which are not applicable to other imaging which may need to be a cti_image and thus have a FrameGeometry (e.g. science imaging data).
I would suggest we split the classes again and have CIFrameGeometry inherit from FrameGeometry.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGETMvK_Jue7qj7WE2b2e1czWWakAREMks5vDxMrgaJpZM4aC55L>.
I'll think on it, still getting to grips with the refactor