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.
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.
Mount: Skywatcher HEQ5 Pro | Main Scope: William Optics GT81 | Guide Scope: ZWO OAG | Imaging Camera: ZWO ASI183MM Pro | Guiding Camera: ASI120MM-Mini | Accessories: ZWO EAF, ZWO EFW 8 x 1.25", Pegasus Pocket Powerbox advance, RPi4
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 van Reeven
ASI6200MM and 7 slot 2" filter wheel with a SkyWatcher Esprit 80 ED on a SkyWatcher HEQ5-Pro
ASI1600MM-Pro Cooled and 5 slot 1.25" filter wheel with an 8" TS Ritchey-Chrétien on a SkyWatcher EQ6-R
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?
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.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
On the 64-bit Raspbian OS and 8GB RPi4 that I am experimenting on, I tried rebuilding Indi and kstars again today using fresh clones from GitHub.It reports as being Version 3.5.3 Beta. It not only built, but this time I was able to use it to capture images from my ASI6200MC, which I was unable to do earlier.
I used the FITS Viewer with debayering checked and adaptive scaling checked, but auto-stretch not checked and also set it to reuse the same FITS window for each image. I then took 20 bias images with my camera (I am at my desk so I could not attach the camera to the telescope and take Lights) and they all displayed with no crash.Incidentally, though auto-stretch was NOT checked, it still auto-stretched. That appears to be a side-effect of having adaptive scaling checked.
I then unchecked adaptive scaling and ran another 20 bias captures. Incidentally, this is when I noticed that auto-stretching was occurring with adaptive scaling because it wasn't happening now, so I went ahead and checked auto-stretching. Anyhow, again, no crash.
In the first instance the system memory monitor reported usage fluctuating between 3GB and 3.75GB. In the second case it was between 3GB and 3.6GB. Those numbers are just from eye-balling it.
Unfortunately I don't know whether the good news is because of the 64-bit OS or because of adaptive scaling or just some other improvement in 3.5.3 Beta.
I have yet another 4GB RPi4, so I will attempt to get the bleeding-edge copy loaded on to that over the next day or two and try to determine if the 64-bit OS had any hand in things not crashing or if it was the other possibilities.
I do have one outstanding question on a related matter that I hope I can get help on (feel free to create a new thread to answer -- I am not fully up to speed on this interface to do that)... anyhow, when I use the version I built under the 64-bit OS, it appears as if all windows, icons, fonts, etc. are magnified by about a factor of 2. Even the start-up splash screen is oversized (I am attaching a screen shot). I have tried playing with the system settings to reduce font and icon sizes, but that isn't fixing the root problem (e.g., no effect on the splash screen). Is there some -geometry or other setting that I need to imbed in some start-up file so that things are properly scaled? It is very annoying as the EKOS window extends outside of my VNC window and I have to drag the window up and down to alternate access the top of the window and access the bottom of the window.
I built on a 4GB RPi4 using the standard raspbian 32-bit OS and ran essentially the same tests that I ran yesterday on the 64-bit OS build using a ASI6200MC camera.
Firstly, the auto-stretching automatically happening when adaptive sampling is turned on did NOT occur (as it had yesterday on the 64-bit OS). So either that was fixed or I hallucinated it yesterday.
In any event, I ran a sequence of 20 Bias image captures with debayering turned on, adaptive sampling turned on and auto-stretch turned on. I got the message about not being able to allocate the debayering buffer while processing the 9th image in the sequence, after which kstars crashed. Note: the memory monitor says the system has 3.32GB available and the monitor never showed resource use exceeding 2GB, but of course there could have been a spike that did not register prior to the crash.
Next I ran another 20 bias image sequence with debayering turned off, limited resource turned on, adaptive sampling turned on and auto-stretch turned on. The entire 20 sequence completed successfully.
Next I ran another 20 bias image sequence with debayering turned off, limited resource turned on, adaptive sampling turned OFF and auto-stretch turned on. KStars crashed after about 3 images.
So, what I get out of this is the following:
adaptive sampling allows kstars to handle large sensor cameras WITH NO debayering on a 32-bit OS 4GB RPi4.
with or WITHOUT adaptive sampling, kstars can handle large sensor cameras WITH debayering on a 64-bit OS 8GB RPi4.
So, for large sensor camera, adaptive sampling is needed improvement, but it is not sufficient to allow debayered images. Running KStars on a 64-bit OS RPi4, however, is a better option, if available, as it also allows debayering.
So, this goes back to my plaintive query at the end of my previous post: does anyone know how to control the overall "magnification" of an app on RPi4. As I mentioned, when I run kstars on the 64-bit OS, it appears as if it were magnified and so has ridiculously large windows that don't always fit within the allotted screen size. Other applications (terminal, web browser) don't exhibit that magnification. So, if anyone knows how to control that in one of the application start-up files, please, please tell me!!