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

I'm shocked to say you're right, it's not open source. I thought it was - certainly it doesn't look like Nicola has tried to monetize the software so wonder why he hasn't open sourced it?

I'll ask him...

AstroDMXCap is a fine program, but for what I'm doing I need a flexible sequencer. For a series
of targets, goto, platesolve, setup camera, start data at a given H:M:S, rinse, repeat up to 50 times
in a given night. I haven't worked with the Ekos scheduler in detail, but Ekos does support all these
functions, just not setting up a streaming data collection. Or does it?

Thanks,
Matt

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

No, to say it very clear: this is NO open source software with an applicable standard license we are used in the field of real open source and all the long term security for the code. You can read on their download page.

I suspect software, that only relies on a self-made “software license” text and seems to be “free” but is in fact not. Not in the sense of open code, where the community can distribute. There is no reference to an officially legal license text, this can change any time (either in the one or the other way ).

But, I do not have a problem with a real dual license for example like EKOS/Stellarmate as long as the major base of the software will be open source. I personally am not interested in another monolith software clone like N.I.N.A.. But hey, be free to use this if you think it's worth the effort. I'll rather stay with the long existing Stellarmate/EKOS which sources it ideas and development of projects like Google Summer of code and various high-end developers worldwide instead of one developer (Nicola Amanda Mackin). No offense, this is a free world.

But I do not like to run behind every new software trend.

I use Firecapture on an intel based stellarmate, this just works and until more powerful arm machines are available. It's as simple as this

Cheers, Axel

I heard from her (my apologies for misgendering you Nicola!) who indicated she didn't intend to either monetize nor open source DMXCapture.

As a sometime planetary imager, I tend to agree with Axel that adding real planetary imaging to the already overly complex EKOS UI seems to be wasted effort, versus perhaps a UI update (although honestly I find the EKOS UI perfectly fine versus trying to cram everything on a single screen) or adding livestacking to the desktop interface (right now I livestack with ASTAP which is also fine but a hassle with filters and calibration etc.) There are lots of excellent planetary imaging packages out there including FireCapture and AstroDMX so it's not like we don't have something. Honestly, planetary imaging is so different than DSO imaging (finicky to position the planet on the sensor for example) that right now I don't do planets because it's a hassle to dismantle my DSO rig and assembly a planetary rig with different filters, ADC, Barlow etc.)

That being said to meet the OP requirement it just sounds like the ability to capture a SER file instead of a FITS is a pretty simple requirement that won't require much change. From what I can tell there just needs to be a change to the Capture tab to include SER in the Format field instead of FITS, 8 or 16-bit. I guess there would need to be a duration field as well since the exposure would be needed.