Preserving astrometric calculation

[turtlecatvyne]

I'm assuming this will be a matter of copying metadata over... But with the recent 1.8.9-2 release the astrometric data isn't valid after a file is processed in Graxpert. Simple steps to reproduce:

1. Process a file in WBPP
2. Open master in Graxpert, process as usual, save the XISF
3. Open xisf in PixInsight, try to do something like SPCC.

You won't have a valid astrometric solution and you have to run through ImageSolver again.

[Steffenhir]

Hi, GraXpert should already copy all of the Metadata, so I guess this is a bug. Is the image you open in GraXpert also a xisf file?

And did this work with an older Pixinsight version?

[afettoxiulong]

In my "normal" pixinsight workflow I use to 1) remove gradient 2) platesolve integration with gradient removed 3) color calibrate (normally spcc) So it's "normal" to me not to look in graxpert output an astrometric solved file, isn't it?

[jst200]

Hi,

I was going to add my own post with this request and then found this thread, so have posted here instead. Hope that is OK?

I too assumed it was a header issue, so extracted the .xisf header from a post WBPP process file and the .xisf header from a post GraXpert AI process on the same file. I then used a web based text comparison site to check for differences.

It turns out there are quite a few differences. I think the most significant is that the GraExpert AI .xisf file removes the single quote bracketing characters from all text keywords. e.g.:

WBPP Output

TIMESYS = 'UTC' / Time scale: Universal Time, Coordinated LONG-OBS= -2.000000 / Geodetic longitude (deg) (compatibility) LAT-OBS = 53.000000 / Geodetic latitude (deg) (compatibility) OBJCTRA = '20 56 16.227' / Right ascension (hours) (compatibility) OBJCTDEC= '+31 25 15.70' / Declination (deg) (compatibility) WBPPCROP= '(3,41)x(5399,3627)' / WBPP Autocrop

GraXpert AI Output

TIMESYS = UTC / Time scale: Universal Time, Coordinated LONG-OBS= -2.000000 / Geodetic longitude (deg) (compatibility) LAT-OBS = 53.000000 / Geodetic latitude (deg) (compatibility) OBJCTRA = 20 56 16.227 / Right ascension (hours) (compatibility) OBJCTDEC= +31 25 15.70 / Declination (deg) (compatibility) WBPPCROP= (3,41)x(5399,3627) / WBPP Autocrop BG-EXTR = GraXpert /

I don't know if these bracket character omissions are relevant, but I notice that other applications seem to retain them.

I've attached the txt files of the full .xisf headers. Please note, both above snippets and in the files have had their their location keywords made less accurate (changed decimal numbers to 0).

Hope this helps?

Can I just add, I've not used GraXpert before, but I am finding that the AI version is producing outstanding results! Thanks very much for providing this tool to the community.

Cheers, Jim

masterLight_BIN-1_5440x3648_EXPOSURE-133.40s_FILTER-all_RGB_drizzle_1x_autocrop_GraXpert.txt masterLight_BIN-1_5440x3648_EXPOSURE-133.40s_FILTER-all_RGB_drizzle_1x_autocrop.txt

[Steffenhir]

Hi everyone, I recently noticed that WBPP in the newest version of Pixinsight does not write the astrometric data into the header file anymore. Could you please check if the astrometric data was written into these files before you take them to GraXpert? When I solve the image in Pixinsight with the ImageSolver script, then process it in GraXpert, and go back to Pixinsight, the astrometric data is preserved.

@jst200 Thank you for testing this! We can not copy the Fits header one to one because Pixinsight does not conform to the Fits standard when writing the Fits header, but the library we are using to copy and modify the Fits header forces this standard. I will check if there is a way to preserve the ' characters.

[turtlecatvyne]

I apologize for the lack of followup. Github didn't send me a notification that the issue had comments. Glad we at least know the situation better.

[jst200]

Hi Steffenhir,

I've just installed the latest release (v2.01) and see that you have fixed the missing single quotes marks. Thanks very much for that.

Unfortunately, as I think you might have suspected, it hasn't fixed the report by Pixinsight's Spectrophotometric Colour Calibration (SPCC) of missing astrometric data. I've checked the fits headers from before and after GraXpert and I can't see what is missing. Very strange!

The good news is that it is easy to run the PI ImageSolver script to put the astrometric back. Though it would be nice not to have to.

I'll keep looking to see if I can see why SPCC thinks it's missing.

Despite this "quirk", I must say that I am really impressed with the results of the AI option in GraXpert. It does a far better job than I have ever been able to achieve when using the standard PI processes!

Thanks so much, Jim.

[AstroDeepSky]

Hi all, I'm using command line mode to run GraXpert from PixInsight with a dedicated small javascript. I'm facing same problem reported here: metadata are lost in final result file (XISF). I had a look last night. I think fields are there but they are all empty (no values). I'll investigate more. I'll report other issues related to command line mode.

[Steffenhir]

Hi @jst200, did you check if Pixinsight's SPCC works with the image before processing in GraXpert?

[AstroDeepSky]

@Steffenhir problem comes from XISF module that do no support all XISF attributs.

Unsupported Property type TimePoint: {'id': 'Observation:Time:End', 'type': 'TimePoint', 'value': '2023-09-30T21:22:42.870Z'} Unsupported Property type TimePoint: {'id': 'Observation:Time:Start', 'type': 'TimePoint', 'value': '2023-09-30T21:12:42.870Z'} Unsupported Property type F64Vector: {'id': 'PCL:AstrometricSolution:CelestialPoleNativeCoordinates', 'type': 'F64Vector', 'length': '2', 'location': 'inline:base64'} Unsupported Property type F64Matrix: {'id': 'PCL:AstrometricSolution:LinearTransformationMatrix', 'type': 'F64Matrix', 'rows': '2', 'columns': '2', 'location': 'inline:base64'} Unsupported Property type F64Vector: {'id': 'PCL:AstrometricSolution:ReferenceCelestialCoordinates', 'type': 'F64Vector', 'length': '2', 'location': 'inline:base64'} Unsupported Property type F64Vector: {'id': 'PCL:AstrometricSolution:ReferenceImageCoordinates', 'type': 'F64Vector', 'length': '2', 'location': 'inline:base64'} Unsupported Property type F64Vector: {'id': 'PCL:AstrometricSolution:ReferenceNativeCoordinates', 'type': 'F64Vector', 'length': '2', 'location': 'inline:base64'} Unsupported Property type UI8Vector: {'id': 'PCL:AstrometricSolution:SplineWorldTransformation', 'type': 'UI8Vector', 'length': '97499', 'location': 'attachment:107102208:97499'}

TimePoint is silently ignored, I modified code to make it visible.

[AstroDeepSky]

Hi everyone,

The root cause is in XISF module use by GraXpert. Below description in official XISF GitHub: https://github.com/sergio-dr/xisf/commit/b9a9084e7bf0d5a73b763a18852e8bde9001f818

"PixInsight now uses extensively F64Vector and F64Matrix types to carry astrometric solutions natively. Unfortunately, they are not supported by now so our implementation simply skips them. Please be aware that PixInsight removes the astrometric solution from the embedded FITS header of the XISF file after migrating it to these XISF properties."

[jst200]

Hi Joel95,

It's interesting the .xisf header key word contents look identical before and after GraXpert. Perhaps it is the word "look" that is the problem? Could there be some unprintable characters in them that we don't see? Or is that just fanciful thinking on my part.

Or is it because the PI astrometric solution isn't stored in the .xisf header at all, but somewhere else in the file?

Anyway, with the new PI integration option, it works seamlessly. So all is good, unless you want to use the non AI methods in GraXpert.

Cheers, Jim