DSO astrophotography is very well developed in KStars/Ekos. But astrophotography isn't all about DSO, there is also planetary imaging Here is the sad part - KStars/Ekos is a rudimentary tool for such purpose. But I love KStars/Ekos! And I would like to see it as the BEST and UNIVERSAL tool for astrophotography in the Unix world So here is my list of what should be changed/improved/added (I am using DMK camera for planetary imaging):
1) Video Stream must not block Video Record and vice-versa;
2) Add option of frame divisor for Video Stream. It will be very useful for users with remotely connected cameras (recording e.g. with 60 fps, but viewing with 5 fps);
3) Add option for Record Directory;
4) Record File option must not ask for full path, just the name;
5) Record File option must not be static, but dynamic (timestamp, filter name, duration, etc.)
6) Add Duration option;
7) Add Number of Frames option;
Add the ability of batch work (e.g. LRGB recording. It is damn important to record fast Jupiter and Saturn, so eliminating manual work is crucial);
9) Add to Video Stream window options for setting different crosshairs.

Now I have few related questions:
1) Does Upload option choose the destination for Record File? Or it affects only images?
2) Why default value for Snoop Devices -> Filter is CCD Simulator and not Filter Simulator?
3) What units are used for Exposure (Absolute)? It doesn't seem to be ms because the same setting in oaCapture is burning the planet (I was recording yesterday Venus)...
4) What are doing Stack options? Is anywhere some clear explanations?

For now it's all, if I will remember more I will write

Yeah, one more thing I remembered (I am recording now Venus) - please add histogram, very important for not getting "onion rings" on the gas giants

I opened the files recorded yesterday in the PIPP. There are 3 problems:
1) I asked 16 bit, but PIPP reports 8 - it seems corresponding setting doesn't affect SER file recording;
2) PIPP reports this error (but still works) - "Error: Timestamps should be present but file is too short for this". According to specifications I found (www.grischa-hahn.homepage.t-online.de/astro/ser/) there should be timestamps;
3) SER files bigger than 2GB gets rejected by PIPP - it said that there are no frames, even though its file info reported the number of frames as expected. It is not clear whose problem is this one - SER file format, PIPP or KStars

Wow that's quite a list. Unfortunately, I'm pretty much the only one working on INDI/Ekos now and these stuff will probably take a very long time to see the light. Do you have any programming background? Any extra help for such features are welcome!

Yeah, I understand that it will take time! I am good at bash scripting, know some C, played with C++ and Python (I will be honest - I still don't know what is class ) and... that's all I think So from my side I would like to help, but I lack a lot necessary knowledge I graduated electronics, not programming

As for now there are few critical features for me:
1) Record File option must not be static, but dynamic (timestamp, filter name, duration, etc.). This one if I understand it right can be taken from Ekos;
2) 16 bit SER recording (a link to depth setting must be added);
3) Histogram. Actually it is enough just to indicate the value of brightest pixel in the image.
This things are vital for me at the moment, I will be very thankful for their implementation. All the rest I can wait

One more thing - can you please answer the questions I previously gave

Hi,
I just commited a version with some of your wishes:
- Simultaneous Stream/Record/Expose. Beware that taking an exposure may change the expose time after while in streaming/recording.
- Streaming rate divisor
- Record files may contain some patterns to make them dynamic: _D_ for the date, _H_ for time, _T_ for a timestamp and _F_ for filtername if any. Concerning duration and number frames, it would require to create a temp file and rename it at the end of recording, unless using the user input duration/Frame count. Is this absolutely necessary ?
-I disabled stacking and color processing. I also disable 8/16bits settings: if input is 16bits, record and expose frames will be 16bits (I don't think Kstars supports 16bits streaming), otherwise it will be 8bits. Anyway the only 16bits supported format is gray16 (Y16).

Concerning SER recording, I've read the spec and wrote -1 in the Date field, thus meaning there is no timestamp in the file. I now write a 0, maybe that would work better with PIPP. Concerning histograms I started an indi-opencv driver and tried it there. But I think it would be more a client-side operation. If you only need the value of the brightest pixel, a max should be enough for a mono image, the same for a colored image after conversion to mono. Am I right ?

Concerning your questions:
- upload settings are only for images (part of INDI::CCD)
- for the filter snooping device, don't know why it is set to CCD simulator, maybe it also implements a filter wheel
- Exposure(Absolute) is the Exposure time in 1/10000 second unit, it is defined in the V4L2 API and present only in some devices.
- Stacking options were some experimental stuff to stack video frames in order to generate a long exposure frame.

Great update Jean-Luc! Much appreciated! So yes KStars does not support 16bit streaming. You can get the max value in an IMAGE in the FITS Viewer stat tool, but not for a stream.

I'm also quite interested in indi-opencv!! But what kind of cameras does it work on? The regular webcams? Is it a frontend to V4L2?

So we can get the max value by taking an exposure. But this may require many manipulations, I don't know if this is enough user friendly. Concerning Kstars streaming, I just remember to have seen what I think is a small bug: the callback used when hiding the streaming window sends a STREAM OFF to the driver. This is ok when the streaming is stopped by closing the streaming window. But it seems that it also arises when disconnecting the device and, at that moment, the driver already has suppressed his properties. So Kstars complains that the property is no longer there and sometimes crashes at the next reconnection and streaming.

I put indi-opencv on sourceforge here . It uses V4L2 as a backend on Linux, together with gstreamer for decoding/encoding. Actually you can open AVI files as inputs, or use a camera index directly related to /dev/video decices. You don't have direct access to the V4L2 device, but you can grab frames without decoding (I didn't test it yet). And you can record directly in AVI format for those interested in.

Great! Looking forward to it! I think I fixed the crash, there was an issue in ser::close in the V4L2 driver and also in KStars when disconnect is invoked, I can't reproduce the crash now.

Thanks for fixing the bug. Actually I did'nt know if this was due to the driver or not. Concerning the update (not sure if it is so great , would see;-)) I believe that a rewrite from scratch would be nice after fixing its features. I've just adapted the code to the INDI CCD interface, and knowing little about V4L2 and Indi, have added much weird code (this is unfortunately my style of programming). I also still think of using dynamic loading (I think libdl lies in libc so no dependencies) to add decoding library, libv4lconvert may be a good candidate. As it is in v4l2-utils, maybe it comes pre-installed in many distributions/platforms. For my next winter nights...