One thing to keep in mind :

in DS photography, all the tools used to make your images, run natively under Linux. (Kstars/Ekos/INDI, Siril, Gimp ...)
In Planetary imaging, the best tools used, run natively (and only) under Windows (AS!3, Registax, Astrosurface ... )

Wine isn't really an option as it cripples literally the performances of the programs. (slower, incomplete functions, impossibility to use the output of a program as an input to another... )

So a planetary tab in Ekos will have to work at its best under WINDOWS ...

- Marc

Some thoughts ...

In planetary imaging, like in sports photography, speed is the key.
A typical planetary camera like an ASI290mm at full frame (1936x1096) delivers 130fps.
That means roughly 2x130x8 = 2Gb/s

Do you think a Raspberry Pi will be able to grab & write a SD card at such a speed without losing frames ?
Of course, you can use ROIs for planets, but for the moon, you'll need full frame.

- Marc

Marc post=93217 userid=5122
One thing to keep in mind :
So a planetary tab in Ekos will have to work at its best under WINDOWS ...

How would this work with INDI?

Marc post=93218 userid=5122
Some thoughts ...
Do you think a Raspberry Pi will be able to grab & write a SD card at such a speed without losing frames ?

My Pi 4 has an M.2 NVME disc and does not run from SD card anymore (1 TB!) This is just a simple add-on board with a USB3 connector. Switching is easy. Either use the imager (which is included in EKOS - but this did not work for me. Or simply use Raspberry Pi imager. You can do all this directly on the Pi. With raspi-config you can simply choose to start from USB (Pi4) So speed is not an issue, nor is disk space.

I finish my planetary imaging with PlanetarySystemStacker with runs natively under Linux, Windows and MacOSX.
github.com/Rolf-Hempel/PlanetarySystemStacker

github.com/Rolf-Hempel/PlanetarySystemSt...acker_User-Guide.pdf

I've never really had a problem with planetary capture on Linux. For capture I use firecapture which runs fast enough, I can capture as fast as the data will come from the camera over USB3. (And sometimes AstroDMX Capture, which although it isn't free software I sometimes prefer, especially for lunar imaging.) Either way, I record straight to an M.2 drive which can take data far faster than USB3 can provide it. A raspberry pi 4 just about has the I/O bandwidth to keep up with 2Gbit/s output from a camera if it's writing to a USB3 drive (even with the pi's suboptimal USB3 implementation) although it might end up being throttled by the capture software if that's trying to do anything CPU-intensive in terms of a preview, and I definitely wouldn't expect it to be able to write that data rate to the microSD card.
As for processing, the usual Windows software (autostakkert!, registax, astrosurface) runs fast and well for me using recent Wine versions. I notice there are a lot of grumbling Wine logs, but the programs run well enough to achieve the required processing.

In terms of developing ekos for planetary capture, I think the first thing is to avoid doing anything to disimprove its deep space capture abilities. AstroDMX has support for INDI cameras since v2.0.2 although the author reports that there are issues with speed and for fastest capture the native drivers should be used, so perhaps the first thing might be to look at removing any bottlenecks to the data rate that might be caused by INDI. After that I guess ekos becomes just another capture application, so would need to look at implementing the same kinds of things as the other capture applications: high speed debayering and high speed preview rates, guiding based on the COG of the planet disc in view, auto ROI adjustment to help in coping with drift, setting of capture frame / time limits, tools like indication of RGB channel misalignment, etc. etc. One specific suggestion would be that the separation of all the camera settings into the INDI control panel is all very well for deep sky imaging where you don't change them often, but for planetary imaging it's much more convenient to have camera settings directly to hand so look at taking the best usability features from the existing front-runner planetary capture apps.

On the processing side, I write code for Siril; there is an ambition to improve our planetary processing capabilities in either the 1.3 development cycle or the one after that (it depends how we get on as there are also some other substantial feature additions as well as (if we're brave enough!) moving from gtk3 to gtk4... So hopefully there will be more native processing options in the not entirely distant future.

Actually, lots of progress has been done at the INDI driver level to improve this. 3rd party authors just need to know how to make the most out of it with FAST BLOB support that was added a couple of releases ago. Speed is not the issue. Ekos has a "video recording" tool in capture module that can be used for record, but it's a far cry from a full-fledged planetary imaging suite. I think what we are missing now is some design document that lists all the requirement in a clear and concise way so that in case someone picks up this task, they know what they have to do. We can even make it as a Google Summer of Code project, but we need complete details with possibly mockups of the design.

However, it needs to be simple and perhaps broken into phases. We can't just shove everything in there. There are lots of ideas discussed here on the forum, but we need a *formal* document to put it all in one place that a prospective developer who has no idea about planetary image (or very little like me) can process and turn into milestones that can be achieved.

One thing I currently miss in Ekos which could be a good starting point for a planetary tab IMHO, is a simple live view with gain, and offset (sliders), zoom (used with a Bahtinov mask), a crosshair (used to align the finder and the main scope) and a large window to help roughly collimate a Shmidt-Cassegrain when you have your hands on the Bob's Knobs, far from the laptop.

In terms of ergonomy, that would be a game changer

- Marc

I'm trying to establish occultation observing with Ekos, and while the streaming recording in .ser
format will work just fine I haven't been able to sort out how to build a sequence queue template
to use with the scheduler. Documentation and custom controls seem to indicate this is possible,
but I haven't been able to set this up. Is there documentation for setting up streaming from the
sequencer?

Thanks

Hi,
I would also like to have this feature! If there is no design document I can try to make one, however I have no experience in planetary imaging, so it might be quite lacking...

I'll start with some items I think are needed, maybe some more experienced people can add their own:
- ability to create capture sequences to be used in planner
- control of resolution, FPS
- settings: ISO/gain, gamma
- capture duration
- check after the capture if the target is still in frame, otherwise recenter the target

Bye
Andrea

This seems to be a rather significant effort when AstroDMX Capture (www.astrodmx-capture.org.uk/) as of version 2.0.2, support now includes INDI mount, camera, focuser and filter wheels. I just loaded it up on my Stellarmate X Beelink Mini and it's working pretty well. My scope is currently configured for DSOs so I'll try some DSO captures but with INDI support it's a pretty powerful tool for planetary imaging, is supported on all the same platforms as EKOS, and is probably the project we most want to throw our support behind.

Also, EKOS is pretty complicated as is

But AstroDMX does not seem to be open source... or is it?

Bye
Andrea