incorrect values for CRVAL1 and CRVAL2

[admin]

Hi Michael,

point taken on the EQUINOX - that follows from the co-ordinates used for the mount positions in RA/DEC/OBJCTRA/etc, and there is no way to say 'these co-ordinates are J2000 and those are JNOW'. That at least is a simple bug that I can resolve. For the rest of it, it will be a bigger task so I will add the option first so that I can 'unbreak' stuff that the CRVAL headers have broken (things go back to the way they were if the option is off), then worry about a proper fix.

cheers,

Robin.

[MikeB838]

Hi Robin,

does that mean that if CRVAL1/2 are present the EQUINOX has to be set to 2000? Then the other values (RA/DEC etc) have to be in J2000 too?!
I think if this is all corresponding that we do not need a option to disable the CR stuff?

cheers,
Michael

[admin]

Hi Michael,

I think that they just need to all be the same and all match the EQUINOX keyword. I am just looking at how that will work, but I suspect that I can just take all the plate solving information and translate that from J2000 to JNOW (if the mount uses JNOW) so that all the data will match.

I don't think this will fix everything though - there are still the cases where the mount movement after plate solving but before saving has to be accounted for and may not be correct.

cheers,

Robin

[MikeB838]

Hi Robin,

to make a test I updated the Fits header of two of my examples:

1. target 995 (has no CR stuff), set RA/DEC/OBJCTRA/OBJCTDEC to the J2000 values of the real center and set the equinox to 2000.0

2. target 4838 (has CR stuff), set RA/DEC/OBJCTRA/OBJCTDEC/CRVAL1/CRVAL2 to the JNow values of the real center and set the equinox to 2025.645

I fed both to Astrometrica and the program shows in both cases the correct center of the image in J2000.

So, as you said, if all values are the same and match the EQUINOX keyword, everything will be fine.

With the special cases (eg. movement after plate solving) I have to deal with (eg. do a plate solve before each new target) I think.
Formerly I had to do sometimes a manual align in Astrometrica if I had not performed a plate solve directly before taking the image.
That was totally understandable to me. I was triggered by the very big offsets in the last versions of SC. But when everything matches, I think
all will be fine

Thanks a lot for your efforts and your very good work!!

cheers,
Michael

[admin]

Hi Mike,

glad that is starting to look promising - I have the code changed now so that it will convert all the CRVAL data to JNOW if the main co-ordinate info is in JNOW, so that should come out consistently in the next update.

cheers,

Robin

[MikeB838]

Hi Robin,

that looks great! Thanks!

cheers,
Michael

[MikeB838]

Hi Robin,

I noticed that the values of CROTA1/CROTA2 are 0° in the Fits header, even when the plate solve gives 180°.

I hope this is fixed too

cheers,
Michael

[admin]

Hi Michael,

I'll have to look into that - those values are generally ignored now, since the CDX_Y matrix includes the same information in a more easily usable way.

cheers,

Robin

[admin]

Hi,

I checked the way that the rotation is set, and it turns out to be complicated... If you want consistent values and to have good compatibility with other applications then you should set the option (in the saving settings) to save FITS files in 'Bottom-Up' format.

Historically (and still by default for compatibility reasons), SharpCap saves FITS files in top-down format (ie the first data in the file is the top of the image). This is wrong, but lots of other software gets it wrong too, since it is very non-standard for image formats. There is a FITS header that some software supports (and SharpCap outputs) to specify the non-standard ordering, but I would say that software that pays attention to this header is in the minority. Because of that, SharpCap flips the orientation of the rotation and the transform matrix when writing in the default top-down ordering - this gives better compatibility with the majority of software that ignores the ROWORDER header.

If I was starting FITS support from scratch then I would write the files in the correct 'bottom up' order and that would be that, but if I change the default now, it would break things for loads of SharpCap users who would have (for instance) their dark/flat frames saved in the old orientation and then get light frames saved in the new orientation that are not compatible

cheers,

Robin

[MikeB838]

Hi Robin,

thanks for looking into it.

The values of CROTA1/CROTA2 are always 180° off versus the values from plate solving. Does this depend on the format?

cheers,
Michael