It appears with the increasing size of CMOS sensors, we need to be more careful about RAM utilization. Currently, Ekos eats a lot of RAM and this could be very well better optimized.

One issue I ran across is that for very large sensors, it's quite possible to run out of memory for 1GB and 2GB models of the raspberry pi. For even larger sensors, not even 8GB is good, not because it doesn't have enough memory, because the process does not have access to a lot of memory under 32bit Raspbian OS.

So this lead me to think of a way to solve this. I think one way to resolve this is to simply skip loading the raw image altogether and perform a conversion to a medium quality JPEG on the fly and load that instead. This would enable users at least to keep capturing the images AS IS, but reduce the load on RAM from previews. Another option would be to disable FITS Viewer completely, but for any operations that require an image (Focus, align..etc), we're again back to the same issue.

Maybe another idea is to release the raw data buffer completely after the initial stretch is done. So no more operations on the raw buffer because it's gone. That would cut utilization by half. Any thoughts on this?

I honestly have not noted any issues with my ASI6200MM camera and a Raspberry Pi 4 with 4 Gb of memory. Polar alignment and focusing work absolutely fine. I have disabled the FITS preview when images are taken but that’s because I don’t like it and not for performance reasons. Perhaps it would be better to first investigate where and how people experience issues to be better able to address those? Unless that is already clear of course

I like this idea the most!

I need FITS Viewer while I do my manual operations and keep track of things while I image (not full automated yet). I also wouldn't like a conversion from RAW to JPEG, as that would slow down download times even more: I just posted a wishlist where I say that I would love if download times wouldn't be affected by dithering or HFR calculations. JPEG conversion would probably add to the time for the image to be displayed and increase the timer before the next exposure is started even more.

But, yes, I would love some RAM optimization. I have a Raspberry Pi 4 4GB and with everything running (KStars, EKOS, PHD2 and FITS Viewer) I am at about 50% RAM consumption. Sometimes PHD2 even hangs and does not issue any command for multiple cycles of guide camera exposures (might be 10-20s, even)...

Surely a simpler method without coding would be to use the "inbuilt" networking ability of Indi (e.g. chaining).Then ,perhaps using the newer Compute 4 (they have EMMC storage) RPI's, create a dedicated Large Cmos Camera server but using "command Line" Indiserver only (NO GUI,System X) to maximise resources .

The initial capture(s) could be stored on these dedicated Large Cmos servers and transfered in "background" mode so not to effect camera capture speeds. Any conversion could then be done on the "other" Indiserver(s) which would have had resources freed by moving the Large Cmos camera.

I accept this would mean extra hardware (RPI's)/networking(wired hub unless you rely on 5GH wireless) hardware costs,perhaps slower image viewing due to transfers but it would be with the minimal amount of software changes to existing Indi structure - until 64bit drivers are created.

Just an Idea !

Couldn't you have the image load it into the fits viewer as a 2x2 bin essentially cutting the file size in half? I know this is almost the same thing as creating a jpeg, but just an idea if people want to keep the raw data in the fits viewer.

I posted a request long ago.

indilib.org/forum/wish-list/5891-use-str...uture-live-stac.html

Ekos category that do not save images (preview, focus processing, PlateSolving, etc.), it is more comfortable to switch to the process of cropping frames in stream mode (the image displayed in live video in Ekos).
It would be even better if an option was added to easily change the pixel size of the streaming.

Hi. I have a ASI6200MC and if I shut-off the FITS viewer and am careful about quitting the Preview window after each use and use some binning when focusing / aligning, I can get by barely. Any slip up and it crashes. Even when careful, a crash is likely after several hours of continuous operation. I have a RPi4 with 4GB and an RPi4 with 8GB. I tried loading the 8GB with the arm64 raspbian OS (beta) and compiling Kstars/EKOS from scratch to get a 64-bit version to determine if the extra memory access alleviates the problem. I have run into a showstopper with that approach ("Exposure failed after 3 attempts") so I don't know if it would help. Has anyone successfully built an arm64 version? If that solves the problem, that seems like the best way to make all users happy (those that don't need it and want to stick with their current Raspberry and those that want it enough that they would not mind springing for an 8GB Raspberry and using the 64-bit OS.

Anyhow, for the here and now, perhaps a software binning option just for the FITS Viewer display (i.e., independent of workflow image capture) is another alternative?

It is definitely worthwhile to provide an option to release all FITS Viewer image related memory once the image is displayed. That should save having to kill the previewer and should also allow one to keep the FITS Viewer option on.

I am new to astrophotography having recently retired and taken it up as a hobby. I am both amazed and thankful for KStars/EKOS/INDI. Big sensor, however, are only likely to become more prevalent and need to be addressed, the sooner the better (IMHO).

I have an ASI6200MM and without using the FITS viewer my 4 Gb RPi can run all night long without crashing. I agree that it is prone to crashes when using the alignment and/or focus modules so I try to avoid that as much as possible.

Note that for color cameras the auto-debayer option can be disabled as well to save additional memory.

I have tried using the Limited Resources Mode but that seems to only reduce the resolution of consequent images leading rapidly to an unusable situation.


Wouter

In my case: I have EKOS installed on RPI4 (4Gb) and I uses VNC to remote from my MacBook Air 11". I set VNC the resolution is 1366 * 768 which matches the monitor display. My imaging camera is Atik 490ex which the image size is 3379*2903. You can see the image is at a much higher resolution than my monitor. 

At my imaging session, I usually has to zoom in and out to check a few things:

At low resolution, I wanted to see the overall image like the object position, orientations are good.
At high resolution, I'd like to check for alignment (i.e. any star trailing) or may be focus shift or look for other artifacts

For my case, loading the full image into the memory is in fact a waste of resources - my monitor cannot display all the pixels at the same time.
If I want to check focus shifts or alignment problems I only need to look at part of the image to find out.

I'm not sure a magnifying glass approach would be worth to look at? Like the FITS viewer would initially show the preview at low resolution, which can be pre-generated. Display this low-resolution at the FITS viewer. Then on mouse-over (or may be a mouseclick is better) to load that part of the image from disk with an area say 50x50 and show that part as 1:1 (or may be magnified 2:1) in a "magnified" image box?

Stephen

In KStars v3.5.2, I added "Adaptive Sampling" to reduce the size used by the image on the screen. However, that came with a bug that made capturing more images progressively worse until it crashes. This has been fixed in v3.5.3 beta, but it still requires more testing. If you can use the beta, that would be great.

Would be great to see a MacOS 3.5.3 too. Rob's latest build script still doesn't work for me.

Action: compile for kde/frameworks/tier1/kguiaddons:5.77.0 FAILED
*** Craft all failed: kde/frameworks/tier1/kguiaddons after 2 seconds ***
fatal error: package kde/frameworks/tier1/kguiaddons all failed

"Adaptive Sampling" Is that why I saw my focus frames appeared to have a progressively lower resolution? It didn't seem to harm the focus routine, but I would only see a pixelated mess in the module's image viewer after a while.