Sergey "Shnatsel" Davidoff

We can kick the tires of this API by splitting PCX into a separate crate and using these hooks to wire it up. Also, [jxl-oxide](https://github.com/tirr-c/jxl-oxide) has shipped `image` integration just...

That sounds like a good way to dogfood the hooks. IMHO there's also value in segregating the formats with weird licenses. PCX is under WTFPL, we probably don't want to...

`pcx` crate has been [relicensed](https://github.com/kryptan/pcx/commit/7ee82e83f8a7ce10cbba70407be40cf76aa6b14c) as `WTFPL OR MIT OR Apache 2.0`, so the license should no longer pose any issues.

On the plus side, splitting out `image-extra` would also let us break semver on those decoders without impacting `image`. I doubt that's going to be relevant to PCX though. But...

If all you want is to substitute the decoder a known format with a custom implementation you don't need the hook machinery at all. You can simply disable the support...

Thanks a lot! I'll take a closer look in the next few days. > Slightly interestingly, cargo didn't include build dependencies for the test fixtures unless I added a build.rs...

Ah, you are probably right! I am a little rusty on the finer points of Cargo dependencies.

Okay, I think I found an actual bug in Cargo: if I run `cargo +nightly build -Z sbom --release` and then `CARGO_BUILD_SBOM=true cargo +nightly build -Z sbom --release`, the SBOM...

~~I've cross-referenced the output of this PR against the output of #210, and the generated audit data matches exactly, with bit-identical outputs. This gives me a lot more confidence in...

I've realized that I've messed up the real-world testing earlier and accidentally compared the `cargo-tree` based branch against itself instead of this one. I see surface-level divergences in all produced...