With ColorType::Luma32F being supported, we can finally have 32-bit single-channel (dynamic) images. However, our exr codec does not support reading and writing such images.
I.e. the following code fails.
let image = ImageBuffer::from_fn(16, 16, |x, y| Luma([(x * y) as f32 / 225.0]));
image.save("test.exr").unwrap();Description
Add support for both reading and writing single-channel luma exr images. (May be separate PRs.)
The OpenExr specification recommends using Y as the channel name for luma. The encoder should create an image with only a Y channel. The decoder should look for a Y channel and use it. Since exr supports any number and combinations of channels (e.g. R+G+B+Y is possible), the decoder should prefer RGB/RGBA over pure luma.
The decoder implementation should be tested using a .exr file containing a Y channel. The encoder implementation should be tested using a roundtrip (=generate some image, encode, decode, compare decoded image to starting image).
Luma + Alpha encoding and decoding should not be a goal right now.
With
ColorType::Luma32Fbeing supported, we can finally have 32-bit single-channel (dynamic) images. However, our exr codec does not support reading and writing such images.I.e. the following code fails.
Description
Add support for both reading and writing single-channel luma exr images. (May be separate PRs.)
The OpenExr specification recommends using
Yas the channel name for luma. The encoder should create an image with only aYchannel. The decoder should look for aYchannel and use it. Since exr supports any number and combinations of channels (e.g. R+G+B+Y is possible), the decoder should prefer RGB/RGBA over pure luma.The decoder implementation should be tested using a
.exrfile containing aYchannel. The encoder implementation should be tested using a roundtrip (=generate some image, encode, decode, compare decoded image to starting image).Luma + Alpha encoding and decoding should not be a goal right now.