Remove binning from camerad.cfg.in

[MateuszKM]

Ensure the detector geometries defined in the sequencer startup script, camerad configurations, and engineering gongpsX scripts use the same initial geometry.

[drriddle]

Why are detector geometries defined in more than one place? That's an architecture failure...there should be a single place where the actual pixel definitions are set, it shouldn't be in multiple places where it can get out of sorts. I set my camera configurations inside a config file that is tied to the detector low level interface, and read the actual camera information to set the geometry. Keys are used to select camera modes, and for geometries it's windows or binning which can be set using external commands. If the detector system doesn't actually report its pixels, then those should be set in one place and everything else reads it from there...that really should be the detector configuration file, it's closest to the actual detector.

[astronomerdave]

camerad is the "owner" of the detectors. His config file camerad.cfg.in defines the physical properties of the detectors, and only the physical properties (I.E. not binning, as that is not a physical property). THESE SHOULD NEVER CHANGE unless there is a detector change. I see that I did include binning there, and that is a mistake. It was not meant to be used and will be removed from that config file.

sequencerd is the "user" of the detectors and everything else (and by design is the only user of the cameras and everything else). sequencerd.cfg.in defines how to set up the cameras (and everything else).

The use of scripts is considered an expert-user interface and is up to the user to manage.

[MateuszKM]

Am less concerned about the binning and more concerned about the image geometries having different overscans defined in different places leading to different final image sizes independent of the binning set.

[drriddle]

Dave already gave the answer. The camerad config file holds the information for the detectors, and the sequencerd holds observation setup information. The overscan setup should be in one of those files, depending on if it's defined as a detector or observation bit of information. Those files hold the information and should be the only source of it.

If someone wants to use their own script they should either copy the information in the config files or read the config files directly. It would be best to use the system as designed and go through the sequencer of course, going around it opens up a can of worms in terms of trying to operate the system that the sequencer is there to solve. If someone wants to use their own scripts instead of the sequencer, then it should be their responsibility to replace the sequencer's role in the instrument.

[MateuszKM]

Until Dave had made the change (not sure if you got a chance to do so, yet, actually), both camera.cfg and sequencer.cfg were defining geometries and I think they were defining different geometries.
I am perfectly happy if something owns the parameters and I can call it from command line to initialize. The problem is that if I want to work with/read out just one of the four NGPS cameras I have to edit a configuration file and restart the relevant daemon(s). All of this came up when we needed to read U+G independent of R+I and there was no canned way to do it.