Sony USB ASCOM Driver question

Post Reply
dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Sony USB ASCOM Driver question

Post by dougforpres » Mon Jan 06, 2020 12:03 am

Hi,

I'm a little late to the Sony Driver party, but I too have written a basic driver that communicates directly with Sony Cameras over USB.
It supports BULB mode on the camera along with the ability to pull either RGB or RGGB data and return it to SharpCap (in addition to saving the actual camera files).

I have the driver working with SharpCap, but I would be interested in discussing how I can expose the "LiveView" feature of many Sony cameras.
LiveView gives a much lower resolution image, (only around 1024x680 in my testing) but at a much higher framerate (around 1-2 fps for my a6400), and supporting the camera's "Focus Assist" digital zoom.

I've worked with the developer of (am I allowed to mention it?) APT and we came up with a solution whereby the software enables "FastReadout" when in preview-mode (only for this driver, to avoid issues with others), and disables it when it wants to take a real photo. This allows the driver to switch between the actual taking of photos and using LiveView - which is much quieter, faster, and less "shutter-y". (using ReadoutMode property is an alternative).

The above workaround is a hack as ASCOM Camera driver doesn't really support this kind of operation.

For more info: http://retro.kiwi/ascom-driver-for-sony-cameras/

Thanks
Doug

User avatar
admin
Site Admin
Posts: 3445
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sony USB ASCOM Driver question

Post by admin » Mon Jan 06, 2020 7:27 pm

Hi Doug,

that sounds great - no worries about mentioning APT - I use it too when using a DSLR ;)

My immediate thought on the live view problem was to register your ASCOM driver twice - once as 'Sony DSLR Bulb' and once as 'Sony DSLR Live View' - they can each report the appropriate resolution and set the camera into the right mode. The user of SharpCap (or other ASCOM compatible software) can just choose the appropriate driver.

Does that make sense? Robin

dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Re: Sony USB ASCOM Driver question

Post by dougforpres » Tue Jan 07, 2020 5:58 am

Thanks Robin,
It's definitely an option, and not one I had previously considered, thanks for the idea.
Once I get the driver more stable in SharpCap I'll look into doing that.

Expect a couple more posts from me asking about how SharpCap is dealing with data.. it seems to present image data (RGB48) differently to APT given the same data.

Doug

PS: Support already present for a6000 and a6400 - I'm hoping to have support for three different a7 variants soon! (just waiting on some info from a tester)

dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Re: Sony USB ASCOM Driver question

Post by dougforpres » Fri Jan 10, 2020 3:07 am

Hi again,

Development of the Sony driver is progressing well, and I've been able to add some newly supported cameras (now supports a number of Sony A7 variants).

I've noticed a couple of differences in how SharpCap renders images compared against APT.

When the driver is configured to return an RGB image, SharpCap displays the image:
1. Upside down, with respect to APT
2. B = [x, y, 0], G = [x, y, 1], R = [x, y, 2] (BGR) (APT expects data in order RGB)

When the driver is configured to return RGGB, the image is not inverted.

Again, I don't know which one (SharpCap/APT) is displaying the images correctly - it's just that the first app I integrated with was APT, so that is currently my "control".

Thanks
Doug

User avatar
admin
Site Admin
Posts: 3445
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sony USB ASCOM Driver question

Post by admin » Fri Jan 10, 2020 7:27 pm

Hi Doug,

I can understand the RGB/BGR thing - SharpCap generally assumes BGR pixel order as that matches the pixel order that Windows uses internally. It doesn't look like Ascom defines the order of the colour layers in the API standard - https://ascom-standards.org/Help/Platfo ... eArray.htm - no surprises there… Sadly there are too many things that are left undefined in that standard.

I'm afraid I don't understand the vertical flip problem straightaway. I do have code in SharpCap that flips the image under certain circumstances, but as far as I can see that's confined to the WebCam code and reading certain file formats when opening a file. I can't see any call to that code in the Ascom handling and in particular I can't see any that would depend on whether the image was RGB or RGGB. I would have expected SharpCap to always put the first data in the image array in the top left corner. Just to be clear, is the image inverted on screen in SharpCap or only in saved image files?

Cheers, Robin

dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Re: Sony USB ASCOM Driver question

Post by dougforpres » Sun Jan 12, 2020 12:22 am

Thanks for the comments.
I've updated the driver to support "Application Personalities"
When SharpCap is selected, the image will be auto v-flipped, and when set for RGB Colour images will be exported as BGR.

Re the invert thing, here's what I do:

For RAW/RGGB images:
* APT/SharpCap/NINA: Invert the raw image data returned by libraw in order for it to appear same as it does in image edit/view apps (need to check how the saved FIT files look)
* APT: Invert the libraw processed "RGB" data in order for it to appear same as it does in image edit/view apps
* SharpCap: Don't Invert the libraw "RGB" data in order for it to appear sane as it does in image edit/view apps (but transpose R/B)

I need to do some more testing, and save the raw bytes from each step to see whether the data is upside down or not... that'll take a little longer.

As it stands, the driver now delivers "right way up" image based on selected "Personality" :)

Doug

User avatar
admin
Site Admin
Posts: 3445
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sony USB ASCOM Driver question

Post by admin » Mon Jan 13, 2020 7:03 pm

Hi,

Good to hear it's coming along well. I must admit that I don't worry too much about which way up the image is for a particular camera because the image can easily be flipped depending on the geometry of the telescope you are using (refractor versus reflector versus Cassegrain, diagonal versus no diagonal).

Cheers, Robin

dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Re: Sony USB ASCOM Driver question

Post by dougforpres » Mon Jan 13, 2020 11:55 pm

Possible bug?
I found the "Memory" tab in settings. Whenever I adjust the live-stack slider it tells me I cannot go over 2048MB due to non-registered copy, but when I click "Apply" the slider reverts to 1024MB regardless of what I had it set to. (If I use "OK" to exit dialog, the value is reset to 1024 when I re-enter).

Doug

User avatar
admin
Site Admin
Posts: 3445
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sony USB ASCOM Driver question

Post by admin » Tue Jan 14, 2020 7:16 pm

Hi,

The 2048 MB limit is actually intended to apply to the sum of the two memory categories. That means that without buying the pro licence you really have no flexibility to adjust the two categories because the minimum for each category is 1024 MB. Initially, I had a lower minimum value for each category, but I found that people didn't have to turn it down very far to start hitting reliability issues with high megapixel cameras. Basically when I stopped the minimum from going below 1024 I never got round to updating the rest of the UI quite correctly to reflect that change.

Cheers, Robin

dougforpres
Posts: 6
Joined: Sun Jan 05, 2020 11:33 pm

Re: Sony USB ASCOM Driver question

Post by dougforpres » Wed Jan 15, 2020 7:13 am

Ahh, that makes sense.
For what it's worth, I've found that when the driver is set to return an RGB48 image, it needs around 225MB in order to convert a 6000x4000 raw file into 6000x4000x3 (x2 for 16-bit values).
(25MB for the original sony ARW file + 50MB for the uncompressed RAW image + 150MB for the RGB image).
I've updated the driver to call "GC.Collect()" before taking each picture and I'm no longer getting issues with memory starvation.

Thanks for your assistance,
Doug

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests