[Solved] Request - Plate Solving function on final Image Stacks

Hi Simon @stastro,

Thank you very much for requesting this.

Yes, plate solving must be implemented soon. We will also try to put the reference frame's plate solve information directly into the integration file before we have implemented the plate solve.

I will also address the FILTER tag issue. Will try to do this for 2.0.0-beta32. I have added your post to my current issue regarding adding plate solve data to the integration header.

Mabula

Hi !

Yes, the integrated file doesn't keep the information datas of the light frames (astrometry of the reference light for example).

It would be really great if that were the case.

Also, astrometry in APP would be very nice, especially for mosaics : star matching and position based on a real astrometry, and no more issue with distortion 😉

Posted by: @mabula-admin

↑

Hi Simon @stastro,

Thank you very much for requesting this.

Yes, plate solving must be implemented soon. We will also try to put the reference frame's plate solve information directly into the integration file before we have implemented the plate solve.

I will also address the FILTER tag issue. Will try to do this for 2.0.0-beta32. I have added your post to my current issue regarding adding plate solve data to the integration header.

Mabula

 

 

FILTER and FRAMETYPE are important, otherwise they are not detected correctly by other apps

Hi @dav78 and @stastro,

Will try to implement it soon, thanks for the information and your feedback.

Mabula

Hi Simon @stastro,

The FITS FILTER tag missing will be fixed in 2.0.0-beta33 😉 . I will now also check for FRAMETYPE and add it.

Mabula

Hi Simon @stastro, can you double check for me in Pixinsight or APT perhaps, I  think the keyword is IMAGETYP and not FRAMETYP ?

According to the official FITS specification, both IMAGETYP and FRAMETYP or not part of it. See https://fits.gsfc.nasa.gov/fits_standard.html , so the FRAMETYP or IMAGETYP is maybe used between some applications but it is not described in the official FITS specification.

Do you know which is the correct FITS tag so Pixinsight will understand the frames coming from APP? Is it IMAGETYP or FRAMETYP ?

And do you know which values the tag can take? Do you use APT for capture? Maybe you can check in those captured FITS files for the keyword and what values it takes for bias, dark, flat, darkflat, lights and their masters?

EDIT: I see on the pixinsight information that MasterBias, MasterDark, MasterFlat in the IMAGETYP should work, so it can recognize the calibration masters. Can you confirm this?  https://pixinsight.com/forum/index.php?threads/wbpp-2-7-8-inconsisteny.23996/

Thanks a bundle !

Mabula

Here are the Fits tags of the reference image and the integrated file as read in APP. The capture was made with NINA.

@mabula-admin My Mistake, it would be IMAGETYP

Posted by: @dav78

↑

Here are the Fits tags of the reference image and the integrated file as read in APP. The capture was made with NINA.

Thanks @dav78,

I will try to have the pointing info stored in the FITS that APP will produce in the next release beta 33.

Mabula

Posted by: @stastro

↑

@mabula-admin My Mistake, it would be IMAGETYP

Hey Simon @stastro,

Yes, thanks, It is already implemented and it will be in the next release 2.0.0-beta33 which I will try to release in the coming week 😉

Mabula

@mabula-admin 

That will be great! Especially when we have to make an astrometry after integration. 

Also, this datas must remain in the fit header, whatever the process we are using (crop, light pollution removal...) 😉

Hi Simon @stastro and @dav78,

I have fixed everything for the 2.0.0-beta33 release,the FILTER tag, FRAMETYP tag and moving all distinct FITS tags from the reference or source FITS files to the output FITS images that APP produces across the whole application. So all relevant tags for plate-solving like RA and DEC coordinates will remain present now.

This is from the release notes:

• IMPROVED and FIXED, keep FITS HEADER TAGS from reference/source files including RA, DEC, FOCALLEN, XPIXSZ, YPIXSZ, DATE-OBS etc...
  

  As mentioned in several topics like this one  https://www.astropixelprocessor.com/community/rfcs-request-for-changes/include-more-fits-header-information-in-the-integration/#post-31871 , whenever APP would make a new FITS file, old FITS tags from the reference or source file would be lost like the RA and DEC coordinates of the object in the image. This is now fixed for the entire application. Calibration masters will still have all the information from the capture software like gain and sensor offset if present, integration files will have all the distinct FITS tags from the reference frame which should make sure that all information is correct like the RA and DEC coordinates. And saving FITS files in all tools will keep the original FITS header tags that APP will not add itself. The FTIS header will have a note that indicates when the transferred tags start from the source/reference file: HDU1 - NOTE-XX = 'Distinct header tags from the original/reference frame follow below' 
  See the below screenshots for the FITS headers that APP will now produce keeping the distinct FITS tags from the reference or source FITS files. Also note the addition of FILTER tag and FRAMETYP tags as described in the release notes below:

I will try to release 2.0.0-beta33 in the coming days for sure 😊 !

Mabula

That's great @Mabula-Admin, thanks !

Next step, astrometry provided with APP, for color calibration and mosaics 😉