869 replies to this topic

[archer1960]

If you are willing to "break" the driver for other cameras, it should be pretty easy to hard code a different value.

 

With a few quick searches through the source, I think it it might have more to do with the fact that the 5D Mk II is a full frame sensor, rather than an APS-C that the driver was originally developed using.  Are you getting a pixel size of somethin like 3.95um?  if so, that's likely the cause.

 

I keep thinking that someday when I get some time, I'll try a clean implementation of the driver, but the need for me personally is much less since I've moved on to dedicated astro camera.

Since I'm retiring soon, and have both full frame (6D and 1DX Mk II) and APS-C (T3i) cameras, I might be able to help with this once I get my head around the code...

[DanMiller]

Since I'm retiring soon, and have both full frame (6D and 1DX Mk II) and APS-C (T3i) cameras, I might be able to help with this once I get my head around the code...

I have very little experience with C#. But I was able to look at the code and not be blown away too bad.  I did download the code and pulled it into Visual Studio and tried to compile it.  The first things I found is that there are a lot of older dot net frame works in it that visual studio didn't like.  I downloaded the latest sdk from canon and replaced some of the dlls and libraries that were obvious.  This resolved the canon sdk not being the correct version of dot net according to visual studio.

 

My plan is to try to resolve those issues first, then to have a fully compiled version of the ascom driver.  Then, because I could not spot where it was setting the focal length and pixil size for the mark II.  I was going to just going to plug my camera in and walk through the code in a debug session to try and get an idea of the flow and values being returned and decide what to do from there.

 

tjay noted that the pixil size and focal length was not being returned from the current version of the driver that is compiled.  So, by walking the code, hopefully I can see if that has changed in the current sdk.  From what I can tell, the code hasn't been changed in 2 years.  At least that is what it looks like on github.

 

If the sdk still doesn't return the pixil size and focal length.  At least at this point I should know where it is building that information to return to NINA.  And at that point, a better resolution can be made for correcting the manual coding for that.  I really am nt inclined to use a database for storing this information for all the cameras.  And my thought process is that the database would have to be constantly maintained for new cameras by anyone that updated the code.  I am leaning more towards an xml file, or some type of formatted file that can be updated by whoever has a camera that is not there.  The bad thing about doing it that way is the camera information in the files would not stay current for distribution.  A sql lite db would be the easiest to use if we went the route of a database.  Very light weight, no overhead or very little, easy to update with SQLiteStudio.  And it could be downloaded with the driver or separately for any changes to the information stored within.

 

I am still am testing new equipment which I still need a couple things to complete before I feel like I am back to imaging full time again.  I need a flattener.  And I just have been having lousy nights lately because my equipment is old.  But I would really like to get my Mark II up and running even if it isn't modified for specific targets. And I don't want to use anything but NINA, so the driver can't be ignored by me.

 

Dan

[archer1960]

If the SDK can't pull the data from the camera, then I like the idea of an updateable file with the data for all the cameras it supports as a backup plan. As you say, the user can update with their own data for a new model. It could even have a simple GUI to manage the update, which might minimize the issues of a user mis-typing something and breaking the file load completely.

[tjay]

Yeah, when I said "database" I was envisioning a config file in some structured format (CSV, maybe XML, JSON, etc.) that would be updateable.  I know that the Canon SDK needed to be updated when newer models came along, so it might not be as useful as it would seem.

 

I spent a few minutes thinking about it.  It might actually be easier to start with a new implementation based on the latest ASCOM version, and completely separate the camera specific pieces from the ASCOM interface.  The reading of the image could be still be left to libraw, which is fantastic, but not trivial to use from .NET.  Switching to Sdcb.Libraw (basically libraw for .NET) might help, but I don't know if it adds support for new cameras as quickly as libraw.   I think the separation would make the code cleaner, and make it easier to add support for new cameras.

[ntbarone]

Is there an Ascom feature that possibly allows for DSLR camers to photograph and work as a guide cam talking to the mount simultaneously? I know this is probably farfetched, but would be Awesome if possible especially for those (myself included) just starting out with guiding.

 

Thanks,

Nino

[archer1960]

Is there an Ascom feature that possibly allows for DSLR camers to photograph and work as a guide cam talking to the mount simultaneously? I know this is probably farfetched, but would be Awesome if possible especially for those (myself included) just starting out with guiding.

 

Thanks,

Nino

I sincerely doubt it. You would need to be able to pull images from the sensor for guiding, while leaving the data in the pixel wells for the longer exposure. It might be possible to build a camera to be able to do this, but it would almost certainly need a custom chip. No consumer DSLR will be able to do this.

[TTMartin]

Is there an Ascom feature that possibly allows for DSLR camers to photograph and work as a guide cam talking to the mount simultaneously? I know this is probably farfetched, but would be Awesome if possible especially for those (myself included) just starting out with guiding.

Thanks,
Nino

You can use the virtual guider in NINA, and plate solve after each capture. Then recenter if the drift is too far. This doesn't allow for longer exposures, but, it does give you a lot of data centered on your target. And any drift you have is simply like dithering.

[archer1960]

You can use the virtual guider in NINA, and plate solve after each capture. Then recenter if the drift is too far. This doesn't allow for longer exposures, but, it does give you a lot of data centered on your target. And any drift you have is simply like dithering.

It's not going to be as good as real dithering, because the drift will usually be in the same direction from image to image, but it would certainly help you stay on target for hours at a time.

[m.takahasi]

I think the easiest way would be to use a live stack like SharpCap
SharpCap stacks while Aligning the image when stacking, so Guiding is not required. i think you can send the Dither signal directly to the mount.

[Jaime1661]

Once again need your help with the Ascom driver for the DSLR. Recently downloaded both the test and the installer giving a fail response. I have copied the setup dialog below for the error reference. Really appreciate the help.

 

Thanks.

---------------------------
Driver Setup Dialog Error
---------------------------
The SetupDialog method of driver "ASCOM.DSLR.Camera" threw an exception when called.

 

This means that the setup dialogue would not start properly.

 

Please screen print or use CTRL+C to copy all of this message and report it to the driver author with a request for assistance.

 

InvalidOperationException - Sequence contains no elements
---------------------------
OK  
---------------------------

[bignerdguy]

BTW don't know if anyone else covered this as there are so many replies its hard to go through them all but for those using SharpCap that find the shutter opens and begins taking photos the moment you connect the camera, there is a live view option in SharpCap that activates automatically on connection.  In the top tool bar if you click this option, the camera will stop taking photos.  For some reason SharpCap has this option enabled by default.  Normally with a Canon Camera, Live view opens a video capture window but with SharpCap this only takes photos every now and then, it doesn't enable video capture.

[sky gazer]

After modifying the source code, I successfully tested this driver with my Pentax K5 camera.

 

As I initially suspected, the issue stemmed from the ReadRaw() function in ‘ImageDataProcessor.cs’. The original implementation incorrectly handled cameras with non-RGGB Bayer filter arrays, potentially rendering the driver unusable for such devices. After revising the code, recompiling, and repackaging the driver, I validated its functionality in N.I.N.A. with my K5 body. The driver now correctly captures, debayers, and processes images with accurate colors.

• Key Observations:

1. Image Dimensions: FITS files generated via NINA are 2 pixels smaller in both width and height compared to raw DNG files acquired via USB tethering.
2. Bayer Pattern: The FITS output automatically standardizes to RGGB format, regardless of the camera’s native Bayer array.
3. DNG Artifact: FITS files and Raw DNG files obtained via USB tethering exhibit a ~59-pixel data-free band at the bottom edge (cause undetermined).

• Recommendations:

1.  This driver is suitable for preview purposes (e.g., focus testing, framing, or plate solver) but not recommended for scientific imaging (lights, flats, darks, or biases).

• Resources:

1. A compiled binary is available for download.https://drive.google...?usp=drive_link
2. Modified 'ImageDataProcessor.cs' source code can be provided upon request for custom builds.

[norcalryder]

Does this driver work with a K1?

[FearL0rd]

Does this driver work with a K1?

I no longer have DSLR cameras to test, but it should work if it doesn't. It needs to be recompiled with the latest API from the vendor

Sent from my SM-S918U1 using Tapatalk

[norcalryder]

I'll give it t a try

[norcalryder]

I no longer have DSLR cameras to test, but it should work if it doesn't. It needs to be recompiled with the latest API from the vendor

Sent from my SM-S918U1 using Tapatalk

I installed the driver and set it to Pentax.  When I try to connect it spins for a while then NINA becomes unresponsive.

[FearL0rd]

I installed the driver and set it to Pentax. When I try to connect it spins for a while then NINA becomes unresponsive.

Try to download the last Pentax files and replace it on the driver.

Sent from my SM-S918U1 using Tapatalk

[AngeloP]

Just a quick question. After reading the DSLR Driver installation guide by Fearl0rd on Github at the beginning of this Topic, and after several failed attempts, I figured out the only way I had to make my EOS 60D work with SharpCap was to replace my ASCOM platform v7 with the "Tested" version v6.5 I downloaded from FearL0rd Github. Now it seems to work fine.

 

However I am wondering whether I am losing some functionality or I will run into some problems down the road by using an older ASCOM platform version... BTW I drive an AZ-EQ6 pro.

Any advice?

Thanks in advance!

Angelo

[FearL0rd]

Just a quick question. After reading the DSLR Driver installation guide by Fearl0rd on Github at the beginning of this Topic, and after several failed attempts, I figured out the only way I had to make my EOS 60D work with SharpCap was to replace my ASCOM platform v7 with the "Tested" version v6.5 I downloaded from FearL0rd Github. Now it seems to work fine.

However I am wondering whether I am losing some functionality or I will run into some problems down the road by using an older ASCOM platform version... BTW I drive an AZ-EQ6 pro.
Any advice?
I really appreciate any help you can provide.
Angelo

The driver was compiled with 6.5. You should not lose a lot of meaningful functionality

Sent from my SM-S918U1 using Tapatalk

[AngeloP]

The driver was compiled with 6.5. You should not lose a lot of meaningful functionality

Sent from my SM-S918U1 using Tapatalk

Thanks a lot FearL0rd, that's wat I was hoping! And great job!