Comments (7)
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?
Is there a rationale behind not adding a C dependency behind a feature flag?
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.
from image.
I think it's best to provide this functionality outside the image
crate itself. All the necessary types and traits for it are public. You can look at the webp
crate that wraps libwebp
in C to see how it's done.
from image.
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 libcfitsio
dependency is somewhat of a blocker. We really try to avoid C dependencies and have been working to remove the ones already present (which are already all gated behind non-default feature flags). There's a bunch of reasons for it including the portability concern you mention, compatibility with fuzzing, and limiting unsafe code.
None of this is to say that there's anything stopping you from using this crate alongside fitsio
today. We very intentionally expose ways of getting access to the contents of our image types, which means that you could write an external crate to do the necessary adaptation to interface with fitsio. In fact, this could even be a path towards building a pure-Rust FITS crate that could later serve as a codec backend for this crate, in much the same way that we internally use the png
, tiff
, zune-jpeg
, etc. crates.
from image.
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 image
can only support FITS encode and not decode.
I agree that the libcfitsio
dependency is somewhat of a blocker, which is why in my implementation it is hidden behind a feature flag. I am working on a pure rust impl of fitsio, but that will definitely take time.
from image.
image
can only support FITS encode and not decode
Why is that?
I agree that the libcfitsio dependency is somewhat of a blocker, which is why in my implementation it is hidden behind a feature flag. I am working on a pure rust impl of fitsio, but that will definitely take time.
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!
from image.
Since image
crate does not support arbitrary dimensions etc, I do not see why image
crate has to support reading an arbitrary FITS file, which may not even contain an image. FITS, however, does support storing the kind of images that image
crate works with, so writing to FITS poses no such problems.
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.
from image.
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?
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. DynamicImage
is great for packaging an image in a Rust application that is operating a camera. The relevant metadata is also generated at the time of capture, such as timestamp, ROI, detector temperature, etc. The user, if necessary, can then perform simple operations (such as rotation, flipping) with the standard interface that DynamicImage
provides, and write it out to a FITS file. This is also the reason image
crate does not need to be able to import arbitrary FITS files.
from image.
Related Issues (20)
- Benchmark error: UnsupportedError { format: Exact(Jpeg), kind: Color(Rgba8) } HOT 1
- Certain JPEGs cause assertion failure in zune-jpeg HOT 5
- 10-bit avif support HOT 2
- How to set the DPI of an image before saving it? HOT 1
- DynamicImage.view().to_image() results in Rgba8 buffer even when source isn't HOT 2
- Moving `imageops` and similar functionality to the `imageprocs` crate HOT 8
- JpegEncoder is very slow! HOT 2
- Add missing map2/apply2 functions to `Pixel` trait HOT 4
- PBM encoder is incorrect for ASCII, aka PnmSubtype::Bitmap(SampleEncoding::Ascii) HOT 1
- Proposal: more aggressive feature flags HOT 4
- Version 0.26.x HOT 4
- Opening and saving an sRGB image yields different colors HOT 5
- PNG (and probably AVIF) encoding with compression too slow HOT 6
- Format error decoding Jpeg: invalid JPEG format: JPGn(7) marker found where not allowed HOT 5
- Add serde support for image::ImageFormat HOT 2
- JPEG decoding inconsistent with other (non-Rust libraries) HOT 1
- Invert Alpha method HOT 5
- Switch to the `rgb` crate `v0.9` pixel types and trait. HOT 1
- Format error decoding Png: Invalid PNG signature. When reading png with embedded color profile
- Building with default features on macOS requires rustc v1.79 or newer.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image.