I am putting the finishing touches to my rust fits library: fitsio
.
I would love to get feedback from any astronomers using rust. The documentation is reasonably complete, so please let me know if I've missed any features, or there is a bug.
I am putting the finishing touches to my rust fits library: fitsio
.
I would love to get feedback from any astronomers using rust. The documentation is reasonably complete, so please let me know if I've missed any features, or there is a bug.
Hi and thank you for your works.
I have a suggestion about the image I/O part of your fitsio lib.
The current api's are rather low level, it would be help to enable the ability to read image data into some rust multidimensional array e.g., ndarray
Otherwise, the user would have to reshape the data themselves.
Hi, thanks for your reply!
I did want to include the ability to read image data into an ndarray
. I think, though I've not tested it extensively, that as the image reading functions take slices, that they're already compatible with ndarray
. You are right, the user will have to reshape it afterwards.
I'll have a think about how to support this. I can imagine creating a trait which is implemented by slices and ndarray
s, and put the ndarray
-specific behaviour behind a cargo feature.
I am not keen on adding more dependencies than are completely necessary at this early stage.
Edit: added github issue
I have another question about writing image.
When I try to create a new fits, and call create_image, it adds a new extended hdu, rather than the primary hdu.
What is the correct method to write data into the primary hdu?
Thanks.
Good point. Currently, creating a new file adds a blank primary HDU.
You should be able to use FitsFile::hdu(0).unwrap()
to get the primary HDU, and resize
the HDU to the correct size.
What isn't supported at the moment is changing the data type of the HDU. I have added this to my todo list (first issue, second issue)
These "ecosystem integration" type dependencies are typically put behind feature flags, so that they can be enabled on demand by library users.
@astrojhgu I added support for customising the primary HDU in the git repository last December, please feel free to check it out!
Thanks!
I'm just trying to use it in my computing antenna beam program.
Cool, sounds interesting. Please keep me up to date on how you are finding the library, and if it can be improved in anyway. You're the first person I know of using it in anger!
Also: version 0.12.1 has the primary hdu creation, if you wanted a versioned release.
Hi, I have just encountered a problem: about the dimension description in ImageDescription.
Suppose I want to generate a 512 row, 1024 col image, how should I compose the dimension field? I guess it should be [512, 1024]? But when I write so, it will create a 1024x512 image.
Following is my test code (sorry that I don't know how to copy code here), notice the highlighted line (i.e., L10):
@astrojhgu you're absolutely right. As stated in the cfitsio
documentation:
C programmers should note that the ordering of arrays in FITS files, and hence in all the CFITSIO calls, is more similar to the dimensionality of arrays in Fortran rather than C. For instance if a FITS image has NAXIS1 = 100 and NAXIS2 = 50, then a 2-D array just large enough to hold the image should be declared as array[50][100] and not as array[100][50].
Given Rust has the same ordering convention as C, it would be nice to keep to the C convention.
I've created a new issue with this in the repo issue tracker. Thanks for your feedback, and please continue to report any problems or suggestions.
@astrojhgu If you're not already, you may want to use the git url to include fitsio
in your project, as it is changing rapidly:
[dependencies]
fitsio = { git = "https://github.com/mindriot101/rust-fitsio" }
I'm not always releasing a new version of the crate with each change I mention here.
@astrojhgu I'm working on ndarray support in the ndarray-support
branch. Currently it reads the data into a dynamically sized ArrayD
, meaning I don't have to implement code for all image dimensions, given that FITS technically supports "images" which aren't 2D.
Please feel free to check it out. I will push some more useful documentation soon. It is hidden behind an array
feature flag, so after checking out the branch:
cargo build --features array
or in your Cargo.toml
:
[dependencies]
fitsio = { version = "0", features = ["array"] }
Let me know how you get on.
Thanks!
That's exactly what I need.