Expose tile shape and compression type on CompImageHDU

[astrofrog]

I think it would be useful to expose the compression type and tile size/shape as public properties on CompImageHDU - but I have run into an API design issue. The tile_size passed in to CompImageHDU is in reverse Numpy order, so if we exposed a property such as tile_size as done in this PR it should return what is passed in to the CompImageHDU (in general this is a good design - if a parameter is passed in, accessing it via a property should give the same result).

However, I think most use cases for this would actually be interested more in the actual Numpy tile shape, so it's not clear what the best option is here. There are several options:

1. Make a new property tile_shape which is in Numpy order and deliberately has a different name from tile_size
2. Deprecate tile_size as input to CompImageHDU in favor of tile_shape, which would be in Numpy order, then have a tile_shape property that matches#
3. Another option I'm not thinking of?

Personally I find it very confusing that the input tile size is not in Numpy order and would prefer 2. but perhaps this would need a long deprecation phase depending on how widely this is used in the wild.

In principle we could also expose other settings (dithering etc) as properties but I wanted to first see if we can figure this one out.

[github-actions]

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[Cadair]

Personally I find it very confusing that the input tile size is not in Numpy order and would prefer 2. but perhaps this would need a long deprecation phase depending on how widely this is used in the wild.

👍 Why we have anything in FITS order is beyond me, we should add a new kwarg tile_shape and a property with the same name and then deprecate tile_size for the next century.

[astrofrog]

@saimn - this is ready to review if you think we should do it (but happy to discuss this more if you aren't sure!)

[mhvk]

I really dislike a size giving back a tuple so deprecating that to be a shape seems to make a lot of sense.

I think "numpy" and "fits" order really just correspond to array order='C' and order='F' (C & Fortran), so both are valid.

Given that the data shape is transposed, I think it makes sense to transpose the tile shape as well; just have to document it clearly (I'd tend to propagate the changes in the internal API as well).

[astrofrog]

@mhvk I've updated the internal code to use tile_shape too now.

[saimn]

Looks good, just a few comments.

[saimn]

HCOMPRESS_1 is for 2D images so I would keep 0 and 1 for clarity, as this is equivalent to the previous code ? (and same thing below)

[astrofrog]

It's actually possible (and supported in astropy.io.fits) to compress 3D+ data with HCOMPRESS as long as the tile size is 1 for all extra dimensions so unfortunately I think I have to leave it as I have it now?

[saimn]

Ah OK, interesting, all good then.

[astrofrog]

@saimn - this is now ready for review again

[saimn]

All good, thanks @astrofrog !