What is the problem this feature will solve?
We [Rubin] are finding that files written by Astropy with GZIP compressed HDUs are unreadable by DS9 and nom.tam.fits (and seemingly fv). See
The issue seems to be that there are many readers out there who think the presence of ZQUANTIZ means that data must be quantized and make bad decisions.
The relevant Astropy code is https://github.com/astropy/astropy/blob/main/astropy/io/fits/hdu/compressed/header.py#L530-L540
Given that DS9 makes annual releases and fv has not had a release in 6 years, can we discuss whether we can drop ZQUANTIZ from the header when there is no quantization? I know that this is standards-compliant (CFITSIO works just fine) but DS9 being unable to read images until they make a new release is a possible reason to try to modify Astropy.
Describe the desired outcome
Not writing ZQUANTIZ if there is no quantization would allow files written by Astropy to work with unpatched DS9 and nom.tam.fits.
Additional context
No response
What is the problem this feature will solve?
We [Rubin] are finding that files written by Astropy with GZIP compressed HDUs are unreadable by DS9 and nom.tam.fits (and seemingly fv). See
The issue seems to be that there are many readers out there who think the presence of ZQUANTIZ means that data must be quantized and make bad decisions.
The relevant Astropy code is https://github.com/astropy/astropy/blob/main/astropy/io/fits/hdu/compressed/header.py#L530-L540
Given that DS9 makes annual releases and fv has not had a release in 6 years, can we discuss whether we can drop ZQUANTIZ from the header when there is no quantization? I know that this is standards-compliant (CFITSIO works just fine) but DS9 being unable to read images until they make a new release is a possible reason to try to modify Astropy.
Describe the desired outcome
Not writing
ZQUANTIZif there is no quantization would allow files written by Astropy to work with unpatched DS9 and nom.tam.fits.Additional context
No response