PixInsight Forum

Software Development => PCL and PJSR Development => Topic started by: Emanuele on 2010 December 30 06:33:47

Title: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Emanuele on 2010 December 30 06:33:47
....get an ImageAcquisition process?   ;D
Wouldn't it be cool to just do everything within PI (and within OSX!):  Control CCDs, FilterWheels, Plate Solving and interfacing with the planetariums.
Those are the only 4 major tools that are needed, in the end.

:)
Just dreaming...

E.
Title: Re: When will Pixinsight....
Post by: Jack Harvey on 2010 December 30 06:55:50
Would not hold my breath, such a program requires dealing with a myriad of hardware and drivers etc.  I could be wrong, but my preference is too do the image processing - and do it well.
Title: Re: When will Pixinsight....
Post by: DaveS on 2010 December 30 07:22:18
I think that could slow down the ongoing development of PI as an imaging processing resource (and dare I say, documentation for it  ;)).

Many astro-imaging CCD cameras come with image capture software, albeit mostly quite basic, and there are a number of free guiding programmes (e.g. PHD)

Astro Art offers both capture and guiding, and is not expensive. At least not when compared to it's competitors offerings.

My vote goes to keeping PI as a 'stand-alone' image processing package, continued development of new 'tools', and improvement of existing ones.

Dave
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2010 December 30 09:40:20
If some developer or development team wants to implement an image acquisition suite on PixInsight, it will be very welcome. And I agree: it would be extremely cool.

Right now PixInsight/PCL provides a rich, multiplatform development framework to implement sophisticated graphical interfaces and image processing tools. It is just a matter of putting the device drivers into action (the dirty work); everything else is very easy.

I personally won't start development of anything related to image acquisition. However, any interested developers can count on my support and assistance. PixInsight is an open-architecture system precisely to make everything possible --and it is possible, if someone decides to start a project seriously.

Packing and uploading PI version 1.6.9.651 while I'm writing this, so stay tuned ;)
Title: Re: When will Pixinsight....
Post by: RBA on 2010 December 30 15:32:41
If some developer or development team wants to implement an image acquisition suite on PixInsight, it will be very welcome. And I agree: it would be extremely cool.

Interesting! I was about to post a message with only two words:

"Delegate. Supervise."

And let those words do the talk, but in the end I decided to keep it to myself in case it wasn't quite in line with your thoughts.

Well, there you go!
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 02 01:40:57
If some developer or development team wants to implement an image acquisition suite on PixInsight, it will be very welcome. And I agree: it would be extremely cool.

Right now PixInsight/PCL provides a rich, multiplatform development framework to implement sophisticated graphical interfaces and image processing tools. It is just a matter of putting the device drivers into action (the dirty work); everything else is very easy.

I personally won't start development of anything related to image acquisition. However, any interested developers can count on my support and assistance. PixInsight is an open-architecture system precisely to make everything possible --and it is possible, if someone decides to start a project seriously.

Packing and uploading PI version 1.6.9.651 while I'm writing this, so stay tuned ;)




Ahhhhh! NICE Juan! I am glad you are with me on this! :) So now we just a need a good kind soul to develop the ImageAcquisition process! :)   Anyone, anyone?
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 04 07:49:27
Would ASCOM support be sufficient?  Or do you think that ASCOM is too much of a .NET / Windows only technology?

I have only tinkered with Javascript so far in PixInsight.  If someone where interested in exploring this idea, would Image Acquisition be a module like DBE or ACDNR, or would it tie into a different point of the PI architecture?  As I'm typing this, I'm imagining an interface where one PI workspace is running my acquisition and guider, and in another I'm processing images.

But it seems like we are still at a point in the architecture doesn't allow modules to communicate with each other.  Is this still the case?  Because when I asked about doing an image stacking module, it seemed like that was one of the limitations...

Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 04 08:32:57
David,

I know nothing on programming. But as far as GUI, I would think of an Image Acquisition module just like the ACDNR, etc. where you can choose the CCD camera, and Filter wheel, and it has controls for exposures, guider etc.
It certainly would not need to run parallel to other modules, since usually ones acquires the image only.

It could also contain a Real Time Stacking module, where PI monitors the folder where the acquired images are being saved and stacks them in Real Time to allow a preview of the final image (no calibration or anything - just a live preview)
.

Just my thoughts.
I am getting excited for this!
E.


Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 04 08:35:57
And I guess Guiding would have to be a "tab" in the module window?
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 04 13:43:10
Right :)
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 04 14:34:37
The real time monitoring sounds like a challenge to me...

It seems like that might not be possible as a Module - can anyone verify that or not?
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 05 04:55:42
Hi David, Emanuele,

I'm glad this is provoking some interest. New development projects on PixInsight are always of high priority for me (see FAQ 1.4 (http://pixinsight.com/faq/)).

Image acquisition should be implemented as a module or a set of modules written in C++ using the PCL (PixInsight Class Library) framework. JavaScript scripts can be extremely powerful --much more than what may seem--, but this is definitely something that would require a tighter integration with the PixInsight platform, which is only possible with modules.

Indeed, .NET and everything it means and involves (dependencies on Microsoft and Windows) is a problem. As you know, PixInsight is cross-platform, vendor-agnostic and open-standards-based by nature. I don't know the ASCOM platform in detail, but I have the impression that it's Windows-centric, unfortunately.

That said, I don't see any technical problem to implement something based on ASCOM and .NET using PixInsight and PCL. It would only work on Windows, which is extremely ugly, but fortunately, we have VMware and VirtualBox to run virtual machines on FreeBSD, Linux and Mac OS X.

I am no hardware expert by any stretch of the imagination, but CCD cameras should be relatively easy to control from Linux, Mac OS X and Windows if the manufacturers provide software drivers for *all* of these operating systems. And if they don't, then they should be gifted with hundreds of complaints every day :)

Whatever you decide to start, you have our support. And if you find that you need something that we don't have, then we'll implement it.

Quote
But it seems like we are still at a point in the architecture doesn't allow modules to communicate with each other.  Is this still the case?

Modules can indeed communicate (for example, each time you register two images with StarAlignment it is communicating with  file format support modules to read and write image files). However, I don't see any limitation here for an image acquisition module. How could this be a problem in this case?

Quote
The real time monitoring sounds like a challenge to me...
It seems like that might not be possible as a Module - can anyone verify that or not?

This can be done with a dedicated thread. You start a thread that retrieves the contents of a directory at regular intervals. When it detects some changes in the files stored in the directory, then it modifies some variables that other running processes are also monitoring.

With a similar scheme based on parallel threads, you can implement several functions that work concurrently. For example, you can be guiding a telescope, controlling a camera, moving a dome and showing the acquired images on the screen as soon as they appear on a directory. Threads are very powerful and efficient in PixInsight/PCL.
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 05 05:16:31
Thanks for your detailed response.

I have been considering this as a project for a while now.  I'm not committing yet ;-)  However, I may go ahead and start getting digging into the PCL - I think my misunderstanding about the architecture came from a question I asked about using PJSR here - http://pixinsight.com/forum/index.php?topic=1922.msg14728#msg14728 ... I had it in my mind that..well I'm not really sure what I had in my mind :-P

I am actually a QHY dealer - and I think if there was a legitimate set of options for image acquisition, telescope control, guiding etc... for Linux - I think the drivers would come much easier. 

And you are completely correct - it is not difficult for vendors to support multiple platforms.  SBIG does it, QSI does it and others...the easy thing would be for these damn vendors to just open source the drivers.  I think they are concerned about proprietary code, but I think they can just use a firmware style system where there is a binary they distribute that is closed source, but the actual driver runtime and API could easily be open source...but I digress...

I don't think the ASCOM approach is the right way to go the more I think about it.  However, I think that we could absolutely support ASCOM just like any other device, but it shouldn't be the basis for a PI based Image Acquisition system.  Although we might be able to take the C# interface design and use it as a starting point from a design perspective.  I will have to check their license on this.  But it would definitely be easier for vendors if the system "quacked" the same way as a well established standard like ASCOM!

I will think about this some more...anyone that has any ideas or suggestions as well - please add to this thread.  If I were to write something like this, it would be free.  I would want it to be open source - I'm not sure what license etc...but that can be discussed if something actually becomes a bit more real :-D

Title: Re: When will Pixinsight....
Post by: vicent_peris on 2011 January 09 04:22:12
Hi all,

first, I think it's not a good idea to prevent the community from doing what any user wishes. I think a project like this would not stop PI development, but improve more in the future, if this is a community project.

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.

Anyway, we can start doing simple things like managing only one instrument... I will be there to test any software. I have plenty of instruments in my univ to run the tests (from Apogee, FLI, Farchild, Astelco, PlaneWave, Meade, Bisque, etc).


Best regards,
Vicent.
Title: Re: When will Pixinsight....
Post by: mmirot on 2011 January 09 07:07:49
This is whole different animal. Testing drivers is full time job and there is always a new one.

 Run away... Run away.... :surprised:

Max
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 09 09:01:26
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
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 09 09:44:39
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.

Title: Re: When will Pixinsight....
Post by: vicent_peris on 2011 January 09 09:59:03
This is whole different animal. Testing drivers is full time job and there is always a new one.

 Run away... Run away.... :surprised:

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.
Title: Re: When will Pixinsight....
Post by: georg.viehoever on 2011 January 10 00:22:12
...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
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 10 05:31:44
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.

Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 10 08:23:12
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
Title: Re: When will Pixinsight....
Post by: mmirot on 2011 January 10 09:33:39
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

Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 10 09:59:24
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
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 11 01:48:24
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!

Quote
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 ;)

Quote
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 :)
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 11 01:58:31
Hi Max,

Quote
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 ;)
Title: Re: When will Pixinsight....
Post by: Andres.Pozo on 2011 January 11 02:18:41
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.
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 11 07:46:55
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!


Quote
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!
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 11 07:58:47
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
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 11 08:31:11
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 !

Title: Re: When will Pixinsight....
Post by: vicent_peris on 2011 January 12 17:29:26
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.
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 12 19:04:32
Thanks for the feedback.  I think I am going to implement a dynamic interface for the preview mode.  That way you can tweak things while you take repeated exposures etc...

I have already coded the Settings as a separate process.  It will all be part of the ImageAcquisition module.  ExposeImage will be a process as well...as will guiding etc...

As soon as I have something to share I will let you guys know!

Cheers,
Dave
Title: Re: When will Pixinsight....
Post by: JGMoreau on 2011 January 16 12:48:59
Cool Dave 8)

..and please include dithering in the guiding part.

JG Moreau
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 16 18:17:47


I will definitely keep dithering on the list of TODOs when I attack the guider part...

Cheers,
Dave
Title: Re: When will Pixinsight....
Post by: vicent_peris on 2011 January 17 02:26:36


I will definitely keep dithering on the list of TODOs when I attack the guider part...

Cheers,
Dave

Please, could you put dithering without autoguider??


V.
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 20 18:55:30
Just a preview of the interface so far...it is definitely not a final draft by any means ;-)

Title: Re: When will Pixinsight....
Post by: Carlos Milovic on 2011 January 20 21:25:12
You may organize it better grouping the subframe NumericControls inside one GroupBox, titled Subframe ;)
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 21 04:31:27
Extremely nice work, David!

That layout needs more spacing between items of vertical sizers. The standard is 4 pixels:

VerticalSizer v;
v.SetSpacing( 4 );
v.Add( FooControl );
v.Add( BarControl );
...


Don't be surprised if the actual spacing of items on the screen is slightly different (usually, somewhat larger). Unless you call explicitly:

Sizer s;
s.DisableAutoScaling();


PI automatically adjusts the final layout in a platform-dependent fashion.
Title: Re: When will Pixinsight....
Post by: Simon Hicks on 2011 January 21 04:51:02
Hi David,

Very impressed that this is all happening, a great effort and a big vision.

Some thoughts;
1. DSLRs would benefit from having a box to specify a mirror lock up time.
2. It would be good to have a readout somewhere that tells me what image number I am on, and how long till that particular exposure finishes.
3. I assume that the idea is that after each single exposure is taken, it is automatically downloaded and displayed with STF enabled and maybe a histogram readout and maybe some statistics displayed as well? That would be cool.
4. If the above was set up then it would be good to be able to track a few statistics graphically during the exposure sequence, like background level, FWHM etc.

Just some thoughts that you've probably already had.  8)

Cheers
         Simon
Title: Re: When will Pixinsight....
Post by: Emanuele on 2011 January 21 04:56:05
Just a preview of the interface so far...it is definitely not a final draft by any means ;-)




Wonderful work David! :)
Title: Re: When will Pixinsight....
Post by: David Raphael on 2011 January 21 05:20:57
Thanks everyone for the feedback.

Keep bringing the ideas!  It is so much easier to say "No" to a request than for me to guess what everyone wants  >:D

Simon -
1.  Regarding the DSLR support - I don't have a DSLR at the moment...but the particular feature you are talking about will be handled in the ImageAcquisitionSettings process.  It is a separate window for configuring cameras and their settings.  Every driver can add specific settings here.  However, I am glad you pointed this particular one out because it potentially may need to have some functionality exposed in the standard PixInsight driver architecture.

2.  I was thinking the same thing about the progress meter last night.  I will give it some thought, I want to make sure we "fit" nicely into the PixInsight paradigms...but I definitely think that this is a fairly different use case than most of the modules as well.  I may incorporate a progress bar for the current image being taken.  For the rest of the statistics, I think we can add those incrementally for sure.   

3.  More or less this is what I am thinking ;-)

4.  Yes - this would be pretty easy I think...and this is one of the reasons I think PixInsight can absolutely be the best app for this!


Juan -
I will add those as suggested...

Carlos -
Will do!

Emanuele -
Thanks for starting this thread ;-)
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 21 07:38:45
David,

Quote
I may incorporate a progress bar for the current image being taken.

With the appropriate configuration of threads, you can provide feedback asynchronously on the same process interface that you use to capture the images. The feedback mechanism can be as simple as a progress bar, or more sophisticated including a text log on a console embedded within your interface. Once you have it running, we can refine it later in numerous ways.

Basically, you need two elements working cooperatively:

- A thread that controls image acquisition. This thread provides two items for communication with the main thread (the main thread is the thread from which PI has started your module):

* A progress indicator. This can be an integer running from 0 to 100.
* A way to cancel the acquisition process. This is typically implemented as a global Boolean variable.

The only precaution is that all accesses to shared global variables must be protected with Mutex objects.

- A loop that watches the acquisition thread until it finishes, or if the user clicks a Cancel button, then it sets the corresponding global Boolean variable to true and waits until the acquisition thread terminates. This loop runs in the main thread. Note that only the main thread can perform GUI operations, so this thread is also responsible for providing user feedback such as a progress bar, and for capturing click events on a Cancel button, etc.
Title: Re: When will Pixinsight....
Post by: RBA on 2011 January 21 07:41:06
May I suggest moving this topic to maybe the PCL and PJSR Development area?
It doesn't bother me here but I do think it deserves its own thread ;)
Title: Re: When will Pixinsight....
Post by: Juan Conejero on 2011 January 21 07:43:28
Good point, Rogelio. I'm going to become 'Pleiades' right now to move the entire thread as a sticky in the development board.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 21 08:00:35
Quote from: Juan Conejero
The only precaution is that all accesses to shared global variables must be protected with Mutex objects.

Got it.  I will look through the source code of the other modules to see examples...I believe I've seen some Synchronize() calls scattered about...

Thanks for moving the thread!

/d
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 22 12:31:15
Couple of Questions:

When do destructors get invoked on the Process classes?  Is it only when PixInsight closes?  Is there anywhere describing the full lifecycle of the Module / Process?

How can I serialize data from a PixInsight Array<T, A>  Class?  I'm sure I can do it manually, but I figured there has to be something built in since you are marshaling objects with their instance data...

...

I keep modifying this post because I am stuck on something I think:

I want to access data in my ImageAcquisitionSettings Process from my ExposeImage Process.  But I am not sure how I want to do this exactly.  I thought about serializing the settings data...I thought about adding some static members...but I think I am missing something a bit more fundamental.  Let me describe the use case:

1.  I start PixInsight
2.  I double click the ImageAcquisitionSettings process
3.  I setup a camera or 2 in the list
4.  I close the ImageAcquisitionSettings interface
5.  I launch the ExposeImage process

At this point, I want the ExposeImage process to be able to pull the camera data from the ImageAcquisitionSettings process.  I know there is only one instance of it (or at least that's what it seems like) - I'd like to be able to access that instance.  At the same time, I feel like I may be fighting PixInsight a little bit - I might be trying to violate some encapsulation principles...

Anyone?

Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 22 19:32:04
I think I just had a "duh" moment...

So let me make sure I am thinking correctly:

When my module is installed, the "InstallPixInsightModule" function is called.  This is called everytime PixInsight starts.   The function calls the CTORs of my processes contained in the module.  Those CTORs all initialize a variable like "TheExposeImageInterface" which is scoped to the module not the class...

Therefore, I can access any of the "The<...>Interface" or "The<...>Process" etc...

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 January 23 01:46:04
Quote
When do destructors get invoked on the Process classes?  Is it only when PixInsight closes?  Is there anywhere describing the full lifecycle of the Module / Process?

Do you refer to descendants of the ProcessImplementation class? In such case, the destructor is invoked each time an instance of the corresponding class is destroyed, either within your module, or as a result of an action performed by the PixInsight Core application. In the latter case, the destructor function is called asynchronously from Core garbage collection routines via the low-level module communication API, you you'll be unable to track the calls using standard debugging techniques.

If you're referring to a reimplementation of the MetaProcess class, then this is a completely different case. In theory, the destructor of one of these reimplementations would be called in the event of the module being uninstalled by the user (via the Process > Manage Modules main menu item for example). However, for reasons beyond this post, the Core application will never unload a module's shared object (a .so, .dylib or .dll shared library). Modules are scheduled for uninstallation in PixInsight; they cannot be explicitly unloaded until the running instance of PI Core terminates. This means that your reimplementations of MetaProcess::~MetaProcess() will never be called, unless you explicitly destroy a MetaProcess descendant instance from your module, which is a nonstandard practice. Note that the same happens with MetaModule, MetaParameter, and the rest of abstract meta description objects in the PCL.

Note that your reimplementations of MetaModule::OnUnload(), in case you define them, will never be called for the same reasons. MetaModule::OnLoad() will always be called upon module installation.

Quote
How can I serialize data from a PixInsight Array<T, A>  Class?  I'm sure I can do it manually, but I figured there has to be something built in since you are marshaling objects with their instance data...

What do you refer by "serializing"? Do you mean persistently storing instances of Array<> in data streams, such as XML documents? Currently, there is no built-in XML support in PCL (this is going to change soon). You can write Array<> to binary files if you want, or you can represent Array<> as plain text. let me know if you are interested in doing this.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 January 23 01:49:33
Quote
So let me make sure I am thinking correctly:

When my module is installed, the "InstallPixInsightModule" function is called.  This is called everytime PixInsight starts.   The function calls the CTORs of my processes contained in the module.  Those CTORs all initialize a variable like "TheExposeImageInterface" which is scoped to the module not the class...

Therefore, I can access any of the "The<...>Interface" or "The<...>Process" etc...

That's correct. The "The<...>" objects are the standard mechanism in PixInsight/PCL to access module global objects. Note also that these global objects are necessary for low-level communication between the Core and your module, which is always happening behind the scenes.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 23 07:17:28
Do you refer to descendants of the ProcessImplementation class?

I think my question was too vague.  I was really trying to get clues as to which of my classes where instantiated and destroyed by PixInsight and which were persistent for the duration of the application.  I think my question about the "TheXXX..." classes is what I really cared about.  So I think I understand that.

Quote
What do you refer by "serializing"? Do you mean persistently storing instances of Array<> in data streams, such as XML documents? Currently, there is no built-in XML support in PCL (this is going to change soon). You can write Array<> to binary files if you want, or you can represent Array<> as plain text. let me know if you are interested in doing this.

Specifically, I want to store the user's camera settings without requiring them to load a process icon.  The Settings API will let me do this, but it doesn't have a convenient way for me to persist my data structures.  As a lazy Ruby developer I am spoiled :-P - so yes, I would like to serialize my Array<> to a char* that I can store using the settings API.  XML would be wasteful since it is just an internal mechanism.  I don't really care if it is human readable.  That's what the XPSM files are for ;-)


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 23 10:57:52
I have another simple question. 

I need to convert a pcl::String into an LPCSTR in Windows.

Is there a simple way to do this?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 23 11:26:51
Is this it? -

Code: [Select]
IsoString theString = GUI->CamDlg.GetDriverFile().ToIsoString();
char * chars = theString.c_str();
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 January 24 02:58:29
Quote
Specifically, I want to store the user's camera settings without requiring them to load a process icon.  The Settings API will let me do this, but it doesn't have a convenient way for me to persist my data structures.  As a lazy Ruby developer I am spoiled :-P - so yes, I would like to serialize my Array<> to a char* that I can store using the settings API.  XML would be wasteful since it is just an internal mechanism.  I don't really care if it is human readable.  That's what the XPSM files are for ;-)

Actually, that isn't difficult to do with PCL using the Settings class and a few container classes.

These static member functions of the pcl::Settings class allow you to do what you want:

bool Settings::Read( const IsoString& key, ByteArray& b )
void Settings::Write( const IsoString& key, const ByteArray& b )


A ByteArray object is a dynamic array of bytes implemented as the Array<uint8> template instantiation in PCL. ByteArray allows you to store basically anything, so it is ideal to store the contents of simple data structures.

Let's say that your camera settings are being represented with a CameraSettings class. Then all you need is adding two member functions that convert its data to/from raw binary representations:

class CameraSettings
{
public:
   ...
   void AddToRawData( ByteArray& ) const;
   ByteArray::const_iterator GetFromRawData( ByteArray::const_iterator );
};


Now you need to implement the actual export/import mechanisms. First, let's introduce a few utility routines implemented as template functions:

Code: [Select]
/*
 * Adds an object t to a ByteArray stream b.
 */
template <class T>
void AddToRawData( ByteArray& b, const T& t )
{
   const uint8* p = reinterpret_cast<const uint8*>( &t );
   b.Add( p, p+sizeof( t ) );
}

/*
 * Retrieves an object t from a ByteArray stream at the specified location i.
 * Returns an iterator located at the next position in the ByteArray stream.
 */
template <class T>
ByteArray::const_iterator GetFromRawData( T& t, ByteArray::const_iterator i )
{
   t = *reinterpret_cast<const T*>( i );
   return i + sizeof( T );
}

/*
 * Adds the contents of a string s to a ByteArray stream b.
 */
template <class S>
void AddStringToRawData( ByteArray& b, const S& s )
{
   AddToRawData( b, uint32( s.Length() ) );
   if ( !s.IsEmpty() )
      b.Add( reinterpret_cast<const uint8*>( s.Begin() ), reinterpret_cast<const uint8*>( s.End() ) );
}

/*
 * Loads a string's character contents from the specified location i on a ByteArray.
 * Returns an iterator located at the next position in the ByteArray stream.
 */
template <class S>
ByteArray::const_iterator GetStringFromRawData( S& s, ByteArray::const_iterator i )
{
   uint32 n;
   i = GetFromRawData( n, i );
   if ( n > 0 )
   {
      s.Assign( reinterpret_cast<const S::char_type*>( i ), 0, n );
      i += n * sizeof( S::char_type );
   }
   else
      s.Clear();
   return i;
}

/*
 * Template instantiations for the String type.
 */

void AddToRawData( ByteArray& b, const String& s )
{
   AddStringToRawData( b, s );
}

ByteArray::const_iterator GetFromRawData( String& s, ByteArray::const_iterator i )
{
   return GetStringFromRawData( s, i );
}

/*
 * Template instantiations for the IsoString type.
 */

void AddToRawData( ByteArray& b, const IsoString& s )
{
   AddStringToRawData( b, s );
}

ByteArray::const_iterator GetFromRawData( IsoString& s, ByteArray::const_iterator i )
{
   return GetStringFromRawData( s, i );
}

With these simple routines we have a rough implementation of ByteArray-based data streams. The implementation is indeed rough, but efficient and sufficient to our purposes. I have in mind adding more capable and elegant data stream classes to PCL but for now these simple routines should do the trick quite well.

In the above code, note that strings require specific template instantiations and specializations, as these are aggregate objects. Basically, we need to store the length in characters (not bytes!) and, if the string is not empty, the sequence of characters as a set of raw bytes. Other simple types, such as int and float, double, etc., can be stored directly.

As an example, let's suppose that your CameraSettings class only has a few data members similar to these:

class CameraSettings
{
private:
   String cameraName;
   int    imageWidth;   // in pixels
   int    imageHeight;  // ...
   float  readoutNoise; // in e-
   int    shutterSpeed; // in ms
};


Then your conversion routines would look like these:

void CameraSettings::AddToRawData( ByteArray& b ) const
{
   AddToRawData( b, cameraName );
   AddToRawData( b, imageWidth );
   AddToRawData( b, imageHeight );
   AddToRawData( b, readoutNoise );
   AddToRawData( b, shutterSpeed );
}

ByteArray::const_iterator CameraSettings::GetFromRawData( ByteArray::const_iterator i )
{
   return GetFromRawData( shutterSpeed,
             GetFromRawData( readoutNoise,
                GetFromRawData( imageHeight,
                   GetFromRawData( imageWidth,
                      GetFromRawData( cameraName, i ) ) ) ) );
}


Now all you need is storing and managing your private data streams with the Settings class. For example:

typedef Array<CameraSettings> camera_settings_container; // represents your set of supported cameras

void SaveCameras( const camera_settings_container& cameras )
{
   ByteArray data;
   for ( camera_settings_container::const_iterator i = cameras.Begin(); i != cameras.End(); ++i )
      i->AddToRawData( data );
   Settings::Write( "CameraData", data );
}

camera_settings_container LoadCameras()
{
   camera_settings_container cameras;
   ByteArray data;
   if ( Settings::Read( "CameraData", data ) )
   {
      CameraSettings camera;
      for ( ByteArray::const_iterator i = data.Begin(); i < data.End(); i = camera.GetFromRawData( i ) )
         cameras.Add( camera );
   }
   return cameras;
}


Disclaimer: code not tested, so it can contain some errors.

Hope this helps.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 January 24 06:46:34
Quote
Hope this helps.

Most definitely!
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Sean Houghton on 2011 February 02 20:10:52
Hi Dave,

Any chance you can host your source code on GitHub so people like me can contribute?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 02 21:20:04
I will post it on github soon...I need to get all the licensing sorted out etc...but I definitely plan on making this a community project!

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 05 18:43:54
Ok - so I am probably the world's worst C++ coder :-)  And when you throw COM into the mix ... along with some templates ... my head starts to hurt!

I am struggling with this code.  It is a wrapper for an ASCOM call.  The ASCOM call, ImageArray() returns a SAFEARRAY ...

This code compiles now, but I think it is fundamentally wrong.  It is really expensive to be invoking all of these functions in these loops...

So - here is what I need help with.  I need to copy this 2d array of signed integers that are buried in this SAFEARRAY (theCameraPtr->ImageArray.parray) into an Image for PixInsight!

I haven't tested this yet...I am probably going to get to that tonight or tomorrow, but in the meantime - I'd love some advice on how to make this code suck a little less.

Code: [Select]

UInt32Image PixInsightASCOMDriver::ImageArray()
{
while(!theCameraPtr->ImageReady)
{
Sleep(1000);
}

UInt32Image theImageData;
theImageData.AllocateData(theCameraPtr->NumX, theCameraPtr->NumY);
CComSafeArray< long > safeArr;
safeArr.Attach(theCameraPtr->ImageArray.parray);
long idx[2];
long val;
for(int rowIdx = 0;rowIdx < theCameraPtr->NumY; rowIdx++)
{
UInt32Image::sample* v = theImageData.ScanLine(rowIdx);

for(int colIdx = 0;colIdx < theCameraPtr->NumX; colIdx++)
{
idx[0] = colIdx;
idx[1] = rowIdx;
safeArr.MultiDimGetAt(idx, val);
UInt32PixelTraits::FromSample((pcl::int16&)val, v[colIdx]);
}
}
safeArr.Detach();
return theImageData;
}

Thanks for any help...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: zvrastil on 2011 February 06 00:42:51
Hello David,

there is a function SafeArrayAccessData, which gives you pointer to the content of the array. It is not on the ATL wrapper CComSafeArray (I'm not sure why). Try following code:
Code: [Select]
       UInt32Image PixInsightASCOMDriver::ImageArray()
        {
                while(!theCameraPtr->ImageReady)
                {
                        Sleep(1000);
}

                UInt32Image theImageData;
                theImageData.AllocateData(theCameraPtr->NumX, theCameraPtr->NumY);
                
                long HUGEP *pData;
                SafeArrayAccessData( theCameraPtr->ImageArray.parray, (void HUGEP* FAR*)&pData );

                for(int rowIdx = 0;rowIdx < theCameraPtr->NumY; rowIdx++)
{
UInt32Image::sample* v = theImageData.ScanLine(rowIdx);
                        memcpy( sample, pData+rowIdx*theCameraPtr->NumX, theCameraPtr->NumX*sizeof(long) );
                }

                SafeArrayUnaccessData( theCameraPtr->ImageArray.parray );

                return theImageData;
         }

I'm writing it from the top of my head, so there may be some error. But that's generally the idea. In case of some problem, let know.

regards, Zbynek
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 07:19:36
Thanks Zbynek -question:
Is
Code: [Select]
long HUGEP *pData;

the same as

Code: [Select]
long *pData;

On 32 bit systems?


I think it is.  I think that
Code: [Select]
long *pData;

is actually not a long.  it should be more like
Code: [Select]
SAFEARRAY *pData;

But I think I can adapt this code accordingly. 

Now this next question may be for Juan - I picked UInt32Image.  I did this because the ASCOM driver always returns a 2D array of long .  However, I was using:

Code: [Select]
UInt32PixelTraits::FromSample((pcl::int16&)val, v[colIdx]);

Which now that I look at it, should probably be int32 not int16...but regardless, I wasn't sure if this is necessary?  I noticed there seems to be a lot of cool template magic with regards to types and the images...but there isn't a Int32Image -

Or if I am completely on the wrong track here, please let me know.

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 10:06:35
Ok - I've whipped up a newer version.  

I think I was thinking that I had to access the safearray as a multidimensional array, but instead I'm accessing it as a single dim array...so I am back to a long * instead of a multidim...

Also, I read that it is not dependable to use the reported size of the image - you need to check the bounds of the array (makes sense)...so I added that change as well.

Code: [Select]
UInt32Image PixInsightASCOMDriver::ImageArray()
{
//TODO:  This needs to have some sort of time out.
while(!theCameraPtr->ImageReady)
{
Sleep(1000);
}

long *imageData;
SafeArrayAccessData(theCameraPtr->ImageArray.parray, (void **)&imageData);
int dims = SafeArrayGetDim(theCameraPtr->ImageArray.parray);
long ubound1, ubound2, lbound1, lbound2;
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,1,&ubound1);
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,2,&ubound2);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,1,&lbound1);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,2,&lbound2);

int sizeX = ubound1 - lbound1;
int sizeY = ubound2 - lbound2;

UInt32Image theImageData;
theImageData.AllocateData(sizeX, sizeY);

for(int rowIdx = 0;rowIdx < sizeY; rowIdx*=sizeY)
{
UInt32Image::sample* v = theImageData.ScanLine(rowIdx);
memcpy(v, &imageData[rowIdx], sizeX * sizeof(long));
}

SafeArrayUnaccessData( theCameraPtr->ImageArray.parray );

return theImageData;
}

My next question is - do I need to use memcpy?  I think with C++ I can just use an assignment, and the memcpy is implicit...

Also - I just thought about something...I don't think I should be copying long data directly to a sample - I think that this is a bad idea...I'm going to change that...do I need to actually copy each sample?  Or is there a bulk way to load a set of data AND convert from signed to unsigned :-) ?

Thanks for the help...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 10:19:57
Ok - that last chunk of code was my brain on drugs I think :=)  I've been writing in Ruby too long...

I was trying to iterate over rows...but I was incorrectly incrementing the row count in trying to create the offset for each row in the other array...

Anyways - I will post a new chunk of code shortly.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 10:25:08
I still can't see how to get around filling each sample individually since there needs to be a conversion from the signed long data to the unsigned int data


Code: [Select]
void PixInsightASCOMDriver::ImageArray(UInt32Image &theImage)
{
//TODO:  This needs to have some sort of time out.
while(!theCameraPtr->ImageReady)
{
Sleep(1000);
}

long *imageData;
SafeArrayAccessData(theCameraPtr->ImageArray.parray, (void **)&imageData);
int dims = SafeArrayGetDim(theCameraPtr->ImageArray.parray);
long ubound1, ubound2, lbound1, lbound2;
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,1,&ubound1);
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,2,&ubound2);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,1,&lbound1);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,2,&lbound2);

int sizeX = ubound1 - lbound1;
int sizeY = ubound2 - lbound2;

theImage.AllocateData(sizeX, sizeY);

for(int rowIdx = 0;rowIdx < sizeY; rowIdx++ )
{
UInt32Image::sample* v = theImage.ScanLine(rowIdx);
for(int colIdx = 0;colIdx < sizeX;colIdx++)
{
//v should be pointing to the current row of data we need to fill
v[colIdx] = UInt32Image::sample(imageData[sizeY*rowIdx + colIdx]);
}
}

SafeArrayUnaccessData( theCameraPtr->ImageArray.parray );
}


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 06 13:56:36
Hi David,

So if I understand it correctly, CCD raw pixel data are being acquired (through ASCOM) as signed 32-bit integers? Seems pretty odd since one might expect unsigned 16-bit integers, but if that's what ASCOM provides, then we'll have to deal with it.

So the key question here is: what numeric range are the input data referred to? In simpler words, which value corresponds to the "no signal" state (black) and which value corresponds to "full signal" (white)? Are we working with data in [0,65535] (stored as int32), or are the data bounded differently? We need to know both bounds in order to translate the input data into an output PixInsight/PCL image.

Along with that, I have a couple recommendations. First, I suggest you use an UInt16Image, instead of UInt32Image, as raw data are 16-bit unsigned pixel values (despite the way they are being provided by ASCOM).

Second, you don't need to work row by row. PixInsight/PCL images store each plane (or channel) as a contiguous block. Since it seems that your input data are also stored as a contiguous block:

Quote
imageData[sizeY*rowIdx + colIdx]

then you don't need ScanLine() and the like. Your code to transfer ASCOM data to a PI/PCL image can be simpler and faster; something like this snippet:

UInt16Image theImage;
// ...
theImage.AllocateData( sizeX, sizeY );
uint16* piImageData = *theImage;
for ( size_type i = 0, N = theImage.NumberOfPixels(); i < N; ++i )
   *piImageData++ = ASCOMDataToPI( *imageData++ );


where ASCOMDataToPI() is a function that you must define to convert a source pixel value into an output 16-bit pixel value in the range [0,65535]; its prototype would be:

uint16 ASCOMDataToPI( int32 );

The above snippet assumes that you're working with monochrome images; for multichannel images the code should be slightly more complex to work on several pixel planes.

So what's the input range of the data as it is being provided by ASCOM?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 14:17:59
What is returned is a SAFEARRAY of type Long.  COM doesn't support unsigned integers.

The ASCOM standard provides a method: ElectronsPerADU - which I think we can use to figure out what kind of data each camera uses...

But in the meantime, let's assume that the data range is -32768 to 32767 - either way there are signed values from what I see in the raw data so far. 






Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 14:30:29
so here is what I have so far:

I'm using long here since that is what is returned from the ASCOM array
Code: [Select]
uint16 PixInsightASCOMDriver::ASCOMDataToPi( long _i )
{
return _i + 32768;
}

And I made the change you suggested:
Code: [Select]
void PixInsightASCOMDriver::ImageArray(UInt16Image &theImage)
{
long *imageData;
SafeArrayAccessData(theCameraPtr->ImageArray.parray, (void **)&imageData);
int dims = SafeArrayGetDim(theCameraPtr->ImageArray.parray);
long ubound1, ubound2, lbound1, lbound2;
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,1,&ubound1);
SafeArrayGetUBound(theCameraPtr->ImageArray.parray,2,&ubound2);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,1,&lbound1);
SafeArrayGetLBound(theCameraPtr->ImageArray.parray,2,&lbound2);

int sizeX = ubound1 - lbound1;
int sizeY = ubound2 - lbound2;

theImage.AllocateData(sizeX, sizeY);

uint16 *piImageData = *theImage;
for( size_type i = 0, N = theImage.NumberOfPixels(); i < N; ++i)
*piImageData++ = ASCOMDataToPi( *imageData++ );

}

Now, the code that calls this is handing a reference to an UInt16Image...however, I am struggling with this.

Code: [Select]
  void ImageAcquisitionSettingsInterface::TestImage()
  {
  activeCamera->SetConnected(true);
  activeCamera->StartExposure(1);
  Console().WriteLn("taking exposure");
  while(!activeCamera->ImageReady())
  {
  //Console().WriteLn("camera not ready yet...");
  }
  activeCamera->SetLogger(&theLogger);
  UInt16Image img;
  activeCamera->ImageArray(img);
  ImageWindow newImageWindow(img.Bounds().Height(),img.Bounds().Width());
  Image* vImage = newImageWindow.MainView().Image() = img; 
  newImageWindow.Show();
  }

This is just a test method.  I'm trying to create an image window with the resulting data.  I've iterated on this a bit, and I think I'm doing something really wrong :-( 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 14:42:38
I just want to set the value of an Image in a ImageWindow...why is this hard for me to figure out???

Sorry if I sound a little frustrated...I am just not used to C++ templates...they really make my head hurt.

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 06 14:57:03
You must work in the opposite order: create your image window first, then get a reference to its main view (images are owned by views in PixInsight), and then a reference to the image in that view. This is an example:

Code: [Select]
ImageWindow window ( sizeX,         // width
                     sizeY,         // height
                     1,             // numberOfChannels
                     16,            // bitsPerSample
                     false,         // floatSample
                     false,         // color
                     true,          // initialProcessing
                     "camera_test"  // id
           );

View view = window.MainView();

ImageVariant v = view.Image();

UInt16Image* image = static_cast<UInt16Image*>( v.AnyImage() );

// ...

uint16* piImageData = **image;
for ( size_type i = 0, N = image->NumberOfPixels(); i < N; ++i )
   *piImageData++ = ASCOMDataToPI( *imageData++ );

// ...

window.Show();
window.ZoomToFit( false ); // don't allow zoom > 1

You actually don't need templates here, since you know in advance that your output image is a 16-bit unsigned image. That's why we can use the static_cast<>() in the above code.

Let me know if it works this way. We'll get it working, you can be sure about that ;)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 06 15:12:44
FIRST LIGHT!!!

Heheh.  Thanks Juan.  I was ready to cut off a finger :-)

We now have image data coming from a camera to PixInsight...and it loads the drivers dynamically through user configuration via the UI - this code works on Windows and OS X so far...but I only have a real driver written for ASCOM support on Windows.

Here is a screen shot of my first light.

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 06 15:24:22
WOW!   8)

Well done! Extremely well done! This is a milestone in the history of PixInsight and we must celebrate it.

Now to dream with this working on Linux and Mac OS X ... :)

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: zvrastil on 2011 February 07 00:29:17
Hello David,

I'm glad you managed the safearray in the end. It's really a big step forward. Two notes:

1) I would be really surprised if ASCOM images are scaled to -32768..32768. They're using long (= int) so the actual range of one value is -2,147,483,648 to 2,147,483,647. The actual range of the provided values should be 0 to Camera.MaxADU (-> property of the camera driver).

2) The image on your screenshot has all pixels in each row equal. If this is not somehow caused by camera, it is likely some bug in your code, causing every row to be filled with only one pixel value. Worth of checking.

Good work.

regards, Zbynek
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Emanuele on 2011 February 07 04:29:31
David,
Sorry to interrupt the programming discussion but I am typing this to congratulate you with this milestone! :)
I can see myself already acquiring with PI on a beautiful starry night!

Thank you!
E.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 07 04:54:51
Hello David,

I'm glad you managed the safearray in the end. It's really a big step forward. Two notes:
Thanks
Quote
1) I would be really surprised if ASCOM images are scaled to -32768..32768. They're using long (= int) so the actual range of one value is -2,147,483,648 to 2,147,483,647. The actual range of the provided values should be 0 to Camera.MaxADU (-> property of the camera driver).
I was surprised too.  The values coming from the driver are negative - but it may just be a bug.  Their is definitely more work to do.
Quote
2) The image on your screenshot has all pixels in each row equal. If this is not somehow caused by camera, it is likely some bug in your code, causing every row to be filled with only one pixel value. Worth of checking.
It is the camera - I compared it to Maxim.  It is just a CMOS guider pointed at junk on my desk.  It has a line noise reduction routine - which creates a strange BIAS pattern.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 07 07:04:03
The more I think about it - the more I think you are right, Zbynek...it doesn't make any sense for the values to be negative.  I probably need to revisit this code:

Code: [Select]
  long *imageData;
  SafeArrayAccessData(theCameraPtr->ImageArray.parray, (void **)&imageData);

Because this is where I am seeing negative values.  You mention that they are using long (=int), but I see them using Long - isn't that a 64-bit value?
Here is a reference from MS:
http://msdn.microsoft.com/en-us/library/y595sc15.aspx

Either way, it does seem odd to me that there would be any negative values.  ESPECIALLY with a property like MaxADU - it would have broken meaning if there were negative values I think.

I am going to take a much closer look at all of this now that the basic plumbing is in place.

Thanks for your feedback - I greatly appreciate it.

-dave


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: zvrastil on 2011 February 07 08:56:36
Because this is where I am seeing negative values.  You mention that they are using long (=int), but I see them using Long - isn't that a 64-bit value?
Here is a reference from MS:
http://msdn.microsoft.com/en-us/library/y595sc15.aspx

Hi Dave,

in C++ and on both 32bit and (oddly enough) 64bit Windows, size of long is equal to 32 bits. The page you're refering to concerns CLR (.NET languages like C# or Visual Basic).
Hope you solve it soon, negative values seem really strange.

BTW, I see on ASCOM pages http://ascom-standards.org/Downloads/PlatformUpdates.htm (http://ascom-standards.org/Downloads/PlatformUpdates.htm), that there is an ASCOM Camera Simulator software. Maybe, it could be good tool for development and testing. With it, you should know what to expect. In general, simulators are very handy when writing hardware-dependent code.

regards, Zbynek
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 07 09:37:30
Regarding Long - since the ASCOM spec says that it is Long - I think that I may need to pass a different type to pull data from the array.  It makes sense that copying data from a 64bit to a 32bit would be a problem  ;-)

I've been posting messages regarding the camera simulator to the ASCOM-Talk board...it is not working for me currently.  I've tried 2 different versions of the simulator too.  I agree - having the simulator would be grand...

I received definite confirmation that there should be no negative values...

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2011 February 07 09:48:03
You may try using int32 (defined by the PCL) instead of long...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 07 10:52:26
When I get home I will try that...


Thanks!

-Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 07 20:30:13
uint32 worked like a champ.  No more negative values.  Screenshot attached ;-)

BTW - The lines were from the driver before.  I disabled the "Line Noise Reduction" option in the driver.  Hopefully I can get the simulator working so I don't always have a camera hooked up ;-)

Screenshot attached...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2011 February 07 20:49:43
Excellent :D
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 08 08:28:18
And just to show that I am testing more than one platform...here is a screen from Mac OS X -

I've written a test driver for Mac OS X - it is basically a simulator.  I will probably port the simulator to each platform so that people that want to write native PixInsight drivers will be able to see some sample code...

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 12 09:51:27
I am running into a weird behavior.  I am trying to throw an exception when a user tries to create 2 cameras with the same name.  However, when I throw the exception it somehow corrupts the button that was last clicked..

Code: [Select]

  void ImageAcquisitionSettingsInterface::__CameraListButtons_Click( Button& sender, bool checked )
  {
    if(sender == GUI->AddCamera_PushButton)
{
try
{
Console() << "AddCamera clicked\n";
AddCamera();
UpdateCameraList();
} catch( ... )
{
throw Error("Please use unique name for each camera.");
}
}
...

So when this code throws, the GUI->AddCamera_PushButton no longer sends events (at least the click event no longer seems to reach the function I have registered as the OnClick(..))  The other buttons still send events to the same event handler...


Let me know if you have any ideas!


Is this a bad way of handling errors with PCL?  Originally, I was throwing from the AddCamera method and not catching in the event handler.  But that doesn't make a difference either. 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 12 10:17:55
Hi David,

As a general rule, no exception should propagate from an event handler. You must catch and process all exceptions thrown within the event handler function. For example:

#include <pcl/ErrorHandler.h>

...

if ( sender == GUI->AddCamera_PushButton )
{
   try
   {
      Console() << "AddCamera clicked\n";
      AddCamera();
      UpdateCameraList();
   }

   ERROR_HANDLER
}

...


The ERROR_HANDLER macro (declared in pcl/ErrorHandler.h) will do the necessary work for you. However, you should throw the correct exceptions from the appropriate locations in your code. In this case, the following exception:

      throw Error("Please use unique name for each camera.");

should probably be thrown from your AddCamera function. The ERROR_HANDLER macro will automatically generate the appropriate error messages for all Error exceptions, and also for other types of exceptions, including allocation errors and even unknown exceptions. ERROR_HANDLER used as above guarantees that no exception will be thrown by your event handler.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 12 10:46:45
Perfect - that fixed my problem...

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 17 22:04:36
This may be an obvious C++ thing, but the following code doesn't compile on OS X:

Code: [Select]
Console() << "foo";

This works though:

Code: [Select]
Console c = Console();
c << "foo";

I am not too worried about it either way...but I was just wondering if this is just one of those MSVC things that let's non-standard C++ slip by ;-)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 18 00:19:51
Hi David,

That's a very strange error; it shouldn't happen. The code you're using:

Console() << "foo"; // *1*

is perfectly valid. It isn't the recommended way unless you only have to write something to the console sporadically, but it is legal. If you have to generate more output, the following code is more efficient:

Console console;
...
console << "foo";
console.Write( "foo" ); // equivalent to the previous sentence
console.WriteLn( "foo" ); // more efficient than 'console << "foo\n"'


because each time you call Console's constructor you're generating a new low-level handle in the core application, which is destroyed when the implicitly generated high-level object in your module gets out of scope (that is, in the same sentence if you use *1* above).

Anyway, as I've said your original intent should be compiled without any issue. What version of GCC are you using on your Mac? Open a terminal window and enter this command:

gcc -dumpversion

It should be 4.2.1. It is the default compiler in OS X Snow Leopard, which I assume you are using. PCL is not compatible with GCC < 4.2 on Mac OS X.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 18 06:29:08
Here is my compiler:
i686-apple-darwin10-gcc-4.2.1

Here is the compiler output:

Code: [Select]

../../ImageAcquisitionSettingsInterface.cpp: In member function ‘void pcl::ImageAcquisitionSettingsInterface::AddCamera()’:
../../ImageAcquisitionSettingsInterface.cpp:181: error: no match for ‘operator<<’ in ‘pcl::Console() << "AddCamera()\012"’
/Users/draphael/PCL/include/pcl/String.h:4692: note: candidates are: pcl::IsoString& pcl::operator<<(pcl::IsoString&, const pcl::GenericString<char, pcl::IsoCharTraits, pcl::StandardAllocator>&)


I definitely agree that it is inefficient to make the call that way each time, but I was still intrigued by the behavior - I agree with you that it should be perfectly legal. 

Thanks,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 22 13:14:32
I am working on the threading code now.  I have some concerns:

I am using something like this code in my ExecuteGlobal() function:
Code: [Select]
...
exposeThread = new ExposeImageThread( TheImageAcquisitionSettingsInterface->activeCamera, exposureDuration, exposureCount);
exposeThread->Start( );

while( exposeThread->IsExposing() )
{
    //console << "exposing .... \n";
    pcl::Sleep(.01);
    ProcessInterface::ProcessEvents();
}

return true;

But this of course leaves the rest of the UIs locked - I think we will want the rest of PixInsight to keep running as normal while capturing.  Is this just an option?  Do I need to enable parallel processing on this instance or something like that?

Alternatively, I tried spinning up the thread and exiting the ExecuteGlobal() before the thread is finished...this definitely didn't make PixInsight happy.

Also, I guess it is a no-no for a thread to make calls that create ImageWindows :-)  <- I guess this is part of your design?  This is easy enough to process on the main ExposeImageInstance object anyways...but I was just curious.

Let me know what you think.

Regards,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 22 13:38:44
And to continue this a bit...

Should I even use ExecuteGlobal()?  I guess this isn't really operating on any kind of images...so I guess I'll just implement my own method? 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 22 16:40:18
Hi David,

Before continuing, at this point you must decide how you want to implement your process:

(1) As a synchronous process. Think of your tool as if it was a special version of the NewImage process. NewImage creates new images from a set of user-defined parameters (image geometry, color space, etc.). Your process would create new images as a result of an acquisition task initiated by the user (we'll see how later). Pros: Easy to implement, relatively simple and rock-solid implementation. Cons: as this is a synchronous task, the whole PixInsight platform has to wait until the image acquisition process is either completed or aborted.

(2) As an asynchronous process. Think of it as a special variation of the Statistics tool. Statistics is an observer. Your process isn't an observer, but it shares with Statistics the fact that it cannot be executed, neither in an image context nor in the global context. In this case your interface governs your process completely, something that Statistics also does. It has no standard execution button in its control bar (neither a triangle nor a sphere) and cannot generate instances (no process icons). You just have a button that reads 'Start' or something like that. The user presses 'Start' and your task is launched by the button's event handler. Your process must be implemented as an asynchronous thread that works in the background. Pros: Versatile implementation. PixInsight continues working normally while your process runs in the background. Cons: Complex and risky implementation. There are many potential stability issues. For example, what happens if the user terminates the application while your background thread is running? There are currently no provisions to assist you in this case (this may change in a future version though). There are possible interactions with other processes that you cannot know in advance. Basically, you have no control once your task has been launched because your interface returns to the main GUI thread immediately.

Option 2 may seem attractive, and it is doable, although it requires a lot of work that would distract you from your main development work. Personally I think option 2 is a bad option for other reasons. My recommendation is that you implement option 1. Then once you have your acquisition process well tested and debugged, converting it to option 2 isn't too difficult, although I doubt it is really interesting. I understand that what you don't like of option 1 is the fact that PI gets 'frozen' while your task is running. Well, that isn't as bad as it sounds; it is actually very good! After all, PI gets frozen with any regular process. For example, think of a long ImageIntegration process. Along with the fact that there is actually no freeze, remember that you can execute up to 256 simultaneous instances of the PI Core application, so you can have one instance acquiring images and another one working normally.

So let's assume that you think it ... ... ... OK, and you choose option 1 ;D

Several important considerations:

- Forget about ExecuteGlobal(). You don't want your process executed in the global context. The reason is that when a process is executed, the whole PI GUI —including your interface— are disabled and no user interaction, besides moving windows, is allowed. You definitely don't want this.

- As happens with option 2, you have a Start button (or an 'Acquire' button or whatever you want to call it). What happens when the user clicks Start? Easy: you open a modal dialog, launch your process as a thread, and enter a waiting loop very similar to your snippet. A modal dialog allows you: (a) ensure that you have a working GUI to provide feedback to the user, and (b) ensure that only your GUI can be used during the whole acquisition process. In other words, you have full control.

- Your process interface allows you to perform maintenance tasks such as defining cameras, working parameters, etc. But once your Start button gets pressed, your modal dialog does the job. This is a typical divide and conquer strategy.

- You cannot create image windows from a thread. Only the GUI thread (the main PixInsight Core thread, from which your Start button's OnClick() event handler is called) can perform GUI operations. A thread cannot communicate using GUI resources in any way.

So your next question is how can I create an image window during the acquisition process? Well, the following code is an example of how the whole thing would look like:

Code: [Select]
struct ExposeImageData
{
   ExposeImageData() :
   mutex(), image(), imageProgress( 0 ), imageReady( false ),
   abort( false ), error( false ), errorMessage()
   {
   }

   Mutex       mutex;         // To protect data from concurrent accesses
   UInt16Image image;         // The image being acquired
   int         imageProgress; // Progress indicator, e.g. from 0 to 100
   bool        imageReady;    // Flag true if a new image is now ready
   bool        abort;         // Flag true if the user wants to abort
   bool        error;         // Flag true if an error occurs
   String      errorMessage;  // Error information
   ... // more stuff
};

ExposeImageData data;

class ExposeImageThread : public Thread
{
public:
...
   virtual void Run()
   {
      while ( true )
      {
         // Check if the user has aborted the process
         if ( data.abort )
         {
            ... possibly perform some cleanup here
            break;
         }
      
         ... do your acquisition stuff here

         // Check possible errors
         if ( error )
         {
            data.mutex.Lock();
            data.error = true;
            data.errorMessage = "Hmm, something went wrong...";
            data.mutex.Unlock();
            break;
         }

         // Update the progress indicator
         data.mutex.Lock();
         data.imageProgress++;
         data.mutex.Unlock();

         // Do we have acquired a new image?
         if ( acquisitionComplete )
         {
            data.mutex.Lock();
            data.imageReady = true;
            data.imageProgress = 100;
            data.mutex.Unlock();
         }

         // Job done?
         if ( finishedAcquiringImages )
            break;
      }
   }
};

class ExposeImageDialog : public Dialog
{
public:

   ExposeImageDialog() : Dialog()
   {
      ... build your dialog here

      // Handle Abort button click events
      Abort_PushButton.OnClick( (Button::click_event_handler)&ExposeImageDialog::__Button_Click, *this );

      // Attach your own dialog execution handler, so you gain control
      // as soon as your dialog is executed modally.
      OnExecute( (Dialog::execute_event_handler)&ExposeImageDialog::__Dialog_Execute, *this );
   }

   void __Dialog_Execute( Dialog& sender )
   {
      // Here we are. Now we are the *only* element of PixInsight
      // that can be used interactively by the user. Since this has
      // been called by the GUI thread, we can do anything we want
      // with GUI resources.
  
      // This is your original snippet
      
      exposeThread = new ExposeImageThread( TheImageAcquisitionSettingsInterface->activeCamera, exposureDuration, exposureCount );
      exposeThread->Start();

      while ( exposeThread->IsExposing() )
      {
         //console << "exposing .... \n"; <-- ups, forget about this; there is no console available at this point!
         pcl::Sleep( .01 );
         ProcessInterface::ProcessEvents();

         // Now let's see if we have an image ready
         data.mutex.Lock();
         bool myImageReady = data.imageReady;
         data.mutex.Unlock();
         if ( myImageReady )
         {
            ... code to create a new image window
         }
      }

      if ( data.error ) // note that the thread is not running at this point
      {
         MessageBox( data.errorMessage, ... ).Execute();
      }

      ...
   }

   void __Button_Click( Button& sender, bool checked )
   {
      // Handle the Abort button
      if ( sender == Abort_PushButton )
      {
         data.mutex.Lock();
         data.abort = true;
         data.mutex.Unlock();
      }
      else ... // handle other buttons
   }
  
};

// This is your interface class

class ExposeImageInterface : public ProcessInterface
{
public:
   ...

private:

   void __Button_Click( Button& sender, bool checked )
   {
      // Handle the Start button
      if ( sender == Start_PushButton )
      {
         ExposeImageDialog dialog;
         dialog.Execute();
      }
   }
  
};

This is just an example to show you how the different parts would work. Of course, the acquisition task could be implemented without a thread. however, a thread leads to a more modular implementation and allows for an easier adaptation of the whole engine to another paradigm in the future, such as option 2 above.

As always, code not tested at all. Hope this helps you to start running in the right direction :)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 22 20:06:01
Thank you for the response...

So this makes me a little sad :-(

The reason I say that is because I was imaging a process container that I could stuff a bunch of different ExposeImage by dragging the triangle to the process container...using this I could do the same for Autofocus, etc...

But I guess that the process container isn't really sufficient for the camera control paradigm...however, I was trying to take advantage of the infrastructure you've laid out!!!

I will ponder this for a day or 2...maybe there is another option that I am not considering...

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 00:45:11
David,

Quote
I was imaging a process container that I could stuff a bunch of different ExposeImage by dragging the triangle to the process container...

Nothing stops you from doing that. You can implement both an instantiable global process and a modal dialog as I have described above. Instead of relying on a Start button on your interface, make your process a regular global process and write your ExecuteGlobal() as follows:

Code: [Select]
class ExposeImageInstance : public ProcessImplementation
{
public:
   ...
   virtual bool CanExecuteGlobal( String& whyNot ) const
   {
      return true;
   }

   virtual bool ExecuteGlobal()
   {
      ExposeImageDialog dialog;
      dialog.Execute(); // this is the image acquisition dialog
      return !thereAreErrors;
   }

   ...
};

The ExposeImageDialog that you open on your ExecuteGlobal routine is a modal dialog that works independently on your ExposeImageInterface; both GUI elements are unrelated and independent.

If you want to implement a process in the 'Pure PixInsight Way'TM then you're done. But if you wish, you can also implement a Start button in your interface. In this case, things are really simple because you can execute your own process globally from your Start button event handler:

Code: [Select]
class ExposeImageInterface : public ProcessInterface
{
public:
   ...

private:

   // This is the instance that you are editing on your interface.
   // It has the current definitions of cameras, working settings, etc.
   ExposeImageInstance instance;

   void __Button_Click( Button& sender, bool checked )
   {
      // Handle the Start button
     
      if ( sender == Start_PushButton )
      {
         instance.LaunchGlobal(); // execute our instance globally
      }
   }
   
};

Personally I like this way, because it adheres much better to the object oriented design in PixInsight. Let me know if this helps you further.

This is a relatively 'atypical' process in PixInsight so we have to devise new ways of doing what we want. I think the platform is flexible enough to accommodate your acquisition process without any problem.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 08:12:20
Quote
Personally I like this way, because it adheres much better to the object oriented design in PixInsight. Let me know if this helps you further.

I agree - here is my idea overall:

If you remember from my earlier post, the ImagingSession Process was a way to run several steps of an imaging run together.  I actually think this will be a process container itself - but with imaging specific options.  And maybe process container is the wrong terminology.  Basically, here is an example workflow I am imagining:

1.  Create new ImageSession by double clicking the ImageSession Process
2.  Create new ExposeImage process and configure for L-filter -> drag the little triangle to the ImageSession Process
3.  etc...

I've created a mockup to describe this idea.  It isn't pretty, but I wanted to capture this in case anyone wants to provide any feedback...

The reason for this separate ImageSession concept, is that we will need to orchestrate Dithering, Errors, Guiding etc... and it will allow for a nice place to manage the whole process once it is kicked off.

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 11:37:58
Hi David,

Nice idea. It can be done without problems right now. Do you know how the ScreenTransferFunction and HistogramTransformation tools work together? As you probably know, you can drag a STF icon to HT's control bar, and HT imports the STF instance. Similarly, you can drag an HT icon to STF.

As long as all processes are defined in the same module, they can share/import instances. You have the full source code of the IntensityTransformations module in all PCL distributions, so you can see how this works for HT and STF; what you want to do is just the same, basically.

This is a skeleton of how you should work with several instances in your ImagingSessionInterface:

Code: [Select]
bool ImagingSessionInterface::ValidateProcess( const ProcessImplementation& p, String& whyNot ) const
{
   if ( dynamic_cast<const ExposeImageInstance*>( &p ) == 0 &&
        dynamic_cast<const AutoFocusInstance*>( &p ) == 0 )
   {
      whyNot = "Must be an instance of either ExposeImage or AutoFocus.";
      return false;
   }

   whyNot.Clear();
   return true;
}

bool ImagingSessionInterface::ImportProcess( const ProcessImplementation& p )
{
   const ExposeImageInstance* ei = dynamic_cast<const ExposeImageInstance*>( &p );
   if ( ei != 0 )
   {
      // We are importing an ExposeImage instance
      ...
   }
   else
   {
      const AutoFocusInstance* af = dynamic_cast<const AutoFocusInstance*>( &p );
      if ( af != 0 )
      {
         // We are importing an AutoFocus instance
         ...
      }
      else
      {
         // Hmmm, this is odd; this cannot happen because we have validated
         // the instance to ensure it is either ExposeImage or AutoFocus
         return false;
      }
   }

   return true;
}

Right now an instance can only be imported by a process interface by dragging it to its control bar. You cannot drag an instance to a control inside a process interface. That would be very nice because in that way the drag&drop actions would be more intuitive. I'll think on a way to overcome this limitation.

Besides that cosmetic limitation, you can import different instances as above, then allow the user to move them up and down on your interface to refine the sequence, if necessary.

HTH
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 11:43:21
Excelente!

One quick question regarding the Image - before, I remember having trouble creating an ImageWindow and then passing image data to it...can I create the UInt16Image and then pass it to an ImageWindow?  Or do I can I copy the data to the window?  Basically set the ImageWindow data to different images?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 11:54:28
Nope, you must create the ImageWindow and work on the image in its main view. You cannot replace the image in a view.

However, you can assign any image to the current image in a view, which is essentially the same thing you're asking for. Recall that you get access to a main view with ImageWindow::MainView(), then you get access to the image as an ImageVariant with View::Image(); we have seen this just before your first light. (http://pixinsight.com/forum/index.php?topic=2681.msg19140#msg19140)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 11:58:53
One further question. AutoFocus and ExposeImage are executable processes? In other words, can I execute an instance of ExposeImage without needing an ImagingSession?

If the answer is yes, then why can't you rely on ProcessContainer? After all, ImagingSession is defining an ordered sequence of processes. Note that ProcessContainer is exactly that. You can execute a ProcessContainer in the global context (as long as all of its contained instances can be executed globally).

On the other hand, I understand that defining a specialized container such as ImagingSession leads to a more intuitive and easy-to-use implementation, so I am not against your idea. I just want to fix the concepts.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 12:02:45
Quote
One further question. AutoFocus and ExposeImage are executable processes? In other words, can I execute an instance of ExposeImage without needing an ImagingSession?

Yes.

Quote
If the answer is yes, then why can't you rely on ProcessContainer?
I think we can use ProcessContainer...
but then we won't have the nice modal dialog reporting all the progress, FWHM monitor etc...?


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 12:05:17
...you can assign any image to the current image in a view...
Would the thread be able to assign that?  It seems that would be the case by using the ExposeImageData struct?  But I thought that the thread couldn't call anything that updates the UI?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Pleiades on 2011 February 23 12:11:09
Quote
but then we won't have the nice modal dialog reporting all the progress, FWHM monitor etc...?

Correct. That's why your ImagingSession container makes a lot of sense.

Would the thread be able to assign that?

Yes, a thread can modify an image, even if it is an image living in the core application (inside a view). As long as you guarantee that two or more threads won't modify the same pixel concurrently (using mutexes if required), everything will be fine.

Quote
But I thought that the thread couldn't call anything that updates the UI?

A thread cannot perform any GUI operation. However, writing and copying pixels has nothing to do with the GUI. What a thread cannot do, for example, is call ImageWindow::Show() for example. As long as the operations that you carry out don't imply (directly or indirectly) a GUI update —which means drawing on the screen, essentially—, there should be no problems.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 12:16:55
Ooops! yeah, it was me. I forgot to become myself again  :laugh:
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 12:23:32
Ok - so the change I just made is crashing PixInsight at startup:

Code: [Select]

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib              0x00007fff836d6616 __kill + 10
1   libSystem.B.dylib              0x00007fff83776cca abort + 83
2   libstdc++.6.dylib              0x00007fff886905d2 __tcf_0 + 0
3   libobjc.A.dylib                0x00007fff81cd4d3d _objc_terminate + 120
4   libstdc++.6.dylib              0x00007fff8868eae1 __cxxabiv1::__terminate(void (*)()) + 11
5   libstdc++.6.dylib              0x00007fff8868eb16 __cxxabiv1::__unexpected(void (*)()) + 0
6   libstdc++.6.dylib              0x00007fff8868ebfc __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
7   ...iades-astrophoto.PixInsight 0x0000000100ebf4ec pcl::CriticalSignalHandler(int) + 284
8   libSystem.B.dylib              0x00007fff836e867a _sigtramp + 26
9   ImageAcquisition-pxm.dylib    0x000000012940766e pcl::Thread::IsRootThread() + 14
10  ImageAcquisition-pxm.dylib    0x00000001294066c9 pcl::StatusMonitor::__Reset() + 25
11  ImageAcquisition-pxm.dylib    0x0000000129402336 pcl::AbstractImage::AbstractImage() + 262
12  ImageAcquisition-pxm.dylib    0x0000000129400bbe pcl::Generic2DPixelData<pcl::UInt16PixelTraits>::Generic2DPixelData() + 22 (PixelData.h:192)
13  ImageAcquisition-pxm.dylib    0x0000000129400c68 pcl::Generic2DImage<pcl::UInt16PixelTraits>::Generic2DImage() + 22 (Image.h:257)
14  ImageAcquisition-pxm.dylib    0x0000000129400ce0 pcl::ExposeImageData::ExposeImageData() + 40 (ExposeImageInstance.cpp:9)
...

So it looks like there is a problem initializing that UInt16Image image - do I need to create this somewhere else?

Here is the code:

Code: [Select]
#include "ExposeImageInstance.h"

namespace pcl
{
    struct ExposeImageData
    {
       ExposeImageData() :
       mutex(), image(), imageProgress( 0 ), imageReady( false ),
       abort( false ), error( false ), paused( false ), errorMessage()
       {
       }

       Mutex       mutex;         // To protect data from concurrent accesses
       UInt16Image image;         // The image being acquired
       int         imageProgress; // Progress indicator, e.g. from 0 to 100
       bool        imageReady;    // Flag true if a new image is now ready
       bool        abort;         // Flag true if the user wants to abort
       bool        error;         // Flag true if an error occurs
       bool        paused;
       String      errorMessage;  // Error information
    };

    ExposeImageData data;
    class ExposeImageThread: public Thread
    {
...

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 February 23 12:33:11
Ah, I know why this happens :)

You are declaring an instance of ExposeImageData in this way:

static ExposeImageData data;

(with or without the static storage class). Here is the problem, because the UInt16Image constructor (called by ExposeImageData::ExposeImageData()) needs to access some core resources that aren't yet available when your module is being installed. Instead of an automatic variable, declare a pointer:

static ExposeImageData* data = 0;

and initialize it somewhere if it is zero:

if ( data == 0 )
   data = new ExposeImageData;


Does this help you?

Note— this should not lead to a crash, but to an error message, so as a bonus you've discovered a bug :)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 23 13:34:31
Note— this should not lead to a crash, but to an error message, so as a bonus you've discovered a bug :)

Sweet!

Quote
and initialize it somewhere if it is zero:

if ( data == 0 )
   data = new ExposeImageData;


I guess it will get cleaned up when PixInsight exits?

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 February 26 13:58:56
I am probably beating a dead horse here ;-)

I know I keep asking questions about UI updates without occupying the rest of PixInsight...but I think this one is a little different.

I'd like to periodically update the ExposeImageInterface with the actual sensor temperature of the camera.  Is there anyway for me to do this?  It is similar to the way an interface can respond to a View event...?  The desired use case is to connect the camera, set the temperature and then the interface will display the current temperature for the camera...

Let me know what you think.

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 07 13:51:53
Quote
and initialize it somewhere if it is zero:

if ( data == 0 )
   data = new ExposeImageData;


I guess it will get cleaned up when PixInsight exits?

As a safety and good programming procedure, you should implement a destructor for your ExposeImageData class, in case it is necessary (e.g. if you have allocated some ojects dynamically in ExposeImageData's constructor).

However, since the 'data' object won't be destroyed  explicitly (because you won't call 'delete data', will you), it is unlikely that ExposeImageData's destructor will ever be called. Your object will live as long as your module is not unloaded. As PixInsight doesn't unload installed modules (a module can only be 'scheduled for uninstallation' upon the next execution of PI Core), your 'data' object will be automatically deallocated when PI exits, but its destructor won't be invoked.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 07 14:20:51
Quote
I'd like to periodically update the ExposeImageInterface with the actual sensor temperature of the camera.  Is there anyway for me to do this?  It is similar to the way an interface can respond to a View event...?  The desired use case is to connect the camera, set the temperature and then the interface will display the current temperature for the camera...

There are several ways. Perhaps the simplest and most efficient way is using a timer. A timer can work in two modes: in single-shot mode and in periodic mode. The timer generates timer events, and you can attach a member function of your interface class to capture these events. In single-shot mode, the timer generates a single tick event when the specified interval has elapsed. In periodic mode, successive timer events are generated at regular intervals. This is just what we want.

In your interface class (for example, ExposeImageInstance), you must include a Timer object as a data member, and a timer event handler as a member function:

Code: [Select]
#include <pcl/Timer.h>

class ExposeImageInstance : public ProcessImplementation
{
public:

   ...

private:

   ...

   // The timer used to update camera data at regular intervals
   Timer UpdateCameraData_Timer;

   ...

   // Timer event handler
   ExposeImageInstance::__UpdateCameraData_Timer( Timer& sender )
};

Then when you construct your GUI subobject, the timer must be initialized and the event handler connected to it:

Code: [Select]
ExposeImageInstance::GUIData::GUIData( ExposeImageInstance& w )
{
   ...
   UpdateCameraData_Timer.SetInterval( 0.5 );
   UpdateCameraData_Timer.SetPeriodic( true );
   UpdateCameraData_Timer.OnTimer( (Timer::timer_event_handler)&ExposeImageInstance::__UpdateCameraData_Timer, w );
   ...
}

Somewhere in your code you must fire the timer; for example when the user starts a new exposure, or where appropriate:

Code: [Select]
   // Start generating timer events
   GUI->GUI->UpdateCameraData_Timer.Start();

Finally, this is how your timer event handler should look like:

Code: [Select]
ExposeImageInstance::__UpdateCameraData_Timer( Timer& sender )
{
   if ( sender == GUI->UpdateCameraData_Timer )
   {
      // Will get here every 0.5 seconds

      ... perform the updates here ...

      // You'll have to stop the timer when no more updates are necessary.
      if ( no-more-updates-required )
         GUI->UpdateCameraData_Timer.Stop();
   }
}

Let me know how this works.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 07 14:28:29
I forgot to mention something important about timers. Timer events won't be generated unless you allow PI Core to process events at a reasonable rate. This means that if you have PI's GUI blocked (for example within a loop in your ExecuteGlobal() routine), then you should call ProcessInterface::ProcessEvents() regularly. The more often you process events, the more accurate the timing interval will be and the less chances to lose timer events. However, don't call ProcessEvents() too often because that may have a strong impact on the performance of your module.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 March 07 14:30:20
So if I am not running the ExposeImage process - it is just sitting idle, can I still spin up a timer that periodically updates the UI?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 07 14:54:14
Yes, the timer will run since you call its Start() member function until you call Stop(). The timer will work in the background, and your event handler will get called regularly. The only exception is that it won't be called during CPU intensive routines that don't process UI events. Other than that, it will work normally.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 March 15 10:55:22
Quote
I'd like to periodically update the ExposeImageInterface with the actual sensor temperature of the camera.  Is there anyway for me to do this?  It is similar to the way an interface can respond to a View event...?  The desired use case is to connect the camera, set the temperature and then the interface will display the current temperature for the camera...

Let me know how this works.


This worked perfectly!  I had tried to use a timer before, but I guess I was doing something wrong...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 18 01:33:23
Good to know David! How is this project going on? Impatient...  >:D
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 March 18 14:16:02
Quote
Good to know David! How is this project going on? Impatient...

The project is going slowly right now.  I was out of town this week on vacation, and I was able to work on it for several hours.

I plan on releasing a version very soon...

Let me give you a specific idea of where I am:
Code: [Select]
TODOs:
 [x] Implement cross platform driver for devices
  [x] Camera
  [x] Filter Wheel
 [ ] Implement Device Simulators
  [x] Camera
  [/] Filter Wheel (50%)
 [x] Unify Current Camera logic across processes (currently there is a direct
  access to the pointer...not good)
 [ ] Wire up filterWheelData as a globally shared object (similar to cameraData)
 [ ] ExposeImage process / instance / interface
  [x] Duration
  [x] Qty
  [x] Camera Connection Logic
  [x] Threading for global execution
  [ ] Filter selection
  [/] Implement FileOutputPattern stuff (50%)
  [ ] Fix range sliders.  Perhaps use a different UI paradigm.
  [x] Implement Temperature Monitoring / UI updates
  [ ] Implement Set Temperature
  [ ] Implement Frame and Focus
  [ ] Implement Sub Frame Exposure
 [ ] ImageAcquisitionSettings process / instance / interface
  [x] Camera
  [ ] Filter Wheel Settings
  [/] Implement Serialized Settings Persistance (85%)
  [ ] Implement Default Camera Driver ( maybe just in Windows? )
 [x] Add thread safety for Camera Data access
 [ ] Implement error handling across the different user interactions
 [ ] Expose scripting interface (make sure that the std paradigms that PI offers are
  adhered to)


This list of todos is not very complete.  I've completed other items before I started creating a TODO list.

Also, I started working on the ImageSession UI and realized that I better finish the expose image stuff first.  The first version that I release will not have a UI while exposing.  I've also been considering using JavaScript to prototype the UI first - since all of the components I am working on are designed to be pluggable in a script, I think this will be a good way to validate that users can leverage the camera control as they wish.  This is the essence of why I think PixInsight will make such a great Imaging platform.

I should be releasing a preview to the public soon.  I still plan on hosting the code on github...

I am not the best at articulating ideas - I tend to focus on writing code and not rhetoric ;-)


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 March 18 17:06:57
I'm stuck on an issue with the serialization stuff I've been working on.  Perhaps you can help me figure this one out:

I've attached screenshots showing the behavior.

Basically, somewhere in the code that serializes the camera settings, I'm doing something that is causing an "off by one" type of error. 

Here is the code for the template functions (based on what you gave me, I only had to make minor tweaks to get it to work.

Code: [Select]

#ifndef __SerializableTraits_h
#define __SerializableTraits_h

namespace pcl
{
    /*
     * Adds an object t to a ByteArray stream b.
     */
    template <class T>
    inline
    void AddToRawData( ByteArray& b, const T& t )
    {
       const uint8* p = reinterpret_cast<const uint8*>( &t );
       b.Add( p, p+sizeof( t ) );
    }

    /*
     * Retrieves an object t from a ByteArray stream at the specified location i.
     * Returns an iterator located at the next position in the ByteArray stream.
     */
    template <class T>
    inline
    ByteArray::const_iterator GetFromRawData( T& t, ByteArray::const_iterator i )
    {
       t = *reinterpret_cast<const T*>( i );
       return i + sizeof( T );
    }

    /*
     * Adds the contents of a string s to a ByteArray stream b.
     */
    template <class S>
    inline
    void AddStringToRawData( ByteArray& b, const S& s )
    {
       AddToRawData( b, uint32( s.Length() ) );
       if ( !s.IsEmpty() )
          b.Add( reinterpret_cast<const uint8*>( s.Begin() ), reinterpret_cast<const uint8*>( s.End() ) );
    }

    /*
     * Loads a string's character contents from the specified location i on a ByteArray.
     * Returns an iterator located at the next position in the ByteArray stream.
     */
    template <class S>
    inline
    ByteArray::const_iterator GetStringFromRawData( S& s, ByteArray::const_iterator i )
    {
       uint32 n;
       i = GetFromRawData( n, i );
       if ( n > 0 )
       {
          s.Assign( reinterpret_cast<const typename S::char_type*>( i ), 0, n );
          i += n * sizeof( typename S::char_type );
       }
       else
          s.Clear();
       return i;
    }

    /*
     * Template instantiations for the String type.
     */

    void AddToRawData( ByteArray& b, const String& s )
    {
       AddStringToRawData( b, s );
    }

    ByteArray::const_iterator GetFromRawData( String& s, ByteArray::const_iterator i )
    {
       return GetStringFromRawData( s, i );
    }

    /*
     * Template instantiations for the IsoString type.
     */

    void AddToRawData( ByteArray& b, const IsoString& s )
    {
       AddStringToRawData( b, s );
    }

    ByteArray::const_iterator GetFromRawData( IsoString& s, ByteArray::const_iterator i )
    {
       return GetStringFromRawData( s, i );
    }
}

#endif

Here is the code snippet from my CameraItem class:

Code: [Select]

    void CameraItem::AddToRawData( ByteArray& b) const
    {
        pcl::AddToRawData( b, cameraName );
        pcl::AddToRawData( b, driverPath );
//        pcl::AddToRawData( b, enabled );
    }

    ByteArray::const_iterator CameraItem::GetFromRawData( ByteArray::const_iterator i)
    {
//        return pcl::GetFromRawData( enabled,
        return pcl::GetFromRawData( driverPath,
                     pcl::GetFromRawData( cameraName, i ) ) ;

    }

Here is the load function from my ImageAcquisitionSettingsInstance.cpp
Code: [Select]

  void ImageAcquisitionSettingsInstance::LoadCameras()
  {
      Console c;
      installedCameras.Clear();
      ByteArray data;
      if( Settings::Read( "CameraData", data ) )
      {
          CameraItem camera;
          for ( ByteArray::const_iterator i = data.Begin(); i < data.End(); i = camera.GetFromRawData( i ) )
          {
              c << "reading: [ " << camera.cameraName << " ]" << "\n";
                   installedCameras.Add( camera );
          }
      }
  }
and the save
Code: [Select]

  void ImageAcquisitionSettingsInstance::SaveCameras( )
  {
     Console c;
     ByteArray data;
     for ( camera_list::const_iterator i = installedCameras.Begin(); i != installedCameras.End(); ++i )
     {
        i->AddToRawData( data );
        c << "writing: " << i->cameraName << "\n";
     }
     //Settings::Remove( "CameraData" );
     Settings::Write( "CameraData", data );
  }

I can't figure this one out (at least not for the last few hours of staring at it) - is there anything that is jumping out at you?

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 March 19 08:01:54
Ok - I found the problem.

This code
Code: [Select]

          for ( ByteArray::const_iterator i = data.Begin(); i < data.End(); i = camera.GetFromRawData( i ) )
          {
              c << "reading: [ " << camera.cameraName << " ]" << "\n";
                   installedCameras.Add( camera );
          }

Was incorrect.  Here is what I changed it to:

Code: [Select]

          ByteArray::const_iterator i = data.Begin();
          while ( i < data.End() )
          {
              i = camera.GetFromRawData( i );
              c << "reading: [ " << camera.cameraName << " ]" << "\n";
                   installedCameras.Add( camera );
          }

I don't know why it didn't jump out to me sooner ;-)  It is kinda obvious that the loop is running once before calling the iterator - thus setting the value of the camera to the newly initialized camera with empty values. 

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2011 March 19 08:59:13
Sorry, the typical use of the 'for' construct betrayed me in this case. Another way to write this is:

Code: [Select]
         for ( ByteArray::const_iterator i = data.Begin(); i < data.End(); )
          {
              i = camera.GetFromRawData( i );
              c << "reading: [ " << camera.cameraName << " ]" << "\n";
              installedCameras.Add( camera );
          }

which doesn't force you to declare the i variable outside the for loop. Let me know if you find more 'Easter eggs' of these :)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 April 26 06:58:28
Ok - it has been a while since I updated everyone.

I went ahead and decided on a Creative Commons License - Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Here is the human comprehendible version of this license:
http://creativecommons.org/licenses/by-nc-sa/3.0/

If anyone has any concerns or objections to this license - please let me know.  I won't go into all of the details of why I chose this license, but I definitely struggled to find the right one.

As of now, this project is available only in source form:

https://github.com/ceterumnet/ImageAcquisition

I don't have any build instructions yet...but on Windows - you should be able to use the included Visual Studio project.  On OS X, I am using Eclipse...

There is a TODO list in the README, but I am going to migrate this into a Pivotal project soon so that I can have a better way to track requests and bugs etc...

I promise I will release a version that you folks can install soon - there are just a few more things I want to have in place before we start any Beta testing.

I am not expecting code contributions - but if you are interested, please don't hesitate to review the code and start a fork. 

We could use some nice icons!  Currently I have some placeholder icons...I don't plan on investing any time in those...so any artistic folks - here is your chance to contribute!

And seriously - ImageAcquisition is a pain-in-the-ass to type.  Anyone have any suggestions for a better name?  PICap?  PISniper?  I dunno...just let me know if you guys have some ideas here as well.  I am not trying to replace the PixInsight name by any means...but I really would like to name the overall collection of functionality related to camera and observatory control to something more meaningful.

Any other feedback is welcome as always...


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2011 April 26 09:20:54
You may just use "Acquire"...
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Josh Lake on 2011 April 26 11:16:18
I'm an artistic type (with a computer) and would happy to work on some icons. Can you tell me what sizes you need, which functions they need to match, and any other specs (filetype, transparency, etc)?

As for the name, what about ImageCapture or FrameCapture? Or even CameraControl?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2011 April 26 12:15:12
Hi jlake

Icons are xpm files. You may work over a png file, and then convert it to xpm with PixInsight. I attached a pair of png/xpm files from the standard CurvesTransform process.

To developers: XPM files generated by PixInsight need to be modified by a text editor, replacing the array name like this:
Code: [Select]
static const char *YourProcessNameIcon_XPM[]={
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 April 27 07:10:17
I'm an artistic type (with a computer) and would happy to work on some icons. Can you tell me what sizes you need, which functions they need to match, and any other specs (filetype, transparency, etc)?

If you just provide PNG (or even PSD) that are 24x24 - that is excellent - I can handle the conversion for the C code into XPM files.  You can leverage transparency as well.  I am not sure if it is a full alpha channel or just a mask type of transparency. 

Here are the functions:
 ...These first 2 are needed soon:
... and not needed right away but we will need them:
Quote
As for the name, what about ImageCapture or FrameCapture? Or even CameraControl?

I definitely like ImageCapture - much easier to type :-)

Thanks!!!
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Emanuele on 2011 April 27 13:44:27
AH!
I am so happy to read that the project is still going strong and been worked at.
ok, so what can i do to help? I would love to, but I have no experience in programming!
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 May 02 12:02:06
Quote
ok, so what can i do to help?

Soon...I will release a beta version.  Then you can test!

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: netwolf on 2011 August 04 05:35:41
David, just finished going over this thread. I am glad to see that there is some development happening in this area. Just wondering how you are going with it?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 August 04 05:47:51
Thanks for asking!

I am close to releasing a beta version.  I would say approximately 80% complete from a camera control perspective.

I had a pretty ugly setback recently with the ASCOM support.  The ASCOM committee changed the architecture to only support late binding for COM.  This required that I rewrote all of my ASCOM driver support.

I am just now finishing that.

So it should be soon!

Best,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: netwolf on 2011 August 04 06:09:50
David, will your module only support ASCOM devices? I ask because I have the SXVR-M26c and as yet there is no ASCOM driver for it. There is a SX Ascom driver but it does not yet suppor the M26C. But I am hopping this will change soon.

Also one thing I miss in Nebulosity is the ability for it to get RA/DEC cordinates, time, location from the Mount and add these to the FITS header. It would be nice to see this as a feature in your module. 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2011 August 04 06:18:56
Not at all!

My module is cross platform.  Currently, I am implementing ASCOM support since it is a low hanging fruit. 

Have you tested the ASCOM driver with the M26c?  Just curious since it says that it supports SX cameras in general.

Ultimately, I am not sure if I will develop drivers for specific cameras.  I am thinking about adding an X2 driver as well so that all of the cameras supported by TheSkyX will also be supported. 

However, if enough people need native Starlight support - it appears that the API is open and available.  So there are no technical barriers :-)  Someone just has to lend me a Starlight camera to develop on.

Best,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2012 December 12 14:03:42
I just wanted to follow up on this thread and let everyone know that I am going to be spending time on this once again.

If anyone is interested in details on where the project is at this point...just reply to this thread :)


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2012 December 12 17:56:11
Hi David!
I know for certain that many people are looking at this :) And also I'm very interested in the results.
If you get PI to capture Canon cameras, and control an autoguider, you'll be my hero. ;)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: georg.viehoever on 2012 December 12 23:54:20
I always wondered what happened to this project. Yes, please, go ahead!
Georg
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Alejandro Tombolini on 2012 December 13 02:24:36
If you get PI to capture Canon cameras, and control an autoguider, you'll be my hero. ;)

+1
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: vicent_peris on 2012 December 13 02:39:16
Hi David,

You know I was always very interested in your project. All I can do for now is to give you a list of the instruments I have to do the betatesting:

- Cameras: FLI Proline, Apogee Alta, Lumenera Skynyx, Starlight SXVR and Superstar.
- Filter wheels from FLI.
- Mounts: Paramount, Astelco NTM, Astro Electronic FS2.
- Tubes (focuser): Planewave CDK, Optec.
- Meteo station: Vaisala WTX520 and Davis Instruments.

As far as I know, there's drivers for Linux only for FLI, Paramount, Astelco NTM and Davis Instruments. But I don't know if you're planning to port your modules to Linux.


Best regards,
Vicent.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2012 December 13 06:20:14
I've attached a draft of an article I wrote last year for the PixInsight magazine :-)  But I don't think it was ever ready for publishing...however, instead of it hanging on my hard drive - I'll attach it here.   Please read this for an idea of the vision It should give a general idea of what capabilities are already in place for ImageAcquisition. 

I will always bite off more than I can chew :-)  Shoot for the Moon ... so that we can Shoot the Stars :-P

So any help is more than welcome.  Today, I can use help with:


As a reminder, there are 2 repositories on GitHub:

https://github.com/ceterumnet/ImageAcquisition <- This is the primary repo with the software.  It has a detailed README as well

https://github.com/ceterumnet/PixInsightASCOMDrivers <- This is the driver code for ASCOM Based Cameras.  These aren't ASCOM Drivers - they are iPixInsight drivers that support ASCOM :)   


My next steps are:

Once I have those Filter Wheel support and A/F - I will probably start using PixInsight as my primary acquisition software :)

Carlos -
I'd be happy to develop Canon support - I just need a Canon camera to test with.  Alternatively, my driver architecture is very modular, and someone else can take on the development for Canon support.  Autofocus is near and dear to my heart - so it is definitely on the top of the list after filter wheel support. 

Vicent -
My module is definitely fully cross platform -- at least that's the intention.  I want it to run on Linux, OS X and Windows.  Today, I've been testing on OS X and Windows.  It certainly shouldn't be too difficult to work with any of the vendors that offer a Linux API.

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: marekc on 2012 December 13 12:05:04
Hi David,

Thanks very much for working on this! I would be very interested to see a PI acquisition module in action :-)

Here's a random feature request, from someone who's not a programmer, but I think it would be a useful thing to have:

We might call this something like `HDR capture support' or `star core capture support'. I'm referring to the fact that we sometimes shoot sub exposures that are long enough to saturate some of the pixels in the image. The cores of bright stars are a prime example. It's been mentioned here on the forum that one can shoot some short subs, to capture those star cores without hitting the full-well capacity of the sensor, and then use PI's HDR combination module to combine the long-sub and the short-sub data. It might be nice to have something - I'm not sure exactly what - built into the acquisition module to facilitate that.

In fact, here's one thing specific thing that might help: `Batch dithering'. I think a lot of PI users (and others) use dithering to help eliminate hot pixels and improve overall SNR. I acquire with MaximDL, and it's reasonably good at dithering between subs. That's fine if my subs are 5 or 10 minutes each, but if each sub is only a few seconds long, then a lot of time gets wasted dithering between each frame. It might be nice for the control software to shoot a number of short `star core' subs, say 10 or 20 of them, then dither to a slightly different pointing, then acquire another 10 or 20, and so on. Maybe that could help the imager strike a good balance between the benefits of dithering and the downside of the time it would eat up.

Maybe there could even be a way to analyze the star profiles in the long subs (maybe with Mike Schuster's script?) and then suggest to the user a good exposure time for the `short subs'?

Just fantasizing... thanks heaps for working on this!

- Marek
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2013 February 07 00:16:13
Hi,
this is a great project, thanks! I started to work on a Canon DSLR driver for this project and so far it works well.

I have a question for the PCL team: Since a DSLR creates images in file formats like JPEG and RAW, I have to "decompress" the image  after downloading from the camera before displaying in PixInsight. Currently I download the image files directly to the host file system  and open it with pcl means from the filesystem. That works fine. But I plan also to implement Live View functionality, and here downloading to file system is not an option. Is there a way in PCL SDK to convert a JPEG bytearray into the internal PCL image format?

Thanks!
Klaus
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2013 February 07 08:15:10
Hi Klaus,

I am glad of reading this! Please keep us informed; we are *very* interested on your project.

Quote
Is there a way in PCL SDK to convert a JPEG bytearray into the internal PCL image format?

Loading bitmaps from raw data is currently only implemented for the SVG format. However, this functionality will also be available for the JPEG, PNG and TIFF formats (8-bit images only) in the upcoming version 1.8.0 RC4 of PixInsight.

The documentation for the pcl::Bitmap class (http://www.pixinsight.com/developer/pcl/doc/html/classpcl_1_1Bitmap.html) is available online. In particular, you'll be interested in the following constructor (http://www.pixinsight.com/developer/pcl/doc/html/classpcl_1_1Bitmap.html#a4251b70816236cacb11b1495ea76e5d9):

   Bitmap ( const void* data, size_type size, const char* format="SVG", uint32 flags=0 )

Starting from PI 1.8.0 RC4, the following example will work:

const void* rawData;
size_type dataLength;
// ...
Bitmap bmp( rawData, dataLength, "JPEG" );


You can render a Bitmap directly on a regular Control (http://www.pixinsight.com/developer/pcl/doc/html/classpcl_1_1Control.html) object, by specifying a paint event handler (http://www.pixinsight.com/developer/pcl/doc/html/classpcl_1_1Control.html#aa772ac5483c9c5ca4109f8f771181933), or using a BitmapBox (http://www.pixinsight.com/developer/pcl/doc/html/classpcl_1_1BitmapBox.html) object.

A new constructor will also be available:

   Bitmap ( const ByteArray& data, const char* format="SVG", uint32 flags=0 )

where the data can be specified as a ByteArray object.

PI 1.8.0 RC4, along with a new version of PCL, will be released in a few days.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2013 February 08 04:49:13
Thanks Juan,
that's exactly what I need!

Quote
... Please keep us informed; 

Yes, of course ;-).  Unfortunately, there are some conditions induced by the Canon driver SDK which do not fit well into PixInsight platform strategy. For example, the Canon SDK only supports Windows and Mac OS and not Linux, and, even worse, only 32-bit (argh). So you well need, an extra Laptop/Instance to run  the ImageAcquisition Plug-In with Canon driver ... hope that Canon will deliver a 64-bit soon.

 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2013 February 08 05:45:54
Quote
For example, the Canon SDK only supports Windows and Mac OS and not Linux

Well, fortunately we can run Windows from a virtual machine on Linux and FreeBSD. This is how the Windows version of PixInsight is being developed, in fact :)

Quote
and, even worse, only 32-bit (argh)

Ouch. This is a much worse problem... and surprising that they don't have a 64-bit version of their SDK.

Do you plan on supporting Nikon cameras too?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2013 February 08 06:34:50
Quote
...and surprising that they don't have a 64-bit version of their SDK...
Yes,  hope they will change that soon; I think they have to ...   

Quote
Do you plan on supporting Nikon cameras too?
Currently not, since I don't have a Nikon camera ... developing without testing is not fun ;)
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2013 March 06 08:25:53
Some updates...

A first version of the DSLR driver for Daves ImageAqcuisition plugin is working now (see attachement). I've tested it a few days ago with my Canon 500D. However currently tested only  with the PixInsight Windows  32bit version  :-\.

I contacted the Canon DSLR developers to find out whether there is a plan to provide a 64-bit version of their library. There is already a "beta" version on their download page but with only very limited functionality -> not usable for our purposes.  However, they don't want commit to any release date ...

On Linux I found a opensource library gphoto2 (32 and 64 bit of course ;) ), which supports several DSLR models... that sounds promising. Maybe also running on a raspberry pi  ;)   

 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2013 July 07 09:16:20
Some updates...

A first version of the DSLR driver for Daves ImageAqcuisition plugin is working now (see attachement). I've tested it a few days ago with my Canon 500D. However currently tested only  with the PixInsight Windows  32bit version  :-\.
 

I should have posted this sooner, but - Great job Klaus!!!  If we could get a couple more contributors on this project...that would be spectacular ;-) 

I wanted to update everyone here with the latest.

I am currently working on stability and bug fixes.  There are a number of issues that need to be addressed so that we can get a usable version of ImageAcquisition made available to the community.

Previously, I posted this list as  my "next steps":

Quote

My next steps are:

    Finish Filter Wheel Support (This is really just part of Camera Control I think)
    Finish Autofocus Support (initially through FocusMax I think)
    Image Sessions (Think simple UI to manage everything)
    Auto-guiding
    Plate-solving
    Telescope Control


Those "next steps" are really more of a road map.  I'd say the next steps for ImageAcquisition are the following:


The latest code in github is actually quite stable for testing ASCOM or Canon DSLR based cameras on PixInsight 1.7 32 bit for Windows.   

Here is a build for Windows and the ASCOM driver for anyone that feels adventurous. 

https://www.dropbox.com/sh/gnyrt7j9bzhbbmd/P36V-lWsov

Any issues that you discover with the plugin - please file them here:
https://github.com/ceterumnet/ImageAcquisition/issues

Here is how to use it:


Here are some screenshots to assist as well:
http://www.flickr.com/photos/21315110@N00/9232390108/in/set-72157634525856869/



Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: pfile on 2013 July 07 14:06:54
cool, i just saw this in an email from flickr and i was like ... whaaaa?

Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 April 12 19:51:10
Howdy all,

I've been doing some more work on this module, and I think it is working pretty well on PixInsight 1.7 :-(

So I've been working on updating it to PixInsight 1.8.  Previously, I was using the following to determine an screen stretch for the image coming in from the camera:

Code: [Select]
m = HistogramTransformation::FindMidtonesBalance( .25, m - c0 );

However, in the latest release of PCL - this doesn't exist.  Can someone point me in the right direction of where this has moved?


Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2014 April 19 11:38:46
Hi David,

The FindMidtonesBalance function is no longer necessary. Use this code instead:

m = HistogramTransformation::MTF( .25, m - c0 );

This is possible thanks to the invertible property of the MTF function. Given input and output background values b0 and b1, respectively, we want to find the required midtones balance mb for the MTF function such that:

b1 = MTF( b0, mb )

It can be shown that the answer is:

mb = MTF( b1, b0 )

For a more complete reference of the AutoStretch routine in the current versions of the ScreenTransferFunction tool, see the ScreenTransferFunctionInterface.cpp source file in the latest version of the PCL distribution (IntensityTransformations module).
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 April 19 12:17:34
Thanks!


Another thing I should mention:

Since PixInsight is deprecating Windows 32 bit support, this makes supporting ASCOM a bit of a problem moving forward. 

I'm working on 64-bit drivers for QHY cameras that will work with the module.  It shouldn't be too hard to add support for other vendors...but it does limit the number of devices ImageAcquisition can support. 

Is it possible for you to include the 32 bit support in PCL for the time being so that the module can still run on 32-bit PixInsight?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Juan Conejero on 2014 April 19 13:49:49
All 32-bit versions of PixInsight are definitely deprecated and will no longer be supported or updated.

A 64-bit application cannot execute code in a 32-bit DLL. The only way to solve this problem that I know of is through interprocess communication. Matt Nicholson has an article that describes this in detail in this blog post (http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/).

The article mentions COM to implement an interprocess communication mechanism. Instead of COM I would use Qt's IPC implementation. See for example the documentation for QSharedMemory (http://qt-project.org/doc/qt-4.8/qsharedmemory.html). I use QSharedMemory to manage multiple running instances of the PixInsight Core application. As long as you take some precautions with data alignment (for example, ensuring that all shared data blocks start at 16-byte aligned addresses), this should allow you to implement a data sharing protocol easily between a 32-bit executable that interfaces with ASCOM and your 64-bit module.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 April 19 14:01:11
I considered doing some sort of IPC based approach...but I'm already not too impressed with ASCOM - so I'm not sure I'm going to invest any more time with ASCOM.  Perhaps someone else will take this part of the project.

I am going to focus in on native drivers on Linux anyways.  I don't really like Windows  >:D  QHY has open sourced a bunch of their Linux stuff...so I will play around with that and see what success I get.  If I can't progress with that quickly enough I may revisit the IPC based approach.

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: vicent_peris on 2014 April 20 12:38:31
I considered doing some sort of IPC based approach...but I'm already not too impressed with ASCOM - so I'm not sure I'm going to invest any more time with ASCOM.  Perhaps someone else will take this part of the project.

I am going to focus in on native drivers on Linux anyways.  I don't really like Windows  >:D  QHY has open sourced a bunch of their Linux stuff...so I will play around with that and see what success I get.  If I can't progress with that quickly enough I may revisit the IPC based approach.

Cheers,
Dave

Thank you very much for taking this decision.

You already have native software for FLI and Apogee. There's also a command line software that allows to control an Apogee camera, it's pretty easy to use.


V.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: pfile on 2014 April 20 17:35:15
some of the SBIG cameras have ethernet interfaces and they have a pretty simple http API.

not sure who really uses this though. there's no support in phd2 for the http API, but then again if you connect to the guider over USB you can still use the http API to talk to the main imager.

rob
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: georg.viehoever on 2014 April 21 02:13:29
Does anyone know if INDI drivers http://www.indilib.org/ are a viable alternative to ASCOM now?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 April 21 09:01:27
Does anyone know if INDI drivers http://www.indilib.org/ are a viable alternative to ASCOM now?

I think INDI shows a lot of promise.  There doesn't seem to be a lot of vendor support, but there are a few community contributed drivers.  Either way, the approach I'm taking with ImageAcquisition abstracts all of that so that we can support whatever moving forward. 

Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 May 05 04:56:14
I just wanted to post a quick update:

New Features:
1.  The first native 64-bit Linux driver is working (QHY5-II) -
  - it is based on https://github.com/ceterumnet/QHYPixInsightLinuxDrivers/
  - and I've created a fork of the QHYCCD Linux driver base - https://github.com/ceterumnet/QHYCCD_Linux
2.  The "Frame and Focus" feature is working.  It starts up a modal dialog
3.  Abort is now enabled for the process

Bug Fixes:
1.  Sub-frames work correctly now
2.  Less crashes

General Updates:
1.  The module is updated for PixInsight 1.8.x
2.  The build system now uses CMake instead of the built-in PixInsight module makefile generation. 
3.  The ImageAcquisition repository has been cleaned up quite a bit - https://github.com/ceterumnet/ImageAcquisition

If anyone has a QHY5-II and wants to try this out on Linux - please let me know.  I plan on adding support in the near future for:

1.  QHY9 + FW
2.  FLI Cameras

It has been a long journey for me so far.  I never thought back in 2011 when I started this project that it would take me this long!  However, I am confident that I will be using this as my only software for controlling cameras in the near future.  I've specifically not renewed my MaximDL license as added incentive for me to get this production ready ;-)

Finally, I'd GREATLY appreciate anyone that is willing to lend a hand.  I can use help with the following:
1.  Testing
2.  Icons
3.  Driver Development


Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2014 May 05 08:33:58
Hi David

Do you think that adding Canon support is too difficult? I would gladly help you testing with those cameras. Also I have an Orion SSAG, if you ever implement it.


Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 May 05 08:42:46
So Canon support exists on Windows for 32-bit PixInsight 1.7 - it was added a while back by Klaus. 

I know that, when he implemented it, there was no 64 bit Canon SDK.  It now looks like they have some Beta support with a 64-bit SDK.  I personally don't own a Canon DSLR, so it will be hard for me to contribute in this regard.

If I ever decide to write a 32-64-bit bridge driver for PixInsight on Windows to support ASCOM - then the SSAG will be supported. 

Sorry for the less-than-great answer :(


Cheers,
Dave
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: Carlos Milovic on 2014 May 05 08:58:56
;) don't worry

Btw, I use linux mainly, so if you ever make the port there, you'll have my eternal gratitude.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: vicent_peris on 2014 May 05 12:53:22
Hi David,

I have a FLI camera, I can test everything as soon as you have the drivers ready.

Best regards,
Vicent.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2014 May 11 06:46:06
Hi all,
due to the restricted platform support of the Canon SDK I started to work on an integration of an INDI client into PixInsight. Prerequisite is a running INDI server on a Linux or Mac  machine and devices which are supported by INDI. With the integrated client you can connect to the INDI server on the same machine or remotely on another machine.  My prototype supports:

- Windows , Linux, MacOs
- receiving and sending device properties to the INDI server to control the devices which are connected to the server
- receiving and sending device properties to the INDI server via the Javascript engine

The INDI client process holds a native INDI client as a singleton to which other  processes can connect to. With that it is possible to write simple convenience apps like frame aquisitions or telescope control. For example I used the Image Solver script to get object coordinates online for telescope control.

It seems to work quite well, at least "I eat my own-dog food" and use my prototype every night when the wheather allows me to do so. However the prototype is still a prototype and not usable for productive use, e.g. behaviour when the INDI server crashes is currently not so good ;)...

If there are some Linux users who want to test my prototype let me know. Then I will try to allocate some time to fix the most critical issues.

 Cheers,
Klaus
 
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: vicent_peris on 2014 May 12 06:05:32
Hi Klaus,

I would be interested in testing your software, I have some Canon cameras available.

Best regards,
Vicent.
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: kkretzsch on 2014 May 12 22:48:57
Hi Vicent,
OK great, I'll first upgrade to the latest PI version and do some testing. For Canon cameras you'll need to install the INDI gphoto driver (indi_gphoto_ccd). This driver supports not only Canon but also a large set (>1000) of other Camera models (Nikon,Sony,Olympus,...). If you have a CCD camera, here is a list of all CCD cameras (SBIG, ATIK,FLI, ...) supported by INDI

http://www.indilib.org/devices/ccds.html

they should also work with my prototype.  I'll come back as soon as I have finished testing and written some documentation on how to install and use the whole setup.

Cheers,
Klaus
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 May 25 09:39:03
Ok - I am trying to figure something out with regards to dialogs.  I want my driver to be able to provide a PixInsight Dialog for configuring the driver settings.   However, I'm running into problems that I think are related to the fact that I probably can't instantiate a pcl::Dialog inside of my driver.

I assume this has something to do with the fact that the memory allocator won't work correctly inside of a loaded library that isn't managed directly by PixInsight's main UI thread. 

Am I correct in assuming I won't be able to simply instantiate a Dialog inside of my driver code?   Any suggestions on how to approach this?
Title: Re: Image Acquisition in PixInsight (Was: When will Pixinsight...)
Post by: David Raphael on 2014 May 25 09:47:13
Ok - after thinking about it a bit more...I'm thinking that my driver *can* return a type that could then be instantiated by the interface...

anyways...I'll tinker a bit more and see if I can figure it out...