Aurelia Molzer

A reason why hotswapping is generally avoided, is to work around ABI compatibility concerns. However, in a language that embeds these abi-declarations into its object code one could check this...

It would but the crate needs to go `1.0` for this to really be considerably better. An unstable compatibility crate makes little to no sense because it necessarily ends up...

You don't need to open a new PR by the way, `git` allows you to force push the branch and Github then updates the PR automatically. Not sure if this...

Unfortunately, the unchecked cast from `f64` to `u32` in `from_dpi` [may not be as safe as one would like](https://doc.rust-lang.org/reference/expressions/operator-expr.html#semantics). Even if, as currently expected, it were to adopt saturating semantics...

The conversion from inch to meter also follows from the [*definition*](https://en.wikipedia.org/wiki/Inch) of an inch as `25.4mm`. Hence, the more precise number to use is `(1000.0/25.4)` but that shouldn't matter greatly...

The approach sounds good, in particular ensuring that `Upsampler::upsample_and_interleave_row` is passed a no-op for its `color_convert`, and a PR would be great.

There are at least two case where applying the transformation at decode time, instead of later, is advantageous compared to a post-processing step after the full buffer is decoded. There...

``` $ djpeg -verbose /tmp/97358000-fc1b8d80-1870-11eb-959b-e4f8051c9502.jpg > /dev/null libjpeg-turbo version 2.0.5 (build 20200830) Copyright (C) 2009-2020 D. R. Commander Copyright (C) 2011-2016 Siarhei Siamashka Copyright (C) 2015-2016, 2018 Matthieu Darbois Copyright...

Have you tried using `dyn BufRead` instead? The performance difference should be negligible, the reason why `png` can't use it is more or less due to auto-trait (`Send` + `Sync`)...

Nice. Do you want to open this as a pull request or us to rebase changes incrementally?