Image: Add support a floating point channels

[usagi]

In the current, image::open and image::load family only support u8 channel image ( converting if open a data of the other channel type ). But, imaging apps programmers need more channel formats. I think, these programmers will be satisfied for many situations if support a f32 / f64 channel types.

[fintelia]

Which formats in particular are you hoping to have support for?

[usagi]

@fintelia I hopes ...

1. RGBA/f32 ( and Gray/f32 ); Sometimes, It use to HDR graphics and many calculations for high precision graphics.
2. Gray/u16; Sometimes, It use to height( or something parameter )-field data exchanging. But in current image, it be degraded to 8 bpp from 16 bpp.
   
   
   
   • note: It's not a floating point, but one of a similar hopes.
   
   

[fintelia]

1. I believe that the hdr module might be what you are looking for.
2. My understanding is that you can load images with higher bit depths by using the underlying decoders directly.

If you have a specific image you are hoping to load, we might be able to direct you better or figure out what features would need to be added.

[pix64]

I believe Image should support floating point as well. This is an image
library not just a image file encoder/decoder.

On Mon, Jul 30, 2018, 3:52 PM Jonathan Behrens [e-mail]
wrote:

>

1. I believe that the hdr module
   https://docs.rs/image/0.19.0/image/hdr/index.html might be what you
   are looking for.
2. My understanding is that you can load images with higher bit depths
   by using the underlying decoders directly.

If you have a specific image you are hoping to load, we might be able to
direct you better or figure out what features would need to be added.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PistonDevelopers/image/issues/795#issuecomment-408988608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEZnSbvTn_oKSPWld5zP7pb65-UFEYHMks5uL2P-gaJpZM4Vlijd
.

[HeroicKatora]

@pix64 It does support floating point images. In particular, the following would be valid:

use image::{ImageBuffer, Rgb, imageops};
let image: ImageBuffer<Rgb<f64>, _> = ImageBuffer::new(100, 100);
// some initialization code
let blurred = imageops::blur(&image, 10.);

It is really mostly the decoder abstraction and the related dynimage which do not support the complete breadth of colour types equally well.

[usagi]

Hmm.. I want to use high-level APIs such as image::open and DynamicImage with non-u8 element types.

For example, I want to get the u16 version of the DynamicImage if image::open with U16 type PNG streams.

And if I can wish more, I want to open with specific color types and element types.

For example, image::open( "rgb8.png", RGBA_F32 ) then get a RGBA_F32 element type version of DynamicImage with converting to RGBA_F32 from RGB_U8, image::open( "gray16.png", SAME_TO_SOURCE ) then get a GRAY_U16 element type version of DynamicImage without converting.

Of course, I can use many of low-level APIs and specific image format libraries for the needs but it is very messy. I think the needs is fit to purpose of the image, then I proposed this issue.

[HeroicKatora]

Instead of selecting the colour type in open, converting the DynamicImage to the respective one should also be possible as soon as it supports the other colour types. Something similar to DynamicImage::to_luma but instead [DynamicImage::to_colour_type(ColorType)] would be my proposed idea for this. Then the code for reading into a specific colour type would be:

let rgba_f32 = image::open("rgb8.png")?
    .to_color(ColorType::RGBF32)?;

This needs two changes: Introducing the additional color types and extending DynamicImage to support them. And additionally adding the conversion functions to DynamicImage which should also be available to ImageBuffer in some strictly typed fashion.

Somewhat unfortunately, this would break the interface of DynamicImage::raw_pixels.

[dobkeratops]

+1000
fp32 and fp16 channels would be great to have. FP16 is of increasing importance because newer machines are more support for it for AI. (I keep on about this in the rust community aswell.. the language should get ahead of the curve with intrinsic FP16 support, see IoT niche)