Bump `image` to `0.24`?

[AntoniosBarotsis]

I'm not sure how hard this would be or what changes need to be made (I think I read somewhere that the image crate introduced some breaking changes somewhere in that version?), just making sure there's a reason for this :)

[piderman314]

Well it seems to compile just fine, but for some reason one of the tests fails. I'll have to have a look at it.

[AntoniosBarotsis]

Nice! 0.24 seems to have some minor performance improvements over 0.23 for some stuff I was working on so that's a plus for the crate!

[AntoniosBarotsis]

I took a short look at the test, not sure if you already found out about this or if it even helps but it seems like the vector of Candidates is slightly different between the 2 versions.

# 0.23.14
[src\detect\linescan.rs:126] &candidates = [
    QRFinderPosition {
        location: Point {
            x: 182.0,
            y: 161.0,
        },
        module_size: 15.5,
        last_module_size: 0.0,
    },
    QRFinderPosition {
        location: Point {
            x: 386.5,
            y: 157.0,
        },
        module_size: 14.678571428571429,
        last_module_size: 0.0,
    },
    QRFinderPosition {
        location: Point {
            x: 184.5,
            y: 370.0,
        },
        module_size: 14.25,
        last_module_size: 0.0,
    },
]

# 0.24.0
[src\detect\linescan.rs:126] &candidates = [
    QRFinderPosition {
        location: Point {
            x: 182.0,
            y: 161.0,
        },
        module_size: 15.5,
        last_module_size: 0.0,
    },
    QRFinderPosition {
        location: Point {
            x: 386.5,
            y: 155.0,
        },
        module_size: 14.892857142857142,
        last_module_size: 0.0,
    },
    QRFinderPosition {
        location: Point {
            x: 184.5,
            y: 370.0,
        },
        module_size: 14.25,
        last_module_size: 0.0,
    },
]

The second candidate's y position (and the modulo) is slightly different (157 vs 155).

After some dbg printing, it seems that this function generates different results between the 2 versions.

[piderman314]

It seems there are some very minute changes in the way the grayscale images are handled within the image create between versions 0.23 and 0.24. In most cases it causes no issue except for this one test that fails which was already borderline unreadable. Still, the algorithm managed to correctly read the QR. To be honest I don't really have time to take a deep dive into the changes in the image crate to figure out where things go wrong.

I'll think about updating Cargo.toml to accept both 0.23 and 0.24 and disabling this one test. You can then use the newer image crate while accepting a slight regression in the ability to read QRs.

[pieterdd]

A screenshotting crate I'm using depends on image 0.24.x, while bardecoder seems to use 0.23.14 in my environment. This seems to have triggered the following error:

struct `image::buffer::ImageBufferand structImageBuffer` have similar names, but are actually distinct types_?

If the one test with the borderline unreadable QR code is disabled, are there any remaining impediments to a 0.24 upgrade?

[piderman314]

Apologies, this issue slipped by mind during the holidays. Version 0.4.1 of bardecoder should now allow usage of version 0.24 of the image crate.

[pieterdd]

Awesome, thank you! This fixed the error I saw.