Hy,
You are not alone, I don't play with the FITS viewer much because of its tendency to cause a Kstars/Ekos abort.
Anything unsaved is lost so rather than risk it I only do things I know don't cause an issue.
Paul

Now that I'm running on a Raspberry Pi 4 with more memory, I can compile and test KStars. So I thought I'd look and see if I could figure out why the fitsviewer was crashing so much.

The irony is, I haven't been able get it to crash amymore! I don't know if it is because of release v3.3.4 , or due to the fact I'm running on a Raspberry Pi 4b, or the fact I'm now using Raspbian with my RPi4, or that the computer has more memory (currently using the 2Gb version, though my 4Gb just came in).

I guess I can't complain--hopefully I'm not jinxing myself, and I'll continue to try and give the fitsviewer a workout, but for now all's well.
Hy

Yes it would be nice to have features that would let you apply screen transfer functionality instead of stretching. Maybe a future release can have that. Jasem as looking for a GSOC student to do exactly this a few months ago. Volunteers are welcome!

The data that gets saved in the sequence has no stretch applied to it, it is raw data. Any stretch that is done is solely for viewing purposes and won’t affect the data unless you save it separately.

I believe any fitsviewer crashing behavior you see on the pi is probably memory related. Image manipulation is very memory intensive. Is this a 3b or 3b+? Do you have ZRAM installed? 1 GB of memory is really not enough to do a lot of manipulating.

Hi all,

I'm late to the conversation, but this topic has been in my head for a couple months now. I'd like to chime in.

First, I'd like to add to the list of people who experience whole stack crashes when fitsviewer has a problem. It seems to happen for arbitrary use of features in fitsviewer, seemingly anything that goes beyond zooming, panning and using some of the information tabs (e.g., FITS header). The behavior is that suddenly I notice that nothing kstars-related will respond to clicks (kstars, fitsviewer, EKOS, INDI windows), then, after some time has passed, all windows disappear. I use a RPi for running INDI server and an Intel desktop machine with 32 GB RAM for kstars etc. so I don't think it's the RPi's limited memory causing this. (I've seen it happen when I just start up kstars to view FITS files and don't connect to the RPi)

Anyway, aside from an obvious suggestion to fix that problem, here are some other suggested improvements:

1. Make fitsviewer stand-alone. I'd like to use Linux to do quick views of FITS files, and fitsviewer would be handy for that independent of kstars. This also might make the system more robust, since if fitsviewer were its own process (is it now?) it would be less likely to bring the whole system down when it crashed.
2. I agree that manipulating the histogram and such gives the feeling that there's a permanent change in the FITS file. I'm glad there isn't. OTOH, it would be great if it were a lot easier to scale intensity. The best example of this is from Nebulosity: just type in the lower and upper values defining black and white and use a linear mapping of values between those limits. Neb does this extremely fast - no waiting for processing to happen. To go beyond that, the scaling that CCDStack does, providing a black point and a white point, plus DDP and gamma also happens very fast, but in my opinion is a "nice to have" (others may think differently). At the very least, it should be easier to understand what the black and white points are in the existing fitsviewer. Not clear at all if that information is present. An "autoscale" button would provide the default scaling; I like the idea that Guido had about saving a scaling (item 2 in his list).

Thanks for listening!

Charles

Right, there is no time to redo many of these issues in FITSViewer. The histogram needs some rework, but the crash that was caused by it is fixed now at least.

The code inside FITSData and FITSView is very slow and doesn't use any modern graphics library. There are some elements that perform parallel operation, but they're performing the _slow_ operations in parallel so there is that. No gamma/shadow controls that are quick and [/b]responsive[/b].

As Robert pointed out, we proposed FITSViewer Overhaul as Google Summer of Code project for 2019, but we didn't get any students. KStars is an open source application and I hope the community would step in to improve these issues for all. We recently had a small patch from a new developer (Mr. Hy) to improve the speed of the FITS statistics by an order of magnitude, so he is off to a great start!

So one thing that should be pointed out is that fitsviewer is really mostly just a container and GUI interface for a fitsview. There are a number of fitsviews In Ekos, in the summary screen, the align tab, the guide tab, and the focus tab. Ekos very much relies on fitsviews for a number of functions and the fitsviewer relies on both kstars and Ekos for many of its functions. Truly Separating them would remove a lot of functionality. That is not to say it wouldn’t be beneficial to have a separate stand alone fitsviewer, but removing fitsviewer from KStars would not be good. There are already a number of standalone fitsviewer programs out there, have you tried them?

Thanks for pointing out that about fitsviews. I was not suggesting that all be separated from Ekos, just that the fitsviewer might run in its own process or thread.

But anyway, I have not looked for any Linux FITS viewers out there. Perhaps this link is a good start? fits.gsfc.nasa.gov/fits_viewer.html

I see you're running Ubuntu 18.04. Gwenview will display all sorts of image files, .fits included.

It absolutely is. And especially for viewing astronomy fits files be sure to look at DS9 (IMHO).

Unfortunately there are not many FITS viewers that display color FITS from INDI. E.g. DS9 only displays grey values and does not recognize the bayer information in the header. Or am I missing something?

BTW, I did not experience a crash with the INDI Fits Viewer yet. But I only have a ZWO ASI 224mc with a small sensor (1304x976). That would also hint at a memory issue, but Jasem already said he had fixed it...

Guido

OK, now that I bought a ZWO ASI 294mc pro, I'll take this back!
I now also experience frequent crashes with displaying pictures of the new camera (11MP, 4144x2822) in Fits Viewer : often when applying Auto Stretch and reproducable when zooming in.

Is there anything I can do to help debugging?
KStars version: 3.3.8 build: 2019-11-16T00:06:30Z
running under Astroberry on a Pi3.

CS
Guido