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

[David Raphael]

ok, so what can i do to help?

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

Cheers,
Dave

[netwolf]

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?

[David Raphael]

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

[netwolf]

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. 

[David Raphael]

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

[David Raphael]

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

[Carlos Milovic]

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.

[georg.viehoever]

I always wondered what happened to this project. Yes, please, go ahead!
Georg

[Alejandro Tombolini]

If you get PI to capture Canon cameras, and control an autoguider, you'll be my hero.

+1

[vicent_peris]

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.

[David Raphael]

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:

• Motivation - when I hear that people want this...it is the biggest help by far!
• Code Review :-)
• Testing of ASCOM Based Cameras - these are ready to be tested
• ...anything else you want to 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:

• 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

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.

[marekc]

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

[kkretzsch]

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

[Juan Conejero]

Hi Klaus,

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

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 is available online. In particular, you'll be interested in the following constructor:

   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 object, by specifying a paint event handler, or using a BitmapBox 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.

[kkretzsch]

Thanks Juan,
that's exactly what I need!

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