Software Development > PCL and PJSR Development
Image Acquisition in PixInsight (Was: When will Pixinsight...)
David Raphael:
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?
Juan Conejero:
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).
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?
--- End quote ---
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?
--- End quote ---
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.
David Raphael:
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
vicent_peris:
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.
mmirot:
This is whole different animal. Testing drivers is full time job and there is always a new one.
Run away... Run away.... :surprised:
Max
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version