New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing images to FITS files #2214
Comments
Before adding FITS support, I'd want to understand how commonly the file format is used. In particular, since the format supports up to 999 dimensions (!) and a whole bunch of channel formats that this library cannot handle, it would be good to know how common it is for 2D arrays of pixels However, before getting there the None of this is to say that there's anything stopping you from using this crate alongside |
In astronomy FITS is THE standard to go with - everything from Hubble to JWST to you name it uses FITS. Most images are however monochrome, and I agree that the |
Why is that?
I don't think we should add this as a C dependency even behind a feature flag. Please do share updates on the pure Rust implementation you're working on though, I think that could be quite useful for the Rust ecosystem! |
Since Is there a rationale behind not adding a C dependency behind a feature flag? I must also add, before FITSIO goes through, adding image metadata will be imperative. I don't see too many people being interested in a FITS file that simply contains image data and no other associated information. |
Could you say a bit more about the flow here. Is the idea that the user would load a PNG or JPEG containing an EXIF chunk, and then we'd parse that chunk and write each of the metadata fields into the FITS file?
Yes, a lot of the maintainer overhead is the same regardless of whether the dependency is behind a feature flag or not. We'd need to be able to run tests for the module locally, build and test it in our CI, and ensure that the module was included in the generated documentation on docs.rs. It also takes away from other goals like getting higher levels of fuzzer coverage or reducing the amount of unsafe code. And once people are using the C dependency it becomes a potentially breaking change to switch to a pure Rust implementation if there isn't perfect feature parity, which can make it controversial as we discovered when moving away libwebp. |
I do not see a user loading a PNG or JPEG image, containing an EXIF chunk, and writing that into a FITS file. Data for scientific applications would already be received as a FITS file by the generating application. The use case for this, really, is storage of captured images. |
I think it's best to provide this functionality outside the |
The Flexible Image Transport System, FITS, is an open standard used extensively in astronomy (both amateur and scientific) and scientific research. The FITS standard supports storing images in a lossless format with optional data compression, with comprehensive metadata support. Adding FITS support to the
image
crate will be great for extending its use in the scientific data collection space.Caveat:
Currently, the only feature-complete FITS library for Rust is the
fitsio
crate. This crate wraps the Clibcfitsio
library in order to provide FITS functionality, which cannot be (easily) compiled on the more exotic targets (e.g.wasm32-unknown-unknown
) as the object files fromlibcfitsio
are required.The text was updated successfully, but these errors were encountered: