asi294mm fits header bug affects ASTAP plate solving

Post Reply
scpanish
Posts: 13
Joined: Mon Feb 17, 2020 6:11 pm
Location: Milton, New Hampshire, USA

asi294mm fits header bug affects ASTAP plate solving

#1

Post by scpanish »

Hi Robin,
I believe I've found a bug in the fits header SharpCap generates for the 294mm pro. I loaded the latest asi driver and sharpcap for testing. This may be a ZWO driver bug or a SharpCap bug.

Plate solving from SC was mostly failing. So I looked at the header and tried the ASTAP app directly on capture subs. I am using an RC with FL=2026mm and an AstroPhysics mount with the ASCOM driver. The 294mm is using the "standard" 4144x2822 resolution binned 2X2. The resolution spec is 4.63 microns square per pixel.

In the fits header, naxis1=2072, naxis2=1411, so these are including the binning. I don't know if that is correct. ypixsiz=4.63, the comment field says /microns, includes binning. same for xpixsz. That does not include the binning, which would double the value to 9.26microns.

ASTAP mostly fails, but occasionally works and gives the following warning: "Inexact scale. Set FOV=.37 or scale=.9"/pix or FL=1014" So the image scale is apparently calculated off by a factor of .5. If I go to the Solve settings, the "Field of View (height) deg parameter was showing .18 deg, which is half the correct height. If I change it to .36, solving always works.

So, it seems that one of those header params is wrong, most likely the 2 pixsiz values, which don't include binning.

Not sure if this is SharpCap or ZWO, since I don't know how the figures are being used.

Here is a link to a sub on my google drive if you want to check this out. Too big to just attach:

https://drive.google.com/drive/folders/ ... share_link

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

Re: asi294mm fits header bug affects ASTAP plate solving

#2

Post by admin »

Hi Steve,

thanks for the report - I think I know where this is coming from... I have special code for the 294MM because the 'unlocked' 1x1 mode is handled by ZWO as binning, but that doesn't play nicely with SharpCap's sensor analysis and other related tools. Because of that, I remap the the choice between 1x1 (47 megapixel) mode and normal 11 megapixel mode as a 'read mode' option. However, that means where I am thinking about binning I need to remember that the binning values need to be tweaked to account for this. Looks like I forgot about this where it works out the pixel size, so I will check to see if I can correct it.

Hopefully this is somthing that will appear fairly obvious when I look at the code, as I don't actually have a 294MM to test with :) If not, I may get in touch to ask you to test some things for me.

cheers,

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

Re: asi294mm fits header bug affects ASTAP plate solving

#3

Post by admin »

Hi Steve,

Ok, this is odd. I tweaked my code to let it pretend that a ZWO camera I have is like the 294MM with the odd binning modes and tried out the various combinations and seemed to get the right pixel size each time.

Can you please take a FITS file in each of the four following settings and look to see what pixel size ends up in the FITS headers?

* 47 megapixel, Bin 1
* 11 megapixel, Bin 1
* 47 megapixel, Bin 3
* 11 megapixel, Bin 2

They should come out at 2.315, 4.63, 6.945 and 9.26 respectively. You could also try SharpCap 4.1 beta (which I am using), but I cannot see any significant changes in the code to set the pixel size between the two versions.

cheers,

Robin
scpanish
Posts: 13
Joined: Mon Feb 17, 2020 6:11 pm
Location: Milton, New Hampshire, USA

Re: asi294mm fits header bug affects ASTAP plate solving

#4

Post by scpanish »

Hi Robin,
Thanks for the (as usual) rapid response. I will test those modes but it may take a while...my parents have Covid and I am caring for them. And...we are having massive snow tonight!

best,
Steve
scpanish
Posts: 13
Joined: Mon Feb 17, 2020 6:11 pm
Location: Milton, New Hampshire, USA

Re: asi294mm fits header bug affects ASTAP plate solving

#5

Post by scpanish »

OK, I figured it out.
In the preferences, cameras, there is a box for the 294, ignore small pixel mode. If this box is checked, (and SharpCap restarted) the pixel sizes are 1/2 the correct values. Also the ROI window and the 11 vs 47 mode select go away. I tried the 4144x2822 in bin 1 and 2, gave 2.315 and 4.63 respectively.

If the "ignore" box is not checked, the 47 and 11 modes are selectable, and all the binnings I tried give correct pixel sizes.

This is with the new 4.0 release. I did not try the 4.1 beta.

You could just eliminate that box in the preferences and hide the ROI window when it isn't appropriate.

If you want to see the fits files, let me know and I'll put then on the google drive. Also if you need testing on a 294MM i'll do it.

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

Re: asi294mm fits header bug affects ASTAP plate solving

#6

Post by admin »

Hi Steve,

ah, that makes some sense - I didn't try using that checkbox. I will see if I can work out a fix. I can't recall quite the reason, but that feature of being able to ignore the 1x1 mode was important to someone...

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: asi294mm fits header bug affects ASTAP plate solving

#7

Post by Hibou »

Hi Robin.
I think you introduced the checkbox to ignore 47 MP mode in response to my request for custom resolution areas (regions of interest) in 11 MP mode.
Cheers Alan
User avatar
admin
Site Admin
Posts: 13347
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: asi294mm fits header bug affects ASTAP plate solving

#8

Post by admin »

Hi Alan,

yes, that's right - it gives access to custom ROI. In theory the custom ROI could be done for both modes, but the code involved in dealing with the two mdes adds a lot of complexity, then custom ROI areas adds more... Too much risk of something unforseen breaking the whole lot :(

cheers,

Robin
Post Reply