Error denosing image: row stride smaller than width * pixel stride

[jonvaldes]

Hello!

I'm getting this error when trying to use oidn-rs: Error denosing image: row stride smaller than width * pixel stride

Looking at the source for oidn, it seems like that can only be triggered if an ImageDesc is created with non-default strides: https://github.com/OpenImageDenoise/oidn/blob/11872d99de4f57786e16ae687945e2b0bc74cb1e/core/image.h#L48

However, neither oidn nor oidn-rs seem to do that... so no idea what's going on.

My repro is simple enough.

main.rs:

fn main() {
    let mut img  = vec!(0.0; 128 * 128 * 3);
    let device = oidn::Device::new();
    oidn::RayTracing::new(&device)
        .image_dimensions(128, 128)
        .filter_in_place(&mut img)
        .expect("Filter config error!");

    if let Err(e) = device.get_error() {
        println!("Error denosing image: {}", e.1);
    }
}

And Cargo.toml:

name = "myproject"
version = "0.1.0"

[dependencies]
oidn = "1.4.1"

Also, I'm using the precompiled binaries from this oidn release https://github.com/OpenImageDenoise/oidn/releases/tag/v1.4.0

[Twinklebear]

Interesting, yeah oidn-rs passes 0 to indicate default stride for the images we pass so I'm not sure why this error is raised. Let me try it out on the example app I've got in this repo as well to see what's going on

[Twinklebear]

@jonvaldes did you get this issue resolved? I just tested out your repro case with OIDN 1.4.0 on my machine and it actually ran without any errors.

[jonvaldes]

Yeah, it seemed to be quite finnicky, and scary. Basically, any change to my executable (even down to adding or removing a dependency in Cargo.toml) would make the issue disappear or show up again. It had symptoms typical of things like memory stomping, or reading of out-of-bounds memory. I wasn't able to track it down, though :(

[davidliljefors]

Same for me on windows, 1.4.1.

[8picoz]

It still happens now for my environment. windows, 1.4.2