I am not sure if this request belongs here or somewhere else. The FITS viewer seems to be an integral part of Kstars.

I observe several issues with the current FITS viewer:

1. Any changes to the image representation actually changes the data and cannot be made undone. E.g. doing an auto stretch. I would prefer to never change the actual image data, but only apply changes to the view, e.g. auto-stretch, various stretch options. E.g. Siril does it this way.
2. Remember the last viewing settings (e.g. auto-stretch, log) per camera. Currently, when applying auto-stretch in a sequence, it is reset to default when the next image is loaded.
3. FITS viewers in different tabs should be allowed different independent settings. I would like to switch off auto-stretch for the Camera tab, but enable it for the Align tab (to see how well stars are being seen).

Or is there a possibility to use an external FITS viewer?

Maybe I am using it wrong. Any thoughts, suggestions?

CS
Guido

If your issue #1 is correct - that's scary! A viewer should be just that - not an editor.

PixInsight can show FITS images and histograms but it may not be convenient to use during an observing session.

Guido,
What makes you believe that changing the view settings changes the raw data?
The only way that the data should change is if you save the changes.
Paul

OK, maybe I got the wrong impression. When auto-stretch was applied I cannot un-apply it and also the histogram now shows the new pixel values. From that I wrongly deduced that the original pixel values were changed.
I was used to the Siril GUI, which uses a drop down menu where you can choose between "Linear", "Logarithm", "Square Root", "Squared", "Asinh", "AustoStretch", "Histogram". Here you can always go back to "Linear".

To be more precise: When I open a FITS from Kstars and the EKOS option "FITS" -> "Auto Stretch" is set, I cannot get back to the unstretched view. Or at least, I did not find a "reset" button in the FITS viewer.
Yes, there is an "Undo", but only for manually applying "View" options.

Well, my proposed improvement would then be to add an "Original" or "Linear" to the list in the "View" menu, which should revert the view to the original, linear image.

CS
Guido

I agree with Guido that it seems not possible to view unstretched after stretching, but I agree with the others, that this stretching does not seem to affect the raw data--when I download these images, they are not stretched. In fact I view with PixInsight, instead of fits-viewer (after transfering a couple FITs files from my Pi to my mac) just for just this reason.

I doubt fixing this would require a totally re-done fits viewer, but would be a nice feature in a future release.

I'd add a 4th request: My fits viewer crashes if I play with it much. Not sure what causes the crash, but it brings down KStars/Ekos with it. Therefore, I rarely do much with it for fear it will crash and end my imaging session. This has been the case for as long as I've been running Ekos on the Pi (all releases since Fall 2018). I view the recent image with fits-viewer, and from time to time might zoom in if I'm focusing manually, but other than that, my work-around is to stay away from it during an imaging session.

I guess I should enable to fits viewer logs and somehow cause a crash (wouldn't be hard) and send it in. I assume I'm not the only one seeing these crashes, though.

FWIW, I just had a crash. It's daytime, but I just booted up the Pi and upgraded to KStars 3.2 on my stellarmateOS Raspberry Pi. I wanted to see if it became more reliable with release 3.2. I had no devices connected. Once installed, I connected via the simulators profile, took a simulator image in the capture tab (that was the only way I could start the fits viewer--hitting the toggle fits viewer button on kstars didn't start it). The I file-->opened a couple fits files on my local disk and started playing with them (looking at stats and histograms and such) and sure enough the view and kstars/ekos/indi all crashed in a few minutes.

Hy

Testing the kstars/ekos ecosystem, I also had some crashes just by trying to display some stats or histograms of previously acquired images. No real stress, just looking at some values to see if there is any risk of saturation or so. But 1 time of 3, pressing such a button in the fits viewer just makes the whole kstars/ekos stack go away, no remission. That major instability kept me away from ekos, and makes me use ccdciel that is more reliable.

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?