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.

Read More...