OBJCTRA and OBJCTDEC

Got an idea for something that SharpCap should do? Share it here.
Forum rules
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

OBJCTRA and OBJCTDEC

#1

Post by oopfan »

Robin,

Data analysis of variable stars requires the use of specialized software that operates on my calibrated images. There are several required key/value pairs in the FITS file. Two of these are OBJCTRA and OBJCTDEC which are the coordinates of the center of the image:

OBJCTRA = hh:mm:ss
OBJCTDEC= [-]dd:mm:ss

For example:

OBJCTRA = 12:22:34
OBJCTDEC= 26:37:17

are the coordinates of a portion of the standard star field called Melotte 111 in Coma Berenices.

Currently, after the images are acquired by SharpCap, I run a program called F4W2HDU by Astroshed to modify the FITS header to insert these key/value pairs. It would be splendid if I could eliminate that step and have SharpCap do it for me.

I am a heavy user of plate solving in SharpCap, so it seems like it should be a matter of writing the most recent coordinates obtained from the plate solver to the FITS file.

I know that I am in the minority of users who need this feature but it would be a real labor saver.

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

Re: OBJCTRA and OBJCTDEC

#2

Post by admin »

Hi Brian,

do you use a GOTO mount with ASCOM driver? That would make the most sense for putting RA/Dec etc into the headers as it would be guaranteed to be an up-to-date position. I worry about using the latest plate solve location with a non-goto mount as there is no way for SharpCap to know if you have moved the mount since the last plate solve. I'd argue that in that case no data is better than potentially incorrect data (from a general user point of view).

cheers,

Robin
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: OBJCTRA and OBJCTDEC

#3

Post by oopfan »

Robin,

Sorry, I am old-school. SharpCap would need to trust me :-)

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

Re: OBJCTRA and OBJCTDEC

#4

Post by admin »

Hmmm,

Ok, that would need an option then as I wouldn't want to turn that on by default. Something like a:

'Use latest plate solve location for FITS metadata if no ASCOM mount connected'

checkbox I think.

cheers,

Robin
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: OBJCTRA and OBJCTDEC

#5

Post by oopfan »

Robin,

Sorry, I do use the Telescope Simulator for .NET in order to synchronize C2A and SharpCap. Perhaps SharpCap could read the current coordinates from it? (I thought it was important to have an actual Go-To mount rather than an imitation but I see my error now!)

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

Re: OBJCTRA and OBJCTDEC

#6

Post by admin »

Hi,

so if you are using the Telescope simulator and are using the 'GPS' button to do the plate solving then that will set the simulator to the solved location. If I added a feature to SharpCap to get the co-ords from ASCOM then I think it would all work for you (and for anyone else using an ASCOM mount).

cheers,

Robin
SteveInNZ
Posts: 83
Joined: Tue Feb 14, 2017 6:56 pm

Re: OBJCTRA and OBJCTDEC

#7

Post by SteveInNZ »

This seems a bit backward to me.
The plate solve is of the image. The result is relevant to the image and is what should be written in the header.
There's no reason that the mount shouldn't be slewing to the next target.
Doing it via ASCOM is making a lot of assumptions that would result in the incorrect information going into the header. Is tracking turned off ? Is the mount just going to sync or is it going to slew to the target location ? Is there anything else moving the mount outside of SharpCap ?

Steve.
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: OBJCTRA and OBJCTDEC

#8

Post by oopfan »

Hi Steve,

I agree but what I think Robin wants to mitigate is the possibility that people slew their scope without following it up with a new plate solve. Me? I'm anal retentive so I have no doubt that I will plate solve.

EDIT:

I reread your post and now I think I understand where the confusion is. Plate solving does not happen in real-time with each new light frame captured -- it is too time consuming. On my laptop it takes about 10 seconds. So what I do is tell SC in the settings to sync my ASCOM telescope simulator with the results of the last plate solve which then tells my C2A planetarium software to show me exactly where it is pointing. Centering the scope on a particular target can take several iterations. Once I am happy I take a final plate solve, and then begin capturing lights. It would be ideal if plate solving could happen in a millisecond or two but alas that is not possible.

Another possible solution would be to write an offline utility that plate solved each image file and then updated the FITS header. I could live with that. Actually AIRMASS could be handled that way too.

Brian
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: OBJCTRA and OBJCTDEC

#9

Post by oopfan »

Robin,

What do you think about the idea of an offline utility? I can write that.

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

Re: OBJCTRA and OBJCTDEC

#10

Post by admin »

Hi,

it certainly should be possible to write a utility to plate solve and then tinker with the headers of an existing fits - I use CSharpFits (https://github.com/rwg0/csharpfits) for fits reading/writing in SharpCap. It's not fully featured, but the bits I use work.

I'm not sure I understand Steve's concern about taking the RA/Dec from a connected ASCOM mount. In most cases the ASCOM mount would be a real mount and would therefore be keeping track of the changes in RA/Dec if you pause tracking, move around, etc. Thus taking the RA/Dec from that and putting it into the FITS file should be OK in 99.999% of cases. If the user has done a plate solve then the values should be pretty accurate too. The use of the simulator mount is a complete edge case - most people wouldn't try it or expect it to work correctly if they did. But for Brian's use case it happens to work out correctly.

cheers,

Robin
Post Reply