Thread panics on EXR containing NAN
Some EXR files might contain NaNs, e.g., AllHalfValues.exr. Calling to_rgba8 on such images causes a panic:
thread 'main' panicked at image-0.25.1\src\color.rs:435:30:
called `Option::unwrap()` on a `None` value
Shorter repro:
let img = Rgba32FImage::from_raw(1, 1, vec![1.0 / 0.]).expect("create nan image");
DynamicImage::ImageRgba32F(img).to_rgba8();
According to my research, there is no defined operation for how to handle NaN when converting to another format. I can open a PR against my branch if the below behavior is agreed upon.
Firefox render of the linked sample image
PNG conversion with clamp applied, from the fixed branch
Num traits does not support Positive infinites, Negative infinites also, only subnormal numbers are supported. Usually most hardware flushes NaNs towards negative infinity ( zero for unsigned, max possible negative value for signed ).
Num traits does not support Positive infinites, Negative infinites also, only subnormal numbers are supported. Usually most hardware flushes NaNs towards negative infinity ( zero for unsigned, max possible negative value for signed ).
Well, in this case the image parses just fine when filtering out NaNs, all other funny values appear to be handled (as this image contains every possible bitrepr)
Not really, here two immediate fails
let img1 = Rgba32FImage::from_raw(1, 1, vec![f32::INFINITY]).expect("create +inf image");
DynamicImage::ImageRgba32F(img1).to_rgba8();
let img2 = Rgba32FImage::from_raw(1, 1, vec![f32::NEG_INFINITY]).expect("create -inf image");
DynamicImage::ImageRgba32F(img2).to_rgba8();
let img2 = Rgba32FImage::from_raw(1, 1, vec![f32::NEG_INFINITY]).expect("create -inf image"); DynamicImage::ImageRgba32F(img2).to_rgba8();
~~I believe this is a tangential issue, as this doesnt work either:~~
let img2 = Rgba32FImage::from_raw(1, 1, vec![0.0]).expect("create any image");
DynamicImage::ImageRgba32F(img2).to_rgba8();
~~(fails on the expect)~~ see below comment
Specifically, image_buffer_len yields Some(4) with input 1,1.
The shorter repro was simply bugged as it did not take the 4 color channels into account.
let img2 = Rgba32FImage::from_raw(1,1, vec![f32::NEG_INFINITY, f32::INFINITY, f32::NAN, f32::MAX]).expect("create funny image");
dbg!(DynamicImage::ImageRgba32F(img2).to_rgba8());
runs perfectly fine
[src/main.rs:9:5] DynamicImage::ImageRgba32F(img2).to_rgba8() = ImageBuffer {
width: 1,
height: 1,
_phantom: PhantomData<image::color::Rgba<u8>>,
data: [
0,
255,
1,
255,
],
}
Fixed by #2381