16-bit and 32-bit (per channel) Colours and Images


#1

Is there any plan to support higher bit-depth Colours and Images in Juce in the future?

I’m doing some image processing and have a need to keep track of colors at a higher precision, so I’m implimenting my own floating point color class.

I’ll also need to read and write images with greater precision, so I’m looking at using the OpenEXR libraries. (16-bit floating point is a pretty good trade-off between precision and file size).

I’m just curious if this is something that other people have already implimented or if it is something that is eventually planned for Juce.


#2

It wasn’t something on my agenda really, and would involve considerable changes to the codebase to make it work. Would be nice to do one day though!


#3

I work with int16 greyscale[1] images, so I need to do all of my own windowing and such.

I’m not sure what your situation is, but for medical imaging, it’s considered perfectly acceptable to window before doing scaling or translation at view time.

Internally, IE for raw image processing, the rules change, but then, very often memory concerns require that images be sub-sampled/depth reduced, and/or cropped to a specific ROI before doing serious number cruching anyway.

Despite the distinct lack of overlap between int16 greyscale, and uint32 ARGB, I’m still able to do alomst everything I need without too much reinventing of the wheel.

[1] and if it was actually int16, and not every possible bit depth between 6 and 15, and uint/int liberally dotted around too, my life would be so much easier. :slight_smile:


#4