Currently INDI camera drivers transfer their images in FITS format. The only exception is the DSLR driver which can also send images in their native captured format.
I was thinking of expanding this to a standard property so other driver can make use of it. For this, I believe we need two standard properties.
1. CCD_CAPTURE_FORMAT
2. CCD_TRANSFER_FORMAT
For the CCD_CAPTURE_FORMAT, it selects what file format the image should be captured in natively from the device. For DSLR cameras, this can be JPG/CR2/...etc (whatever format natively supported by the camera). For CCD/CMos cameras, this can include RAW-8/RAW-16/RGB/etc..
Now the CCD_TRANSFER_FORMAT simply designates the format which INDI clients receive the captured blob as. These can be:
1. RAW (as is, native)
2. FITS (default)
3. XISF (future implementation perhaps)
4. ..etc
This is already realized in the DSLR driver. That is, you can captured a JPEG image and transfer it as FITS or as RAW, or capture RAW CR2 and transfer it as FITS..etc. So what is suggested here is to standardize this further and make it available for other driver to implement in a standard consistent way.
Read More...
Yes, we've been looking to do something like that in KStars. I think we need a very fast star-matching algorithm (to know how to rotate/scale frame before integration) and then some averaging algorithm. It's mostly just as a way to see live how the image acquisition is going. It's also great for observatories with visitors..etc.
I wish there is a library we could use to make this easier, unless a developer steps in to implement it from scratch based on the existing algorithms in ASTAP and/or CCDCiel.
Noticed both programs seems to use Pascal as well 
Read More...
edh wrote: I thought the ASCOM driver was a Windows driver. Is there a version that works with the Stellarmate? If so, how can it be selcted?
There appear to be 2 drivers that may be associated with the CGEM mount. One is listed as 'Celestron CGEM', and the other is listed as 'Celestron NexStar'. Which one should I be using? The same problem is seen with both drivers.
After performing a series of diagnostic steps requested by Celestron Technical Support, they had concluded from my description of the problem and the results of the diagnostic steps, that the problem must be with the Stellarmate software. Chris, you have been extremely helpful with investigating the issue. And the logs support my conclusion that although the problem is experienced when the mount is connected with the Stellarmate, the failure is in the communication between the Celestron mount and the Celestron hand controller. I am not yet willing to give up on Stellarmate because it is the best tool for my requirements. And I am not ready to dump the CGEM and purchase a different mount. As a retired engineer with hardware design and software development and testing experience, I know that this is a solvable problem and one I can solve if I have the appropriate tools. Celestron has agreed to provide me with a NexStar hand controller with a serial port to test. In addition to that, I plan to probe the Celestron internal communication bus with an oscilloscope to see if there any apparent electrical changes when the Stellarmate is connected. Beyond that, I would need guidance and diagnostic tools from Celestron to investigate the issue. It remains to be seen how much support they would be willing to provide.
Chris, Thank you for your help. Let me know if you have any connections with Celestron that might have the knowledge to assist with this investigation.
Ed
Thank you for your exhaustive testing. I might have an idea of something that might help. Can you please open a ticket at stellarmate.com? or send email to This email address is being protected from spambots. You need JavaScript enabled to view it. to get this issue resolved. We'll try different ideas and then if something works we'll announce it back here.
Read More...
han.k wrote: The ASTAP commandline is specified here:
www.hnsky.org/astap.htm#astap_command_line
Han
Thank you Han! I just have to say again I'm in love with both HNSKY & ASTAP! The functionality in ASTAP puts KStars FITSViewer to shame. I have a couple of questions if you don't mind. I love the stacking feature. Do you think your star alignment routine can be used to perform *live* stacking?
Read More...
Alright, I'm quite impressed with ASTAP after trying it for the last hour. We already worked with Han before to get INDI support into HNSKY so I know he's pretty smart, but this is on another level!
Anyone up for adding this to Ekos alignment? It's not as complex as astrometry.net so it should be fairly straight forward to add it as an alternative solver.
Read More...
I will look into it... if someone from the community can work on adding ekos support for that it would be great.
Read More...
Ok, so you need to add:
INDI_declare_component(v4l indiv4l)
to the FindINDI.cmake in the 3rdparty/cmake_modules directory.. since this is what is used by the driver.
Read More...
I fixed a couple of issues (you can't use DEBUG outside the class, use IDLog). but it compiled fine. It's not linked against indi_v4l2.. did you push this part yet?
Read More...
Do you these changes in a fork somewhere? If yes, I can check out the fork and diagnose the issue right there.
Read More...