[chimera-cam] start new exposure when downloading

[wschoenell]

When can sensitively reduce the dead time starting the new exposure right after the CCD was read. Download and save can be done while exposing the next image.

[phsilva]

Today, all camera drivers handles the final image saving process. This must be moved to base camera.py and there it is possible to do the final saving in a different process. It will need a way to pass the (possibly large) image array to this new process. Maybe CameraBase can create a pipe or something, where the driver must write its data, after it is written there the camera can move to a new exposure.

Not a naive change to do, caution required.

[phsilva]

http://docs.astropy.org/en/v0.3/io/fits/appendix/faq.html#how-can-i-create-a-very-large-fits-file-from-scratch

This could be used in the scheme I mentioned above. But I would add some profiling code to check where time is being spent. SBIG and FLI are similar I think, but maybe on SI final camera things might be problematic as the size grows a lot.

[wschoenell]

In the case of the SI camera, the SI Image program sends the image array
through the socket or it saves a fits file on the directory defined on its
configuration file. I would go for using the save-on-camera-computer mode
with chimera doing an header update after saving. What do you think?

From SI manual:

Modes can be selected where the image is saved on the local computer
that is controlling the camera and/or transmitted to the client. The
client can also inquire the camera status and obtain the image header
that contains all the operating parameters of the camera during the last
image acquisition.

On Thu, Mar 12, 2015 at 7:53 PM Paulo Henrique Silva <
notifications@github.com> wrote:

http://docs.astropy.org/en/v0.3/io/fits/appendix/faq.html#how-can-i-create-a-very-large-fits-file-from-scratch

This could be used in the scheme I mentioned above. But I would add some
profiling code to check where time is being spent. SBIG and FLI are similar
I think, but maybe on SI final camera things might be problematic as the
size grows a lot.

—
Reply to this email directly or view it on GitHub
#38 (comment).

[ghost]

Hola;

Several thoughts in no particular order, just out of my mind, and with

no specific preference (yet):
o Is generality still a goal for Chimera as a project? It's fine to think
about solving this issue for the SI camera since it's our primary concern,
but shouldn't we try to design a solution that fits most cases? The de
facto pattern for instrument drivers is to have a "low level" component
handling the communication with the hardware, and a "high level" one to
manage images, chimera requests, etc. This latter deserves attention since
it's hard to multi[task|thread|process] an instrument...
o I keep constantly reminding myself that Chimera is a distributed
system... Meaning it can be a system design decision to offload a heavy
task (like reading the SI CCD) to a separate chimera node specially fit for
the task, running in its own python.
o Are CCD readout times, slew times, XYZ times part of the scheduler's
decision algorithm? For what little I remember from my engineering, this is
an optimisation problem, never easy...

On Thu, Mar 12, 2015 at 8:19 PM, William Schoenell <notifications@github.com

wrote:

In the case of the SI camera, the SI Image program sends the image array
through the socket or it saves a fits file on the directory defined on its
configuration file. I would go for using the save-on-camera-computer mode
with chimera doing an header update after saving. What do you think?

From SI manual:

Modes can be selected where the image is saved on the local computer
that is controlling the camera and/or transmitted to the client. The
client can also inquire the camera status and obtain the image header
that contains all the operating parameters of the camera during the last
image acquisition.

On Thu, Mar 12, 2015 at 7:53 PM Paulo Henrique Silva <
notifications@github.com> wrote:

http://docs.astropy.org/en/v0.3/io/fits/appendix/faq.html#how-can-i-create-a-very-large-fits-file-from-scratch

This could be used in the scheme I mentioned above. But I would add some
profiling code to check where time is being spent. SBIG and FLI are
similar
I think, but maybe on SI final camera things might be problematic as the
size grows a lot.

—
Reply to this email directly or view it on GitHub
#38 (comment).

—
Reply to this email directly or view it on GitHub
#38 (comment).

Nelson Saavedra Pinos

NAIR Servicios Informáticos E.I.R.L.

e: saavedra.nelson@gmail.com
c: +56 51 69074027