I've only skimmed it, but this PR looks kinda hard to review because moves around a bunch of finicky code.

One thing that particularly stands out to me though is that it uses a macro to generate generic, unsafe trait impls, on a public type. That's both a public API addition and inserts new unsafe code to the library. Potentially hard to justify for a minor perf improvement

One alternative is to create a clone of theimage_transform which instead returns the colors in place.

Other than exposing anunsafe impl directly to the users, it's also possible to directly transmute the underlying types at the point where the bytemuck cast was added. I wasn't sure if that would be more or less preferred.

Looking though this now, the PR basically just changes a memcpy into an unsafe transmute? That's not an improvement IMO. We'd ideally like this crate to be#[forbid(unsafe_code)], and while we're not quite there yet, I'd really rather not add any more unsafe in the meantime

For me, as long as the unsafe code is entirely within the confines of the API and with controlled types, then it's fine to introduce. But that's a personal opinion, so I've ripped it out & should be cleaner now.