UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred  after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Â Before I release it, I will make sure that everything is working properly and then I will release it.
How easy would it be to implement some sort of plate solving function for the final image stacks. In my Light frames the RA and Dec is recorded by SGPro, and then when I want to use another tool for Post Processing it would be good to have the Astrometry details in the image stack.
Also it would also be nice if APP would use the FITS naming convention properly, for example I have noticed that on my Calibration Masters, they are not recognised in other applications because the "FRAMETYPE" variable does not exist in the FITS header, and with my light frames, the Keyword "FILTER" does not exist either, it has been replaced with some other variables that are not recognised with other applications.
Here's an example of an image stack for my Ha data created by APP
FILT-1 is not recognised by other apps, and I have to manually go in and add FILTER into the FITS header
Regards
Simon
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 😉
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 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
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
Â
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...) 😉
Â
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 😉Â
