I notice that if I open an image taken in another application (MaxIm DL), right click on the image, and ask for a plate solve, that the plate Scale is 0.000 even though the FITS header contains the FOCALLEN, XPIXSZ, YPIXSZ, NAXIS1, and NAXIS2 which is all the information needed to calculate the image scale. See Image Scale and Field of View Calculator for example. Can SGP not use this information to calculate the image scale?
If I open the M42 image SGP uses for simulations, right click on the image, and ask for a plate solve, the Scale is populated with a nonzero value. I note also that the FITS header for the M42 image contains a field PIXSCALE. Is this what is being used to populate the Scale field in the Plate Solve window?
The Control Panel Camera tab has a field for Scale. Is this what is being used to populate the SGP FITS header field PIXSCALE and thence the Plate Solve field Scale?
If so, then do I have to go into the FITS Header and manually edit it to insert a PIXSCALE value? The SGP documentation says I can use images from anywhere. It did not notice that it said I have to manually edit them.
Also, I notice that in SGP XPIXSZ AND YPIXSZ are type Int. Pixel sizes in sensors are not going to always be integers.
The formal professional standard for things such as image position and pixel size is the World Coordinate System WCS. This defines the plate scale as CDELTi where i is the axis number.
But it’s only been out for a short time, the paper defining it was only published in 2002. Before that there was no standard way to define plate scale so applications tended to define their own. SGP and Maxim have chosen different ones. Trying to handle everything that multiple applications can throw at you is probably impractical.
Thank you for the interesting background information, but it does not answer my question.
My question is why cannot SGP compute plate scale when it is provided with all the information to do so, viz. FOCALLEN, XPIXSZ, YPIXSZ, NAXIS1, and NAXIS2? Is that not a reasonable thing to expect?
My only point in mentioning MaxIm DL is that I, and doubtless others, have images that have been taken using MaxIm. Is it unreasonable to ask that SGP can use these images without having to manually edit FITS headers or manually enter the plate scale in SGP?
I think it does, it just isn’t the answer you wanted WCS is the only standard for things such as position and plate scale.
Any application can put what keywords it likes into a FITS file. The FOCALLEN, XPIXSZ and YPIXSZ are in no standard. AFAIK they are at best Maxim proprierty. Trying to support this sort of thing is a developer’s nightmare. I don’t think it is a reasonable thing to expect.
I’ve tried to answer a number of your questions and been blown away just about every time so I don’t think I will try answering any more.
I have done a little more research and actually, all of the FITS keywords I referenced are already in SGP.
If I use simulators and “take an image”, the FITS header of the sample image file of M42 included with the SGP download contains NAXIS1, and NAXIS2. These are specified in the SGP user manual, pg. 101.
The FITS header of the image created using the simulators also contains XPIXSZ and YPIXSZ although these are not specified in the user manual. However, I did find a forum thread from February 2016 which confirms that these fields are in the FITS header as well. So, they have been in SGP for a while. (I do note a concern however which is that these fields as they appear in the FITS header of the sample file are type Int. But, maybe the type is determined by the value and could be float if the value contained a decimal? Sensor pixels are certainly not always sized in an integral number of microns.)
Page 102 of the user manual states that FOCALLEN will be included if a telescope is attached (and the sequence is using it).
Thus, it appears that these fields are not MaxIm proprietary but regardless, they are fields which SGP already recognizes, supports, and uses. So, leave MaxIm DL out of the discussion. It is not really relevant.
Cannot SGP use the fields it already supports to compute the plate scale? Is this a new feature request? It would seem to be a modest one if so, and it would be very helpful, I think.