Sergey "Shnatsel" Davidoff
Sergey "Shnatsel" Davidoff
Yes. Although most formats that are currently bundled are so simple that splitting them out didn't really make sense.
I asked around and it seems the typical way to deal with this is `#[doc(hidden)]`, which I find unsatisfying but is apparently the least invasive way. We could also restructure...
We could also keep the old impl around and add a new one for toml 0.8, but since getting rid of 0.7 in the dependency tree is a big part...
I like that approach in principle but I am not keen on writing the `map_err` all over the codebase. I think that's why we didn't go with it for 9.0.0?...
For deployment-time rather than coding-time thread count customization, I believe the `RAYON_NUM_THREADS` environment variable documented [here](https://github.com/rayon-rs/rayon/blob/main/FAQ.md) would be a good option.
I've been thinking about this now that we can make semver-breaking changes again. I don't think we will be able to get around letting people pass a custom Rayon thread...
I'm not a fan of this approach because if the application handles Exif like a black box and forwards it to the output (like most image conversion programs would do,...
> implemented in tiff crate but not wired up to image @1c3t3a could you clarify? I cannot find any references to `tiff` crate supporting IPTC metadata.
cc @kornelski
`ImageReader` already supports limits, as you've already noticed. `image::open` is a high-level convenience function, if you need more control you're expected to create an `ImageReader` and set the options on...