20 January 2021: Soon to be released APP 1.083-beta2 : improved comet registration, updated tools, new Star Reducer Tool and more...
16 November 2020 - Wouter van Reeven has officially joined the Astro Pixel Processor Team as a moderator on our forum, welcome Wouter 🙂 !
Invalid FITS Header on ZWO ASI 178MC
my name is Riccardo, and I am a new (trial) user of APP.
I am trying to calibrate images created with a ZWO, but every time I try to preview the FITS file I get this error:
"This fits file seems to be incomplete and / or corrupt Error message: IO error: java.io.IOException: Invalid FITS Header "
With other programs I can load and align files. Can you help me?
That sounds like the file itself does have a problem somehow. In fact the FITS header is the issue, so while other programs may load it, they must be ignoring that while APP is using it to judge what image it is. What program did you use for shooting and saving the images?
Voyager on Zwo Asi last driver.
this is my FITS file created with Voyager.
Mm, I'm not familiar with Voyager, do you still have the raw data before using Voyager? If so, please try to load those, I suspect Voyager isn't writing the Fits header properly. I'll check the fits as well here.
Having said that, I also can load it in another package, so I'll forward this one to Mabula to see what the issue is if at all. Thanks for sharing!
Ufortunately I have no raw data, voyager writes the file directly in the updated format. I am waiting for any developments.
Mm, that's something you can't change in preferences? I would advice to always keep the original data when possible. There should be no need to process the raw data in between as APP is able to do this together with the raw calibration data.
my opinion APP expects to find a value in the header that is not written by vayager in the FITS file. But all the other programs read without problem the FITS files generated by this program APP seems to be the only one to have this type of problem (pixinshight, maximDL, DeepStaker, FITS Viewer read without problems)
Yes this could very well be, I've forwarded the file to Mabula so I'm waiting for his analysis. The original raw data however will very likely work anyway.
Hi, any news on the problem? If the trial license expires I will not be able to test this software.
Best Regards, Spectre
Not yet no, Mabula is working hard on the next version, when he doesn't respond in a few days I'll notify him again (please ask here again as well then, so we're sure we can get you the help needed).
Hi Riccardo @spectre_68,
I am investigating your voyager fits file right now. It does seem that the FITS is not created properly according to FITS NASA specification. We use a NASA library to READ/WRITE FITS files, so a properly created FITS would not give this error I think... but let me investigate a bit more for now. I will report back later 😉
Hi Riccardo @spectre_68,
After more investigation, it is becoming more clear now that this FITS file has a serious problem in terms of the FITS specification. I can only conclude at the moment that something went wrong in Voyager when the file was written to your harddisk. Do the other Fits files from voyager work properly?
my name is Paolo,
same problem encountered with images from a Starlight Xpress Trius-SX26C Color - ATEO2A Insight Observatory -
, see FIT attached. (change type file from .txt to .zip and dezip the file)
I don't know, but other files always downloaded from insight observatory's Starbase platform - from mono sensors like FLI Proline 16803 or SBIG STL11000 - I work very very well with A.P.P.
problem solved, I opened and saved all files with M DL. Now it would seem that A P P works them.
Together with Leonardo Orazi, developer of Voyager, we have found the problem. The FITS writer code that Voyager uses has a bug in terms of FITS specification.
The FITS headers are not closed properly according to FITS specification.
"Every HDU consists of an ASCII formatted `Header Unit' followed by an optional `Data Unit'. Each header or data unit is a multiple of 2880 bytes long. If necessary, the header or data unit is padded out to the required length with ASCII blanks or NULLs depending on the type of unit.
The header is padded with additional blank records if necessary so that it is a multiple of 2880 bytes (equivalent to 36 80-byte keywords) long. Note that the header unit may only contain ASCII text characters ranging from hexadecimal 20 to 7E"
The problematic voyager files have the HDU bytes filled up with 00 which is not allowed in the FITS specification. Those 00 should be 20 in hexadecimals... which is 32 in decimals... which is the ASCII blank character.
I understand from Leonardo that the FITS writer code in Voyager is a port of the same NASA library that we use and so this port was not done correctly then... Apparently, even the ASCOM driver of ASI has this bug it seems then.
I will make sure that APP will catch this bug and deals with it so the files can still be read in APP's next release 😉 allthough the problem is caused by the capture software or driver.