Excellent, this could be the problem that has been plaguing me for some time. I haven't had time to look into it more, but will have to try some .ser again to see.

Would appreciate if someone can take a look at the code and identify the issue.

I had the same issue with the video files i recorded with Kstars/Ekos during the weekend.
My camera is a ToupTek GP-1200-KMB Mono and I was recording in full resolution (1280x960).
IAccording to the manual my camera supports a bit depth of 12.

In the INDI Control Panel inside KStars I selected the camera and on the Image Info tab in it says "Bits per pixel: 16".
And on the Controls tab I can see that "Mono 16" is selected. The only other option is "Mono 8".

I wonder if this is the issue for me? Camera supports only 12 bits but INDI is configured for 16?

However, the live view looked good and recording went fine.
I also captured some normal frames that looks fine (see attached image).

But the movies I recorded with the live view (ser format) looks very weird when i see them in AutoStakkert and I am not even able to open them in PIPP.
The moon appears twice on the videos and it does not look at all like the single frames.
The 2 moons looks like they are made of white and black noise.

If I reduce the SER scaling in Autostakkert to 8 bit there are still 2 moons and each of them looks a bit like the single frames I captured (but much darker).
If I turn up the brightness to 8x the 2 moons starts looking much more like the single frames, but it is obvious that the greyscale quality is much worse.

PIPP shows me this header details for one of the ser files:


is there any way I can fix the videofiles so I can stack them?

I can confirm that I can record video files that works fine if I select "Mono 8" on the Controls tab.
So I will do that going forward. But I still hope to save the videos I took during the weekend if anyone has a tip I will be very happy.

BTW, I can also confirm that trying to record cropped videos from the Live view results in useless video files no matter if "Mono 8" or "Mono 16" are selected.

EDIT: I used a hex editor to change the bit depth in the SER file header from 16 bit to 8 bit. It made it possible to open and watch the files but the video stream was corrupted and the images could not be used for stacking. So I have to delete the files and capture new ones with "Mono 8" next time I have clear skies.

I played a bit around and it looks like Ekos always dumps full resolution 8 bit depth SER videos when recording from the live view (with my camera at least).
However, the SER header gets the correct information about bit depth (Based on INDI settings) and resolution (Based on live view frame size).

If anyone can point me to the place in the code where video files are written to disk I can try to take a look at it.
I am a developer by profession and have some C++ experience from years back, but I have no experience with the KStars/Ekos code or INDI.

Right so when live streaming, bit-depth is automatically reduced to 8bit to help make it faster. This is done in INDI. Thanks for offering to help, it is very much required to improve streaming & recording issues in INDI. You can find the logic in the function asyncStream in streammanager.cpp in INDI.

Right now, it's downscaling to 8bit. Though I can see that one improvement could be to immediately record the data before performing the downscaling. At any rate, I'm open to ideas for improvement. A few weeks ago I had to disable the threading for asyncStream when recording is active as I couldn't trace back a thread issue with file descriptors. Right now it's running on the main thread so it's slower but works OK. If you can also investigate this part it would be great!

I would like to set it up locally on my machine so I can debug it.
I guess that it is possible to make the local KStars project use the local INDI project so I can debug it and try out my code changes.

And I guess that you already have that set up so any suggestions would be great before I try to make it work on my own.
I am using Debian for the task.

Yes absolutely. You can checkout the documentation + video here: indilib.org/develop/developer-manual/163...ent-environment.html

Basically, in Ekos, you select "remote" but keep the host as localhost. You can then start INDI driver on command line, or preferably in QtCreator so you can debug easily as shown above.

Hello Any update on this issue? Have you made any progress?

Here in Denmark we have had clear skies for several days in a row now so I have not spent much time on debugging the issue yet.
But my development setup is ready (following the link you sent) and Ihave verified that I am able to debug the local indi code by connecting in Ekos as you described above.
Everything is working, now I just need some time to debug and see what I can discover

Yesterday, I read through the INDI developer manual to get a better understanding before I start debugging.

I just gave it a try.
My breakpoints in this file are activated and stops the debugger:
/indi/indiserver.c

But unfortunately my breakpoints in this file are not activated and does not stop the debugger:
/indi/libs/stream/streammanager.cpp

Do I need to attach the debugger to another process in order to catch the breakpoints in this file?

---
Here is what I did:
Build Configuration set to Debug in Qt Creator.
Run settings set to indiserver with these parameters:
-v indi_simulator_ccd indi_simulator_telescope

Selected Debug -> indiserver in the lower left of Qt creator.
Clicked Start Debugging button.

indiserver starts up and I am able to connect to it using KStars.
Breakpoints in the indiserver code is activated but not breakpoints in any other "module".

I also tried selecting Debug -> indi_simulator_ccd
Before I started debugging and this activated breakpoints in the indi_simulator_ccd code but now the indiserver is not running.

I then tried to debus indi_simulator_ccd and start the indiserver on the side.
But here it does not look like any breakpoints are activated at all

Any tips on how to debug different parts of indi in Qt Creator would be nice.

Yes, put set follow-fork-mode child in the GDB options. Check below:



You can also start it as:

Then whenever you make changes to the CCD simulator, you can simply compile and run again without running sudo make install. Please note that when you stop the debugger, it does not kill indiserver. So if you want to truly restart the indiserver, you must type in a terminal pkill indiserver before clicking debug again.