feat(fits): add FITS image support

[cek]

No description provided.

[Tom94]

Heya, thanks a lot for the PR. Currently don't have all that much bandwidth, so might be a little bit until I get to review & merge.

[cek]

No worries at all -- no rush, and thanks! I'm just happy to be able to examine astrophoto images in my favorite viewer, rather than having to use one of the terrible alternatives. ;)

To be a more full-featured replacement for said alternatives, tev would also need a astrophoto-centric tone mapping operator and associated controls. However, such a specific/extreme tone mapper probably won't be of interest to most tev users, and thus would be a waste of UI space to render it all of the time. Once I have something working, I'm likely to have questions about how to integrate it such that it doesn't clutter the UI when not needed (e.g., a visibility toggle, defaulting to rendering it if a FITS image is loaded, for example...?) Or it may prove to be too specialized to add to tev proper. In any case, more to come.

[Tom94]

I was planning to add soft clipping (log-space sigmoid with configurable min/max brightness) to the HDR popup menu. Probably not the kind of tone mapping you are looking for 😅, but mentioning it just in case.

I think other specialized tone maps would also fit into the HDR popup for now… to be consolidated in an actual tone map selector when/if tev gets support for a bunch of other standard graphics ones (that’d share aforementioned min/max brightness controls and also consume image metadata like max FALL etc.)

[Tom94]

Thanks again for the PR! Looks mostly good to me -- just requesting a few minor changes.

EDIT: oh, and I almost forgot: could you add a fits entry to void ImageViewer::openImageDialog() as well?

[cek]

Thanks and sorry about that -- a little too quick on the PR trigger...

[Tom94]

Thanks a lot! I think I can take it from here. Just one more question to make sure: are uint8 fits images really linearly encoded?

If they were sRGB-encoded you could use toFloat32<true>(...) to do the decoding, but generic transfers like gamma curves require a bit of extra code.

And: is there no signed int8 format?

[cek]

The vast majority of FITS files hold either linear 12-to-16-bit raw sensor data as uint16, or linear processed (and possibly negative) data as fp32.

They can also hold processed data that is wildly nonlinear -- extreme "stretching" of shadow/lower-order bits where the interesting astro signals live. But FITS data is essentially never sRGB-encoded.

FITS has no real support for signed 8-bit data. I don't think I've ever seen an 8-bit FITS file in the wild, to be honest.

Thanks again!

[Tom94]

Sorry again for the delay; just tested the PR and it's ready to be merged in principle. Just one remaining thing:

I noticed that 5 out of the 10 top-level sample images from https://fits.gsfc.nasa.gov/fits_samples.html don't load. 4 of them with "Invalid FITS structure" and 1 with "Non-standard BZERO/BSCALE".

I think it's fine if tinyfits does not support the whole format (though I'd of course prefer that :)), but the error messages should at least make clear which FITS images are simply unsupported vs. malformed. tev's README should also specify which subset of FITS is actually supported in the formats section. (tev goes to great lengths to support pretty much every feature of the existing bolded formats.)