search

kosinix / raster

An image processing library for Rust
https://docs.rs/raster/
MIT License
93 stars 13 forks source link

Support for more color encodings and bit depths? #10

Open Enet4 opened 7 years ago

Enet4 commented 7 years ago

This is an interesting project, as it covers image operations not found in any other Rust crate at the moment. Unfortunately, it appears that there is only support for RGBA images. I've had to deal with grayscale images for 16-bit color depth in my work, sometimes even with each pixel being represented by a floating-point number.

Are there any insights for generalizing your data structures and algorithms in the future? Do you consider this feasible?

kosinix commented 7 years ago

I do plan on eventually using floating point for pixels to preserve accuracy during processing. By bit depth do you mean 16 bits/channel or 16-bit color image? The 16 bits/channel issue is limited to what the current rust decoders/encoders crates are capable of (png, gif, jpeg_decoder). For 16-bit color images, there is no plan yet.

Enet4 commented 7 years ago

By bit depth do you mean 16 bits/channel or 16-bit color image?

In my particular case, images may have a single channel of 16 bits/pixel, which is not unusual in medical imaging. Even if current decoders will not provide images with other color depths, making the image data structure more generic shouldn't be out the question, as not only they could be made with custom procedures, but future crates may also keep this project in mind to achieve some level of harmonization.

From my experience with other image processing libraries, the matrix data type in OpenCV fulfills this use case and is very versatile. It's definitely worth having a look. ;)

kosinix commented 7 years ago

Interesting. Can you give me an example use-case on how you would use the matrix data type?

Enet4 commented 7 years ago

The matrix data type would be just an implementation detail. It supports region slicing with a possibly shared image buffer, and the actual value type (per channel per pixel) is generic.

As for my use case, I've been using scipy for performing rotations and translations that preserve the original resolution, and image resizing.

kosinix commented 7 years ago

@Enet4

Right now raster just lumps the rgb values in a 3 dimensional array (kinda, since each elements are struct) rgb = [[[255, 0, 0], [255, 0, 0]], [255, 0, 0], [255, 0, 0]], [255, 0, 0], [255, 0, 0]]]

What you want is something like each channel in their own 2 dimensional array (matrix):

red = [[255,255]. [255, 255]] green = [[0, 0]. [0, 0]] blue = [[0, 0]. [0, 0]]

Is this what you have in mind? I apologize for the very late response, but ive been thinking about refactoring raster lately and your comment comes to mind.

Enet4 commented 7 years ago

Preferably, I would want to have no more channels than the ones I need. With greyscale images, the dimensional order of the image (HWC, CHW, ...) is no longer as relevant. It may also happen that each pixel value may not fit in a single byte. I suppose that a refactor should contemplate images of different kinds, and so with a possibly different number of channels. The image crate covers this well, albeit with not as many image transformation routines.