×

INDI Library v1.9.2 Released (14 Sep 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones.

Management of large sensors in Raspberry pi

  • Posts: 12
  • Thank you received: 6
So, I think I have some good news to report.

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.
The following user(s) said Thank You: Alfred
5 months 2 weeks ago #69938
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 6
I have more information now.

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!!
The following user(s) said Thank You: Alfred, Rafael Schlegel
Last edit: 5 months 2 weeks ago by John Mocenigo.
5 months 2 weeks ago #69964

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 6
Last message from me on this topic...

I ran  AstroPi3 to set-up my 64-bit OS raspberry and after that the magnification problem I mentioned in my earlier posts went away. It might have been something specifically in that script or it might be that - as part of the script - it does an 'apt update' and an 'apt upgrade' and with a new beta of the 64-bit OS just released on April 9, it may have picked up a fix from that.

I don't really know, but all I know is it all works now so I'm happy.
The following user(s) said Thank You: Alfred, Rafael Schlegel
5 months 2 weeks ago #69977

Please Log in or Create an account to join the conversation.

Time to create page: 0.599 seconds