2.0.0: Dependency on image 0.25 is forcing users to be exposed to panics in zune-jpeg 0.4

[ssokolow]

After adding use of image_hasher to my project and bumping my image version to get the Image trait to line up, I started having all the worker threads in my indexing runs quickly dying to etemesi254/zune-image#184.

Given that the author of that crate hasn't yet responded to the three-days-ago request to backport the fix from 0.5.0-rc0 to the 0.4.x line which image 0.25 depends on, I'll leave it up to you to decide how to address this.

(Since my data flow has image_hasher as the last thing that consumes the image data and I'd rather not comment out the BitOrder parts of my code to store the generation parameters alongside the hashes, my workaround is just to use image 0.24 for loading images and then also depend on a copy of image 0.25 with no features enabled and do a non-copying hand-off of the decoded pixel data to it to make the types line up.)

    // Hand off so we can use the un-panic-y JPEG loader from image 0.24 with a newer image_hasher
    let image: image_025::ImageBuffer<image_025::Rgba<u8>, _> =
        image_025::ImageBuffer::from_raw(width, height, img_rgba8.into_raw())
            .expect("Handed image data off from image 0.24 to image 0.25");

    // In debug builds, save the handed off data, re-load it with image 0.24, and check for
    // equality to ensure the hand-off didn't do something like get the byte order wrong.
    #[cfg(debug_assertions)]
    {
        let mut tbytes: Vec<u8> = Vec::new();
        image.write_to(&mut Cursor::new(&mut tbytes), image_025::ImageFormat::Png)?;
        let img2 =
            ImageReader::new(Cursor::new(tbytes)).with_guessed_format()?.decode()?.into_rgba8();
        assert!(image.as_raw() == img2.as_raw());
    }

    let perceptual_hash = hasher.hash_image(&image);
    trace!(" Image Hash: {}", perceptual_hash.to_base64());

[mqudsi]

Just add this to Cargo.toml:

[patch.crates-io]
# Until a 0.4.x update is released for https://github.com/etemesi254/zune-image/issues/184
# and https://github.com/qarmin/img_hash/issues/19
zune-jpeg = { git = "https://github.com/etemesi254/zune-image/", rev = "add9ba71c9e29665ca65003ead12f85d25d763a7" }
zune-core = { git = "https://github.com/etemesi254/zune-image/", rev = "add9ba71c9e29665ca65003ead12f85d25d763a7" }

[ssokolow]

That would prevent me from uploading my crate to crates.io

I'll stick with my solution of using two versions of image and a hand-off of the decoded in-memory data from 0.24 to 0.25 for now.

[mqudsi]

Your solution is better since there are other critical regressions in zune-jpeg that aren't even resolved yet. Fixing that one just meant I ran into this one non-stop: etemesi254/zune-image#202