Use case: decode Radiance HDR image, upload into video memory

Radiance HDR image format uses 4-byte shared exponent representation. Decoding it into a vector of RGB<f32> pixels, then recompressing it into, say, RGB9_E5_EXT requires 3 times more memory than really needed, thanks to the Pixel trait.

EDIT: I found out that implementing Pixel trait is optional, but still, refactoring Pixel trait seems reasonable.

Pixel trait is responsible for

1. enforcing storage format (from_slice, channels methods constraint underlying representation to [Subpixel; n_channels])
2. providing color conversions
3. providing various color operations (notice that invert() doesn't make sense for shared exponent format)
4. providing mutable access to underlying pixel storage.

It is too much for a single trait.

What do you think about splitting Pixel into ColorConvert, ChannelArrayStorage, ColorOperations?

ImageBuffer becomes

impl<RawPixel, Container> ImageBuffer<RawPixel, Container> 
where Container: Deref<Target=[RawPixel]> { ...

RawPixel type will be implementing ColorConvert and other traits as appropriate.

Pixel trait will be defined for RawPixel where RawPixel: ColorConvert + ChannelArrayStorage + ColorOperations to maintain backward compatibility.

EDIT: ImageBuffer should be left as is, Deref trait exposes underlying storage.

Start by locating the Pixel trait, ImageBuffer, and the Radiance HDR decoding path mentioned in the issue. Review how storage, color conversion, color operations, and mutable access are currently coupled; done means a decided trait design that supports shared-exponent pixels while preserving the stated backward-compatibility requirements.