Does and should this library support images with subpixel types that are signed integers?

[RunDevelopment]

I've been thinking about this recently, while looking at Primitive, Pixel and functions consuming them.

A lot of functions just don't handle signed ints correctly, and I don't blame them. Random example: brighten:

let e = pixel.map_with_alpha(
    |b| {
        let c: i32 = NumCast::from(b).unwrap();
        let d = clamp(c + value, 0, max);

        NumCast::from(d).unwrap()
    },
    |alpha| alpha,
);

See that 0 in clamp? brigthen assumes that 0 is the minimum value. Which is true for floating point types and unsigned integer types, but not signed integer types. Just from looking through them briefly, it seems like all color ops make that assumption.

Basically everything in src/color.rs also makes that assumption. For example:

impl<T: Primitive> Invert for Luma<T> {
    fn invert(&mut self) {
        let l = self.0;
        let max = T::DEFAULT_MAX_VALUE;
        let l1 = max - l[0];
        *self = Luma([l1]);
    }
}

Note that the subtraction can overflow for signed types. E.g. for i8, it's possible to calculate 127 - (-13). This either panics in debug mode or silently produces wrong results in release mode.

I want to stress that these are random examples. I didn't look for hours until I found something. Examples like this are extremely easy to find, because the whole codebase seems to collectively ignore signed integer types. I too have written code with issues like this, because I didn't even consider signed int types until I found that they implement Primitive.

So what level of support is there for signed integer types as subpixel types? Should they be supported? If so, is the amount of work required to support them properly worth the effort?