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
While I'm thinking about the topic, this issue will serve as a clearinghouse for work that needs to be done on the FITS tile compression support:
Tile compression should be implemented natively in Python, with a few C/Cython functions for implementing the actual compression/decompression algorithms. What I mean by this is that currently tile compression is supported by hooking io.fits into CFITSIO in a rather complicated and ad-hoc manner. It is the only feature CFITSIO is used for. With Pythonic wrappers for the supported compression code, most of the need for CFITSIO can go away. Some of the other functionality currently in CFITSIO, such as the code for breaking an image into tiles and iterating over those tiles, can be easily rewritten in Python using Numpy. edit: done in A new tiled image compression submodule mostly replacing cfitsio #14252
Support actual per-tile decompression. Part of the point of the tile compression convention is that images can be decompressed one (or several) tiles at a time, as needed, rather than decompressing the entire image in one go. The current code does the latter, and thus misses out on a lot of performance opportunities. This should probably involve some kind of array wrapper that only decompresses tiles as needed, and perhaps also caches recently used tiles. edit: done in Implement lazy-loading of data for CompImageHDU #14353
Having all of the above fixes in place would also open the door to multi-core compression/decompression. Using tiles effectively makes this ridiculously parallelizeable.
Yes! To manage things efficiently we need lazy instantiation of tiles plus some means of caching and "retiring" tiles (or maybe swapping out to VM, but it would likely be faster to go back and re-read and uncompress a tile rather than writing and reading an uncompressed version of it). I completely agree that dask sounds like a good basis for the development. I'd love to see this happen and am willing to help. (I'm very familiar with the low-level cfitsio compression code since I wrote most of it.)
Hey @rlwastro I too would love to see this happen, but while I have some experience with dask and astropy.io.fits it sounds like you have a lot more of the skills that would be needed to make this happen!
Do you have time to work on this? Is there anything myself or the Astropy project could do to help you work on this problem?
@astrofrog am I correct in saying that we have now achieved
Having all of the above fixes in place would also open the door to multi-core compression/decompression. Using tiles effectively makes this ridiculously parallelizeable.
with the latest performance PR, if you know how to do the dask magic? or are we keeping that box un-ticked until we merge #14452 ?
While I'm thinking about the topic, this issue will serve as a clearinghouse for work that needs to be done on the FITS tile compression support:
io.fitsinto CFITSIO in a rather complicated and ad-hoc manner. It is the only feature CFITSIO is used for. With Pythonic wrappers for the supported compression code, most of the need for CFITSIO can go away. Some of the other functionality currently in CFITSIO, such as the code for breaking an image into tiles and iterating over those tiles, can be easily rewritten in Python using Numpy. edit: done in A new tiled image compression submodule mostly replacing cfitsio #14252