Hi Blaise,

I have a the API documentation. Very poor but she has the credit to exist.
I will try to work on the ROI implementation.
I seen your code and seriously he is clean.
Also, Do you think it's a good idea to propose all behavior of the camera that are "forced" to be programming by users ?

Regards

Hi Jon,

I'm pretty new to Ekos too
Some years ago, I used my own software (qastrocam-g2).
Then, I had a break with astronomy. But I'm back now !

Ekos records video streaming as ".SER" files.

I started to work on the "live view" today.
Hope I will be finished soon.

Thanks for your code review ! LOL

Best regards !

Blaise

PS : 3 years ago, I was in charge of our JEE Application servers. I didn't code a lot in Java, but I did a lot of troubleshooting in production

Hi Christian,

Thanks for you review.

Concerning the hard coded settings, the main reasons are :

- I wanted the driver to be available in a short time
- Some settings are inappropriate for astronomy, especially with INDI.
- In my mind, the SDK has been developed for standard cameras, and then patched for astronomy. Some "GetCapabilities" results are wrong, we can't trust it.

But I'm open to work on these features for the next version.

Best regards !

Blaise

Hi,

Sorry, I forgot to say : binning done (software binning)

Best regards,

Blaise

Hi,

Just pushed the first "stream enabled" version.

I think I will soon ask for a pull request.

There is a lot of possible improvements, but in my mind this first version is usable.

Feel free to send me any comments about my code.

Best regards,

Blaise

Blaise,

I checked binning yesterday. Seemed good. I'll check "stream enabled" today.

I did look at the v4l2 driver using my SV105 as a test. The indi control panel does have a significant image control (hue, saturation, et al) screen. That said, I'm not certain that it isn't a bit buggy, though I didn't take time to do a thorough test of v4l2.

*JC*

Blaise,

I'm not a previous user of Ekos LiveView, but I think there may be issues. Using a field spotting scope with the camera in daytime, I got reasonable FITS images in the preview viewer. However, clicking live view gave me a dark gray screen. I know something was going on, because I could point the camera at the daytime sky and get a brighter gray and a complete dark with the cap on the camera. The SER file I received seemed very grainy and the resolution was not as set (1080P) as seen here in a SER header display from SER Player:
Header Details:
* FileId: LUCAM-RECORDER
* LuID: 0
* ColorID: 9 (GRBG)
* LittleEndian: 1
* ImageWidth: 960
* ImageHeight: 540
* PixelDepth: 16
* FrameCount: 37
* Observer: Unknown Observer
* Instrument: Unknown Instrument
* Telescope: Unknown Telescope
* DateTime: 28/05/0120 11:06:31.862589 (0x85de096a193462)
* DateTime_UTC: 28/06/2020 15:06:31.862603 (0x8d81b74d780d4ee)

I am not used to working with SER files, but may stack them later in Siril to see if anything more encouraging appears.

At this time, I am willing to "guess" that liveview is not working properly. I did play with gain and exposure duration with no obvious result. Although, changes to gain made significant impact to preview images.

*UPDATE*
I stacked the SER images in Siril and got nothing usable. It is possible I had the gain up too far when I made the SER video. Note, I am not willing to rule out "pilot error" with regard to these results. As I said, I am not used to SER video files. We may have a brief period of clear sky this evening. If so, I'll try again with the telescope.

Hi Jon,

Thanks for your tests. It really helps.

As already said, I'm not an Ekos expert.
I think using live view for capture is a miss usage.

Live view uses a "stream manager". The INDI API says :

<<
16bit frames are only supported in some recorders. You can send 16bit frames, but they will be downscaled to 8bit when necessary for streaming and recording purposes.
>>

<<
By default, the full image width and height are used for transmitting the data.
>>

In my mind, live view is for :

- live FOV corrections
- fast manual focus

It's a kind of "fast preview".

Then, you program a shooting plan and start it.
Then you process all your fits images

Am I wrong Knro ?

For pure planetary imaging, a would use AstroDmx instead of Ekos.
I think Ekos is more "DSO imaging" oriented.

In live view, you have to toggle the "bayer button" to get the frames. I don't know why. I asked to Knro. Exposure time is also much shorter.
But you're right, live view needs more work.

Best regards !

Blaise

I just tested the driver on x86 32 bits.

It works as expected.

For the "live view", I think I will disable the feature until really understand what I'm doing.

Best regards.

Blaise

Blaise,

Good to know (and clearly, I did not). My primary use of live view is focus and alignment, but toggling the bayer button would not have jumped to mind as a method to enable the frames. I did play with the frames per second settings in the hope of getting an image, but that didn't help.

There is, of course, great value in knowing what a rank amateur or otherwise inept operator would do with a particular piece of software. I am pleased to provide that service.

thx8411 wrote: Hi Jon,

Thanks for your tests. It really helps.

As already said, I'm not an Ekos expert.
I think using live view for capture is a miss usage.

Live view uses a "stream manager". The INDI API says :

<<
16bit frames are only supported in some recorders. You can send 16bit frames, but they will be downscaled to 8bit when necessary for streaming and recording purposes.
>>

<<
By default, the full image width and height are used for transmitting the data.
>>

In my mind, live view is for :

- live FOV corrections
- fast manual focus

It's a kind of "fast preview".

Then, you program a shooting plan and start it.
Then you process all your fits images

Am I wrong Knro ?

For pure planetary imaging, a would use AstroDmx instead of Ekos.
I think Ekos is more "DSO imaging" oriented.

In live view, you have to toggle the "bayer button" to get the frames. I don't know why. I asked to Knro. Exposure time is also much shorter.
But you're right, live view needs more work.

Best regards !

Blaise

Currently, there is no sure way a client can learn that the incoming stream is Mono or Bayered. Some cameras (like ZWO) can send in Mono, RGB24, or Bayered. The way Ekos tells the difference between between mono/bayer and RGB24 is by size. I suppose maybe there is a possibility to change the format from the generic .stream or .stream_rgb24 or .stream_bayer ...etc. but this needs some where and also updated documentation. We can't break backward compatibility as well.

Hello,

@Jon, you're far from being an inept operator

In France, we talk about "monkey testing". I don't know if you have something equivalent in USA

Thanks for your help.

This bayer toggle button issue could be a bug.

@knro

When building and running my driver for the i386 target, I use INDI 1.7.6 (the last one available for 32 bit, right ?), and "live view" works as expected :
- grey frame by default
- color frame when toggling the button

When building and running with INDI 1.8.5 :
- no frames by default
- color frame when toggling the button

I use the same Ekos client in each case :

INDI 1.7.6 :
- server in a virtual machine, ubuntu 18.04 i386 (indi 1.7.6)
- Ekos client on the host, ubuntu 18.04 amd64 (indi 1.8.5)

INDI 1.8.5 :
- server and Ekos client on the same host, ubuntu 18.04 amd64

Am I doing something wrong, or could it be a regression ?
Or something to do with 32/64 bits ?

I made 2 temporary debian packages, for easier testing, for i386 and amd64 targets

drive.google.com/drive/folders/1hFZUCZle...Tnz77kb2?usp=sharing

Best regards !

Blaise