You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Loosely related to #9652 and #9685, is there a specific reason why io.fits does not support lzma compression? From the way .xz files are handled in data.py it looks like it could be implemented quite analogously in the FITS file handlers, but of course it would involve somewhat more significant modifications.
Activity
saimn commentedon Dec 10, 2019
Not specific reason I think, it is probably just less frequently used and nobody needed it.
ivvv commentedon May 22, 2024
One attractive feature is that the
xzallows multi-threading compression/decompression, which is useful with huge FITS files.dhomeier commentedon May 22, 2024
Right. Though in most such cases the tiled compression capacity of
CompImageHDUwould probably be the better choice now, linking this to #15474.saimn commentedon May 28, 2024
xz/lzma is available through python's stdlib (https://docs.python.org/3/library/lzma.html) so adding support should be straightforward.
pllim commentedon May 28, 2024
Is this one of those libs that not always there? Might complicate logic a little but not a blocker.
neutrinoceros commentedon May 28, 2024
Correct. We have a couple use cases for
HAS_LZMAalreadydhomeier commentedon May 28, 2024
And we already have an equivalent setup for
HAS_BZ2kYwzor commentedon Apr 1, 2025
Came across this while working on #17960. Not sure how common these actually are, but the code necessary for this is so simple I just created a PR. I could find at least one instance of "fits.xz" files in the wild, so there are real use-cases (if rare).
EDIT: Found another example file here