[Solved] Java error message - FITS files created by EasyCAP of QHY

Hi Gary,

Thank you for reporting this. Can you share a screenshot of the APP main window and the APP console possibly when this happens? Most usefull would be if you could send me one of those QHYCCD8L files. I assume these are FITS files? If you can and want me to have a look myself, you can send one frame to mabula@astropixelprocessor.com using wetransfer or dropbox.

Does the error occur on initial loading of the frames?

Kind regards,

Mabula

Hi Gary,

Yes, the problem is quite clear fortunately.

The DATE tag in the FITS header doesn’t follow FITS conventions at all I am afraid.

The creator of the application that created this FITS file should definitely be warned also about this I feel ( the people at NASA would certainly agree).

https://archive.stsci.edu/fits/fits_standard/node40.html#SECTION00942110000000000000

“Starting January 1, 2000, the following format shall be used. FITS writers should commence writing the value of the DATE keyword in this format starting January 1, 1999 and before January 1, 2000. The value  field shall contain a character string  giving the date on which the HDU was created, in the form YYYY-MM-DD, or the date and time when the HDU was created, in the form YYYY-MM-DDThh:mm:ss[.sss...], where YYYY shall be the four-digit calendar year number, MM the two-digit month number with January given by 01 and December by 12, and DD the two-digit day of the month. When both date and time are given, the literal T shall separate the date and time, hh shall be the two-digit hour in the day, mm the two-digit number of minutes after the hour, and ss[.sss...] the number of seconds (two digits followed by an optional fraction) after the minute. No fields may be defaulted and no leading zeroes omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of §5.2.

The value of the DATE keyword shall always be expressed in UTC when in this format, for all data sets created on earth.

The following format may appear on files written before January 1, 2000. The value  field contains a character string  giving the date on which the HDU was created, in the form DD/MM/YY, where DD is the day of the month, MM the month number with January given by 01 and December by 12, and YY the last two digits of the year, the first two digits being understood to be 19. Specification of the date using Universal Time  is recommended but not assumed.

Copying of a FITS file does not require changing any of the keyword values in the file's HDUs. “

So only FITS files created before 2000 can have the forward slash / in the DATE tag, And I haven’t seen any in the past 5 years to be honest… If the year part consists of 4 fields like 2017 then the forward slashes simply aren’t allowed to be used.

The required format is: YYYY-MM-DDThh:mm:ss[.sss...]

Your file has: DATE    = '7/12/2017'          / Capture Date

So that’s the bad news regarding these FITS files, they simply aren’t created according to FITS specifications and the creator of the application that created these FITS files really should be warned about their bad implementation.

-------------

Now the good news: I can however easily compensate for this I think. So I’ll work on this, this afternoon so it makes the next APP release.

But, please make the developer of the application that created this FITS file aware as well.

 Unfortunately, lots of developers don’t seem to read the FITS specifications at all, which causes much frustration for the FITS inventors/maintainers at NASA.

 APP uses the latest version of the NASA java library to interpret FITS files and the people at NASA really feel that a problem like this should be solved at the source, otherwise they need to adjust their code to support bad implementations ;-( which is something they simply don’t want to do as you might understand.

 As soon as a new APP version is released, which has this fixed, I’ll restart your trial period 😉 when you have downloaded it.

 And i’ll notify you when it’s fixed.

 Kind regards,

Mabula

Hi Gary,

 It’s fixed 😉. I’ll release the next APP with the fix possibly today, otherwise tomorrow…

 I notice this is CFA data, so in 0) RAW/FITS you will need to enable “force CFA” for correct processing and it seems the bayer pattern is GBRG, would that be correct?

 Furthermore easyCAP of QHY apparently delivers files with really large raw borders which need to be cropped as part of calibration. Is this normal behaviour of EasyCap?

na vele keren geen probleem nu JAVA  java.lang.NulPointer .Exception ! nieuwste versie APP

Guido FORRIER

having only recently problems with JAVA . i use SIRIL to convert Sony files to FIT and had no problems before . she screenshot

Guido

@guidoforrier,

When do you get this? when you just load an image or when you do a certain process?

Maybe you can send me 1 or 2 files that produce the problem?

Mabula

If it's any help, until I updated my video card I would get that error but.... only one doing star color calibration and only if I selected the entire frame with nebulosity in it, I would not get the error if I select a little boxes. Go figure.

@guidoforrier,

Does the error still happen in APP 1.059 ?

If so could you send me 1 of the files and show a screenshot of the console window when the error happens?

Thanks,

Mabula