FrameGeometry shouldn't include certain routines

[Jammy2211]

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.

[rhayes777]

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>.

[Jammy2211]

I'll think on it, still getting to grips with the refactor