Ressource limits and large images

[Wolfgang Reissenberger]

Sorry, forgot to mention the crash details:
/home/wolfgang/sterne-jaeger/git/indi/libs/lilxml.c(moremem): Failed to allocate memory.


> Am 22.05.2021 um 23:20 schrieb Wolfgang Reissenberger <sterne-jaeger at openfuture.de>:
> 
> Dear all,
> I’m experiencing currently crashes of EKOS running on a Raspberry 4 with Raspbian 10. Meanwhile, I can reproduce the error. The problem is that allocation of new memory fails when a new image gets loaded.
> 
> As a workaround I can resolve it if I turn off completely the FITS viewer.
> 
> To reproduce it, you need the current 32bit Raspbian 10 and do the following:
> - use CCD Simulator and increase the image size to the maximal vaules 8192x8192
> - run the focuser (one completed capture is sufficient)
> - run an alignment (2x2 binning is sufficient)
> - start a capture sequence
> Typically after the second frame, KStars crashes with 
> 
> The reason is, that we have several places where images and associated pixmaps are used: Manager, Focuser, Align, FitsViewer. In each place, at least one QImage and one QPixmap is stored. With the setup above, each QPixmap object is 256 MB.
> 
> One solution is that for such sensors we should recommend 64Bit OS versions. As far as I understand, 32Bit OS have a memory limit which we are touching with big frame sizes.
> 
> As an alternative, we could rework EKOS in such a way, that we shift all images to the FITS viewer and in case of a low resource mode, only one image is held at one time, i.e. capturing, focusing and alignment share the same pixmap. This would drastically reduce memory consumption.
> 
> What do you think about this?
> 
> Cheers
> Wolfgang
> 
> —
> Wolfgang Reissenberger
> 
> www.sterne-jaeger.de <http://www.sterne-jaeger.de/>
> TSA-120 + FSQ-85 | Avalon Linear + M-zero | Moravian G2-8300 + ASI 1600mm pro + ASI 6200mm pro
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210522/6a00dce8/attachment.htm>