Skip to content

Compressed HDU enhancements #3895

Description

@embray

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
  • The use of CFITSIO also breaks support for direct compression of non-contiguous arrays (see Pyfits: Incorrect writing of non contiguous data in compressed FITS #2150), as there is no straightforward way to make CFITSIO understand Numpy nditer iterators. Addressing the first bullet point would make this straightforward. edit: done in Avoid copying non-contiguous data in CompImageHDU #14425
  • 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.

Activity

  1. astrofrog commented on Nov 23, 2021

    @astrofrog
    Member

    This should probably involve some kind of array wrapper that only decompresses tiles as needed, and perhaps also caches recently used tiles

    This sounds like something dask could do if we wanted - and we would also get things like parallelisation over tiles etc for free.

  2. rlwastro commented on Nov 23, 2021

    @rlwastro
    Contributor

    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.)

  3. Cadair commented on Feb 17, 2022

    @Cadair
    Member

    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?

  4. Cadair commented on Mar 16, 2023

    @Cadair
    Member

    @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 ?

  5. astrofrog commented on Mar 16, 2023

    @astrofrog
    Member

    Yeah I would say let's wait until that PR is merged to tick the last box.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions