A. Molzer
7d498a0284
We have a fundamental choice here: We could add more proxy implementations for `Vec` and `Box` to follow `&'_ T`, for some types that indirections is clear. Vec and arrays are also both very natural ways of expressing a repeated value. However, passing an allocated value to the interface forces us to drop it inside. We might be able to utilize the allocation for an in-place byteswap in a future increment but not with the current design. So, overall, I think that inherently `Drop`-y types should be avoided in these implementations. Instead, we can use the amazing diagnostic tools in the compiler to just help the users navigate the type system. We can still provide the impl for arrays. For context, see: https://users.rust-lang.org/t/what-type-is-u16/137395 Now they see: | 38 | .write_tag(tiff::tags::Tag::GeoKeyDirectoryTag, &geokey); | ^^^^^^ the trait `TiffValue` is not implemented for `&Vec<u16>` | = note: the trait is implemented for primitive types (`u8`, `i16`, `f32`, etc.) = note: the trait is implemented for shared references to values = note: the trait is implemented for slices, pass them by reference (e.g. `&[u8]`) = note: the trait is implemented for arrays if it is implemented for a slice = note: values in a `Vec` or `Box` should be dereferenced, e.g. `&vec[..]` = help: the following other types implement trait `TiffValue`: Previously the compiler would both strip the `&` in its first message (due to our forwarding impl) and not list any way of getting a reference-to-slice.
image-tiff
TIFF decoding and encoding library in pure Rust
Supported
Features
- Baseline spec (other than formats and tags listed below as not supported)
- Multipage
- BigTIFF
- Incremental decoding
Formats
This table lists photometric interpretations and sample formats which are supported for encoding and decoding. The entries are ColorType variants for which sample bit depths are supported. Only samples where all bit depths are equal are currently supported. For example, RGB(8) means that the bit depth [8, 8, 8] is supported and will be interpreted as an 8 bit per channel RGB color type.
PhotometricInterpretation |
UINT Format | IEEEFP Format |
|---|---|---|
WhiteIsZero |
Gray(8|16|32|64) | Gray(32|64) |
BlackIsZero |
Gray(8|16|32|64) | Gray(32|64) |
RGB |
RGB(8|16|32|64), RGBA(8|16|32|64) | RGB(32|64), RGBA(32|64) |
RGBPalette |
||
Mask |
||
CMYK |
CMYK(8|16|32|64) | CMYK(32|64) |
CMYKA |
CMYKA(8) | |
YCbCr |
||
CIELab |
Compressions
| Decoding | Encoding | |
|---|---|---|
| None | ✓ | ✓ |
| LZW | ✓ | ✓ |
| Deflate | ✓ | ✓ |
| PackBits | ✓ | ✓ |
| Fax4 | ✓ | not yet |
| JPEG | ✓ | not yet |
| ZSTD | ✓ | not yet |
Not yet supported
Formats and interpretations not listed above or with empty entries are unsupported.
- Baseline tags
ExtraSamples
- Extension tags
Fuzzing
This crate uses cargo-fuzz in order to test the image parser.
After installing it with cargo install cargo-fuzz on a nightly rustc, the
fuzzing harness can be run with recommended settings using
cargo fuzz run decode_image -snone -- -timeout=5.