https://bugs.kde.org/show_bug.cgi?id=444094
Bug ID: 444094
Summary: FITS Viewer corrupts certain FITS images on save
Product: kstars
Version: 3.5.5
Platform: Ubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mutla...@ikarustech.com
Reporter: christian.ck.kir...@fau.de
Target Milestone: ---
Created attachment 142660
--> https://bugs.kde.org/attachment.cgi?id=142660&action=edit
FITS file recorded in a sequence queue which will be corrupted when saving via
FITS viewer
SUMMARY
FITS images saved using the FITS viewer (either from observations in preview
mode or when simply opening an existing FITS file) are sometimes corrupted. The
image looks as if the first 1440 pixels contain garbage data.
STEPS TO REPRODUCE
1. Open the attached file (BACHES_001.fits) with the FITS viewer
2. Use "Save As" to write it into a new file
3. Inspect the new file in any FITS viewer, comparing to the original.
OBSERVED RESULT
Looking into the file, the first 1440 pixels in the image filled with garbage
data and all other pixels shifted accordingly. As the image is 1530 by 1020
pixels, this makes it look like the first 90 columns were shifted to the back.
The FITS file also no longer complies with the FITS standard (see for instance
the FTOOL fverify). Here, the second HDU (which should not exist) is reported
to be corrupt.
EXPECTED RESULT
Aside from the statistics header keywords kstars inserts (MIN1, MAX1, MEA1,
...), the input and output files should be the same.
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma: Ubuntu 20.04.03 LTS
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version: 5.12.8
ADDITIONAL INFORMATION
I've noticed that this bug only happens when the additional header keywords
inserted by kstars increase the size of the FITS header beyond its original
block size (a FITS block being 2880 bytes). In this case, the original header
only takes one block of space and gets extended to two blocks.
Furthermore, the number of corrupted pixels corresponds to exactly one block in
storage (1440 16 bit pixels -> 2880 bytes).
My guess is that the header is somehow extended incorrectly, such that data
that is supposed to be in the header unit is parsed as if it is in the image
data unit. This would explain why the *first* 1440 pixels of the new image are
corrupted, and the *last* 1440 pixel values of the original image are lost.
I've also noticed that, when inspecting the FITS file written by kstars in
e.g., vim, that there is an additional END header key (otherwise empty) before
the actual END card newly inserted by kstars. This may be the root of the
parsing error (I don't think END header keys are formally allowed?)
--
You are receiving this mail because:
You are watching all bug changes.
