APT produced FITS files usually fail Image Solver

L

lmclouth

Active member
Hello,

I believe I've finally figured out why FITS files produced with APT usually fail "Image Solver" in PixInsight.

A little background -- I have an iOptron CEM-120 mount and as far as I can tell it needs epoch JNOW, so I have that checked in APT (and programs like Stellarium.)
The coordinates that are stored in the FITS header are for epoch JNOW. But when using WBPP (or Image Solver directly) in PixInsight, it appears it is expecting epoch J2000 coordinates. So it usually fails the initial attempt. But if I do a search in Image Solver and it gets the data for the object (from VizieR) the coordinates are now J2000 and the image solves correctly.

So since I cannot change the epoch in APT to be J2000 (because of the mount's needs), is there some additional FITS keyword (like EQUINOX) that needs to be present in the FITS header so Image Solver knows the coordinates are JNOW?
Or is there a setting in Image Solver (also working in WBPP) that will tell it that the coordinates are JNOW?

I've asked this question on the APT forum too in case it's something they can/need to correct.

Thanks for any help,

Lamar
 
Last edited:
lmclouth said:
Hello,

I believe I've finally figured out why FITS files produced with APT usually fail "Image Solver" in PixInsight.

A little background -- I have an iOptron CEM-120 mount and as far as I can tell it needs epoch JNOW, so I have that checked in APT (and programs like Stellarium.)
The coordinates that are stored in the FITS header are for epoch JNOW. But when using WBPP (or Image Solver directly) in PixInsight, it appears it is expecting epoch J2000 coordinates. So it usually fails the initial attempt. But if I do a search in Image Solver and it gets the data for the object (from VizieR) the coordinates are now J2000 and the image solves correctly.

So since I cannot change the epoch in APT to be J2000 (because of the mount's needs), is there some additional FITS keyword (like EQUINOX) that needs to be present in the FITS header so Image Solver knows the coordinates are JNOW?
Or is there a setting in Image Solver (also working in WBPP) that will tell it that the coordinates are JNOW?

I've asked this question on the APT forum too in case it's something they can/need to correct.

Thanks for any help,

Lamar
Click to expand...
This seems unlikely to be an issue. ImageSolver only needs to know the very rough center coordinates of the plate, maybe within 25% or so of the actual center. The difference between JNOW and J2000 is arcseconds. It shouldn't make any difference at all. Can you post an image that doesn't solve for you?
 
lmclouth said:
it needs epoch JNOW, so I have that checked in APT
Click to expand...
Exactly where do you set this in APT?
The mount is operating in RA and DEC, which are implicitly in JNOW for the moment of measurement. When you are solving an image with reference to catalogue star values, part of the task is always adjusting the catalogue postions from their catalogue epoch [technically, equinox] (which will usually be J2000 these days) to the time of the measurement (i.e. the "JNOW" of the measurement) (which is why ImageSolver asks for the date / time of the measurement); this adjustment uses a model defined in the underlying reference system (these days ICRS). In principal the solver could use several catalogues, with several different epochs. Note that the epoch of the catalogue has nothing to do with the epoch of the measurement (ImageSolver is expected to adjust for the difference).
Mount control is always in current RA DEC (which is why I am puzzled about setting any epoch in APT).
 
cloudbait said:
This seems unlikely to be an issue. ImageSolver only needs to know the very rough center coordinates of the plate, maybe within 25% or so of the actual center. The difference between JNOW and J2000 is arcseconds. It shouldn't make any difference at all. Can you post an image that doesn't solve for you?
Click to expand...

With a focal high enough and a small sensor it can make a difference (enough for the coordinates not to be in the frame) but ,even though coordinates are entered in JNOW I doubt very much that they are stored in this format in the fit header by APT. It wouldn't make sense.
 
cloudbait said:
This seems unlikely to be an issue. ImageSolver only needs to know the very rough center coordinates of the plate, maybe within 25% or so of the actual center. The difference between JNOW and J2000 is arcseconds. It shouldn't make any difference at all. Can you post an image that doesn't solve for you?
Click to expand...
I'll get an image soon. But here are the coordinates for NGC 5885 for Image Solver from the FITS file itself which fails.
NGC5885_from_FITS.jpg


and here are the coordinates when I search for NGC 5885 from VizieR that is successful.
NGC5885_from_search.jpg


There is a pretty large difference in the coordinates and that is the only thing that was changed between the two attempts.
It is most frustrating when I start WBPP and walk away knowing it will take an hour or more to complete. But I come back to it and it has stopped at Image Solver because it has failed.

Lamar
 
Besides not being a practical problem for seeding an astrometric solution because the differences are relatively small (except for very small fields as noted above), "JNOW" is an invention that does not exist in the FITS standard. Our code base simply ignores it.

To specify that the (nonstandard) RA and DEC keywords provide geocentric apparent coordinates in a FITS file, the (standard) RADESYS keyword should have the value 'GAPPT' instead of 'ICRS'. See Table 24 in the current FITS Standard 4.0 document. This is what our astrometry engine expects to find in FITS headers.
 
lmclouth said:
I'll get an image soon. But here are the coordinates for NGC 5885 for Image Solver from the FITS file itself which fails.
View attachment 22870

and here are the coordinates when I search for NGC 5885 from VizieR that is successful.
View attachment 22871

There is a pretty large difference in the coordinates and that is the only thing that was changed between the two attempts.
It is most frustrating when I start WBPP and walk away knowing it will take an hour or more to complete. But I come back to it and it has stopped at Image Solver because it has failed.

Lamar
Click to expand...
Well, 5 arcmin difference could be enough to be an issue if you have a small FOV. You can always change the plate coordinates manually before running WBPP so it doesn't hang in the middle.
 
Correction: the difference is significant in your case because you are working with a relatively long focal length. Here are positions calculated with our Ephemerides script:

Code: 
                      -------Astrometric--------
     Date - TT            R.A.          Dec.
--------------------  ------------  ------------
                        h  m  s        °  ′  ″
2024 APR 17 00:00:00  15 15 04.154  -10 05 09.68

                      ---------Apparent---------
     Date - TT            R.A.          Dec.
--------------------  ------------  ------------
                        h  m  s        °  ′  ″
2024 APR 17 00:00:00  15 16 24.039  -10 10 41.03

So yes, working at 0.3 arcseconds per pixel this can be a serious problem because the initial coordinates are outside the image. Calculating ICRS coordinates from apparent coordinates is doable as an approximation but quite complex (I have already implemented an approximate solution with the help of Mathematica to solve the inverse relativistic annual aberration equations, but this is something not advisable for an image acquisition application).

The solution should be implemented in APT and is quite easy IMO. Send apparent coordinates to the mount but store the astrometric coordinates to write them in image metadata.
 
Can anyone tell me a mount that does not work in "JNOW" epoch (i.e. that does not point to the aligned RA, DEC coordinates when directed to a specific RA, DEC)? Of course, for most circumstances the difference will be small, and a user may honestly not know which his mount is doing. But I think the idea the any ordinary amateur mount embeds an ICRS epoch propagator sound very unlikely.
The opposite (which I think is what @Juan Conejero is referring to), of converting J2000 positions (from some reference source) to current RA, DEC in the mount control application does make sense.
... however, I would expect all positions reported in the header to be measured RA DEC positions (i.e. "JNOW" for the time of capture).
 
Juan Conejero said:
The solution should be implemented in APT and is quite easy IMO. Send apparent coordinates to the mount but store the astrometric coordinates to write them in image metadata.
Click to expand...
I would expect all data associated to an image (i.e. in the image header) to be referenced to the capture time of the image. The idea of capture software applying some sort of arbitrary epoch propagation sounds like a recipe for disaster to me.
... particularly when proper catalogue propagation includes proper motion propagation for each star, which is obviously not possible for the capture app.
 
fredvanner said:
however, I would expect all positions reported in the header to be measured RA DEC positions (i.e. "JNOW" for the time of capture).
Click to expand...

This is strange to me: "JNOW for the time of capture" is not JNOW at all. If we have epochs coordinates isn't it to use them precisely when we store coordinates?
 
lmclouth said:
So since I cannot change the epoch in APT to be J2000 (because of the mount's needs),
Click to expand...

Is the J2000 option grayed out for you in APT? Per your post #5 you have success with the VizieR coordinates, which should be J2000.
 
nico1038 said:
This is strange to me: "JNOW for the time of capture" is not JNOW at all. If we have epochs coordinates isn't it to use them precisely when we store coordinates?
Click to expand...
There is no such thing as "JNOW", which is why I use scare quotes. I think the situation should be dead simple. Images have coordinates defined in actual RA, DEC at the time of capture. There is no reason for them to be expressed in any other epoch - to do so can only cause confusion.
 
fredvanner said:
There is no such thing as "JNOW", which is why I use scare quotes. I think the situation should be dead simple. Images have coordinates defined in actual RA, DEC at the time of capture. There is no reason for them to be expressed in any other epoch - to do so can only cause confusion.
Click to expand...

I disagree: coordinates at the time of capture will need to be converted anyway just as J2000 coordinates. Then it seems more sensible to have all coordinates in the same format. This way for instance you can compare them. I believe it works like that in most aquisition software.
 
nico1038 said:
I believe it works like that in most aquisition software.
Click to expand...
That's new to me. And it seems wrong. You can adjust the coordinates of the image centre to a hypothetical epoch, but that does not correctly adjust the positions of the stars (since it does not - and cannot - take proper motion into account; nor does it accommodate RA DEC rotation); so the result is not a "J2000 image", it is a "J2024 bodged to sort-of J2000" image. IMHO the only consistent option is to keep the image data as a time and date specific sample. It is then straightforward to handle this data in any postprocessing, at any future date, referenced to any epoch / equinox.
 
nico1038 said:
Then it seems more sensible to have all coordinates in the same format.
Click to expand...
I sort-of agree; when we are processing images captured at a particular date and time we should have all the data in the same frame. Since we can't "back-propagate" the proper motion of stars in the image (because we don't know what the proper motion is), the only option is to forward-propagate any catalogue data to the image time, which you will have to do for matching anyway. So yes, lets have all the data in the coordinate frame of the captured image.
 
Last edited:
What is really important here is the correctness of metadata. If the approximate coordinates of the center of the image (RA/DEC FITS keywords or Observation:Center:RA/Observation:Center:Dec XISF properties) are astrometric or ICRS coordinates, the value should be 'ICRS'. If the coordinates are apparent or topocentric apparent "of the date" coordinates, the metadata value should be RADESYS='GAPPT' (FITS) or Observation:CelestialReferenceSystem='Apparent' (XISF). This way, there are no ambiguities, and everybody knows what to do and expect.

I'll review how we manage these essential metadata items in our code base, and more specifically how we apply the necessary coordinate transformations in ImageSolver to acquire the approximate center position.
 
Juan Conejero said:
What is really important here is the correctness of metadata. If the approximate coordinates of the center of the image (RA/DEC FITS keywords or Observation:Center:RA/Observation:Center:Dec XISF properties) are astrometric or ICRS coordinates, the value should be 'ICRS'. If the coordinates are apparent or topocentric apparent "of the date" coordinates, the metadata value should be RADESYS='GAPPT' (FITS) or Observation:CelestialReferenceSystem='Apparent' (XISF). This way, there are no ambiguities, and everybody knows what to do and expect.

I'll review how we manage these essential metadata items in our code base, and more specifically how we apply the necessary coordinate transformations in ImageSolver to acquire the approximate center position.
Click to expand...
Any update on this?

If I understand correctly, APT should set in the FITS header RADESYS=ICRS if using astrometric or ICRS coordinates (i.e. J2000). Or set RADESYS=GAPPT if the coordinates are JNOW.

Is this correct?
 
lmclouth said:
Any update on this?

If I understand correctly, APT should set in the FITS header RADESYS=ICRS if using astrometric or ICRS coordinates (i.e. J2000). Or set RADESYS=GAPPT if the coordinates are JNOW.

Is this correct?
Click to expand...

Yes, that's correct. However, the only really good option would be to store astrometric (ICRS) coordinates in image metadata in all cases. Reasons:

1. APT already knows the ICRS coordinates when it transforms them to apparent coordinates before sending them to the mount. So we are not asking for something requiring any additional work.

2. If the metadata center coordinates are apparent, considerable work is required to perform the (approximate, never accurate) inverse transformation to ICRS coordinates, which are required to perform the necessary database search operations to compute an astrometric solution.

3. With ICRS image center coordinates we have universally valid and consistent metadata to compare and classify images without any additional work.
 
You must log in or register to reply here.
Back
Top