Image Acquisition in PixInsight (Was: When will Pixinsight...)

[David Raphael]

If I were to write this module(s), here is what I would do for the camera driver interaction:


I would define something like the following for the camera driver interface:

PICameraInterface.h
PICameraInterface.cpp

This would define the interface a manufacturer would need to implement for a PixInsight driver. 

We would have some sort of GUID to identify a particular driver.  This would allow a "registry" of sorts...really I am not inventing anything here.  I would just find something good in the open source world and emulate it...I won't try to guess what that looks like at the moment...


And to demonstrate this, I would implement the ASCOM PixInsight Interface:

ASCOMCameraInterface.h
ASCOMCameraInterface.cpp

Incidentally, this would provide a large amount of coverage for Windows based cameras. 


I agree with Vicent that we need a multiplatform ASCOM.  However, that is not something that belongs in the PixInsight community IMO.  I'm not planning on running any further with that idea myself.  I'd really like to see the ASCOM folks extend the standard to be C/C++ based - qt is really a good choice for this as evidenced by PixInsight itself.  In fact, the proof of concept for a multi-platform ASCOM can "fall out" of a project like this.  This is a virtue of implementing camera control on PixInsight :-)

I'm probably going to start prototyping this soon...I've been setting up my PCL builds on OS X and Windows.  I don't usually run Linux or FreeBSD, but I am sure we can cross that bridge later.

Anyone have any specific requests? 

Cheers,
Dave

[Emanuele]

Can't wait for some development David! 

I am here if you need some beta testing!

I have an FLI ML8300 and FLI CFW2-7. Along with a Lodestar. And a 10Micron GM2000QCI mount.

[vicent_peris]

This is whole different animal. Testing drivers is full time job and there is always a new one.

 Run away... Run away....

Max

I think this must be up to the user... The same thing happens with the ASCOM, and it's not a crazy project.

IMO, this would be a wonderful project.

Regards,
Vicent.

[georg.viehoever]

...Second, IMO, what's really needed is a multiplatform port of ASCOM. ASCOM is being today, IMO, a bit outdated. There are a lot of multiplatform apps right now, and this will evolve in the near future. So it would be great if we have a platform independent (well... only driver dependent) communitcation protocol for astronomical instruments....

I think INDI http://www.indilib.org/index.php?title=Main_Page is a platform independent alternative to ASCOM (currently under development).

Georg

[Emanuele]

I was following another thread that was mentioning an FWHM tool.
It would be incredibly useful to implement this tool in the Real Time Stacking/Folder monitoring tool.
To have a way of selecting a star in the image, and by the use of the Real-Time stacking tool, have a monitor of the FWHM of the selected star.

E.

[David Raphael]

I've started to bang away at some code.  So far, here is how I am laying things out in order of priority:

ImageAcquisitionModule

 - ExposeImageProcess (in progress)
   This will support the following parameters:
       exposureCount
       exposureDuration
       cameraConfiguration (this may be a separate process - kind of like the Global Modules, but I haven't decided yet.  Right now, I am doing a modal type of dialog that lives inside of the same code.)
          ...
       cameraTemperature
       filterIndex
       isPreviewExposure
       binningModeX
       binningModeY
       fileSavePath
       fileNamePrefix
       
       ... I am probably missing some, but you should get the general idea here...

 - ImagingSessionProcess
    I'm thinking this can drive multiple sets of ImageExposures.  Additionally, this would be a lot like a CCD Commander where we can add actions as the rest of the processes are developed.

 - ImageAcquisitionPreferences
    There needs to be a place to store things like F/L, Aperture, Site locations, Sensor characteristics, Image scale etc...this would be a place to centralize those data points for all of the other processes in the module.

 - HFD/FWHMProcess:
    FWHM + A real time monitor of star quality.  It can even possibly notify a user based on a threshold that there is an increase in HFD etc...

 - AutoguideProcess
    This would be higher priority, but PHD guiding is good and free.

 - SlewProcess
    This would be really easy to do.

 - FocusProcess
    With the HFD/FWHM function, this would be relatively easy to implement

 - PlateSolveProcess
   This would be a fairly "dumb" module that could interface with the Blind Solver or PinPoint etc...

 - CurvatureMeasurementProces
   I would also like to be able to perform similar curvature maps like CCDInspector...

 - TiltMeasurementProcess
   And tilt as well...
   


All of these processes will have GUI interfaces, instance classes, and parameter classes where appropriate...

I will keep adding to this as I think through it more.  Feel free to add any thoughts or suggestions!

Cheers,
Dave

[mmirot]

I have no problem if someone wants to develop this per se.

My concern is that it delays other aspects of PI development.

The implementation and testing of drivers is on multiple plateforms is a major time commitment.

Will it become a major headache everytime someone wants the their new equipment added to list of supported devices?

Just responding to these requests takes time.

Max

[David Raphael]

I am planning on supporting ASCOM out of the box.  So that will actually cover a lot of devices for "free."  ASCOM drivers are a lot easier to deal with since the interface is well defined. 

I don't plan on writing a bunch of drivers for different cameras.  Most of the camera companies already support ASCOM, so this should really be a big deal unless I am missing something.

Since I don't work on any other parts of PI ;-)  I don't think this will delay anything! 

Also, I plan on making the driver architecture dynamic.  This means that you will be able to drop drivers into the module - as opposed to the module maintaining a huge list of drivers.

Cheers,
Dave

[Juan Conejero]

Hi David,

Excellent initiative. I like your overall design as a starting point, so go ahead and count on our collaboration with anything related to PI/PCL development!

Also, I plan on making the driver architecture dynamic.  This means that you will be able to drop drivers into the module - as opposed to the module maintaining a huge list of drivers.

This is coherent with PixInsight's modular/object-oriented architecture. 'Dropping something into' sounds well as an object-oriented concept. Just like dropping a process icon on an image for example; you're getting the feeling of it

I am planning on supporting ASCOM out of the box

I understand your reasons. However, I'd suggest you design your modules with total independence on ASCOM or anything similar. With a proper top-down design and isolation between functional blocks, you can support it without depending on it. ASCOM is Windows-centric, which is something to be avoided for the reasons noted before.

Georg has suggested INDI, which looks like a nice alternative. However, I see it still too immature as to depend on it (please correct me if I'm wrong). I'd keep a close eye on this project though.

A first step could be answering a simple question: Which camera manufacturers provide drivers for Windows, Linux, and Mac OS X, and what do these drivers have in common? This would give us an idea of what we can expect and where we should be moving on.

ExposeImage
       exposureCount
       exposureDuration
       (cameraConfiguration)
       cameraTemperature
       filterIndex
       isPreviewExposure
       binningModeX
       binningModeY
       fileSavePath
       fileNamePrefix


That looks like a very good start. Instead of ExposeImageProcess I'd name it just ExposeImage (the word Process is redundant IMO). Perhaps even better, AcquireImage (has a more general meaning). cameraConfiguration requires further elaboration; I don't think it should be part of ExposeImage, it probably should be a global configuration object within your module. I'd add a fileNamePostfix parameter because there are guys out there that prefer postfixing (I know a few ) Other than these, your design looks very correct to me. Now you need an icon

[Juan Conejero]

Hi Max,

My concern is that it delays other aspects of PI development.

Don't be concerned about that. As David has said, I am not involved besides assisting him as I do with other active developers, which is just part of my job.

More at the contrary, these initiatives are just what can make PixInsight greater and more useful. PixInsight is here to generate new tools and new ways of enjoying astrophotography and image processing

[Andres.Pozo]

Georg has suggested INDI, which looks like a nice alternative. However, I see it still too immature as to depend on it (please correct me if I'm wrong). I'd keep a close eye on this project though.

Indi has not an implementation for Windows, so it is not [yet] multiplatform neither.

[David Raphael]

Hi David,

Excellent initiative. I like your overall design as a starting point, so go ahead and count on our collaboration with anything related to PI/PCL development!

Thanks!

I am planning on supporting ASCOM out of the box

I understand your reasons. However, I'd suggest you design your modules with total independence on ASCOM or anything similar. With a proper top-down design and isolation between functional blocks, you can support it without depending on it. ASCOM is Windows-centric, which is something to be avoided for the reasons noted before.

Let me clarify this statement about ASCOM - I am not going to integrate with ASCOM directly.  I will implement something like:
 - IPixInsightCamera.h

And I will probably use the ICamera interface from ASCOM as my inspiration.

When I say I will support ASCOM out of the box, I simply mean that I will distribute the PixInsightASCOMCamera.h/cpp etc...

A first step could be answering a simple question: Which camera manufacturers provide drivers for Windows, Linux, and Mac OS X, and what do these drivers have in common? This would give us an idea of what we can expect and where we should be moving on.

I am a QHY dealer.  We don't have anything but Windows drivers officially.  However, Dr. Q (of QHY) releases the drivers as open source.  The only thing that is not open source is the HEX Firmware.  However, this is also freely available and is platform independent.  There are a group of grassroots developers working on Linux support for QHY...He has committed to me that he wants to support multiple platforms.

SBIG provides Mac and Linux drivers.

QSI provides SDKs and some Linux support as well.

I am not sure about the other companies. 

ExposeImage
       exposureCount
       exposureDuration
       (cameraConfiguration)
       cameraTemperature
       filterIndex
       isPreviewExposure
       binningModeX
       binningModeY
       fileSavePath
       fileNamePrefix


That looks like a very good start. Instead of ExposeImageProcess I'd name it just ExposeImage (the word Process is redundant IMO).

Makes sense

Perhaps even better, AcquireImage (has a more general meaning).

I started with "ImageAcquisition" ... and then I started thinking about what acquisition means...I was thinking that acquisition includes things like guiding and dithering etc...  I think I am striving to keep this modular...and then we can rename ImageSession to AcquireImages?  Imaging the serialized data of an AcquireImages:
 <sessionName>Wide Field of Orion</sessionName>
 <sessionDate../>
 <executeProcesses>
    <Autoguide command="calibrate"/>
    <Autoguide command="guide"/>
    <ExposeImage>
      <count.../>
      <duration.../>
     <.../>
    <.../>
    <Autoguide command="dither"/>
    <ExposeImage>
      <count.../>
      <duration.../>
     <.../>
    <.../>
    <Autoguide command="stop"/>
    <Slew.../> <- slew to focus star
    <Focus.../>


This is really rough, but I hope it communicates some of what I am thinking.

One thing I am completely unsure of - can a process like Autoguide be run in a separate thread of the AcquireImages process?

cameraConfiguration requires further elaboration; I don't think it should be part of ExposeImage, it probably should be a global configuration object within your module. I'd add a fileNamePostfix parameter because there are guys out there that prefer postfixing (I know a few ) Other than these, your design looks very correct to me. Now you need an icon

This makes sense.  I will remove the camera config from the ImageExpose process.  There will just be a chooser to choose a camera that is already configured with the ImageAcquisition global preferences.  There would be a dialog that pops up telling the user to configure the camera if there are none to choose.

Thanks for the feedback!  Keep it coming as you see fit!

[David Raphael]

Also, I'd like to mention that I am a Linux and Mac fanatic ;-)  So I plan on making sure this module works with Windows, OS X and Linux.  My dream is to be able to use any environment that I want to control my rig.

Cheers,
Dave

[Emanuele]

Dave....

you are simply awesome! Pure Awesomeness.  Also highlighted by the fact that you are a Mac fanatic! I am under OSX here as well!

Thank you !

[vicent_peris]

Hi,

some ideas about the project:


first, I think that a module for controlling a CCD camera can be a good starting point. But this one alone is not quite useful because dithered exposure series are a must today. So, if you really want to make a useful tool, you need to manage the guider.

Once you have a ccd camera + guider control module, things change completely. Think that nowadays it is usual to see multi-night exposure sessions of one object. So you really only need to move the scope two times per night: one at the start of the image session and another for the meridian flip. The rest of the night is ccd camera + autoguider (and filther wheel, of course).

OTOH, please, the camera configuration buttons must be IMHO, always accesible. It's a pain to click on a tab or a button to popup a window each time you change binning or window. This is specially needed when you start the session, when you change a lot of times binning, exposure time or window to make the proper adjustments. So, if you want to put the camera setup appart from the imaging module, please put it in a separate module. This way, one can open both modules at the same time and access them quickly. Then, once the image session starts, you can close the camera setup module.


My two euro-cents,
V.