ripytide

Thanks for the insight, I'd imagine if there were multiple types of conversions we could make a trait per conversion type such as: `GpuColorConvert`, `ViaXyzColorConvert`, `SimdColorConvert` and similar though to...

I think I've got an idea for both type-level pixel conversion and enum-value-based pixel conversion in a single interface: ```rust trait HasColorSpace { type ColorSpace; } trait IntoXyz: HasColorSpace {...

That's a good point, there's also the possible optimization for large enum-based color-space conversions when doing bulk amounts of the same run-time color space conversion that you don't want to...

Great points. Perhaps then the conversion traits should work on an image-level rather than a pixel-level which would allow using the full `[Rgb]` slice context which should allow using SIMD,...

Relevant to this issue might be my most recent design attempt: https://github.com/ripytide/pixmeta and some discussion on it: https://github.com/kornelski/rust-rgb/issues/142

Interesting, how would you expect this to work? Perhaps a function taking a normal rectangular image and then giving it a background color or 0-opacity around the corners at a...

Yep that sounds reasonable, so something like: ```rust //copied from kurbo pub struct RoundedRectRadii { pub top_left: f64, pub top_right: f64, pub bottom_right: f64, pub bottom_left: f64, } pub fn...

Sounds good to me, there are four issues labelled with `blocks-release` likely needing to be addressed before the next release: #667, #664, #661, #653. #661 and #667 may need more...

The workaround of using the maximum value is the correct call in my opinion. I say this after trying out the `RangeBounds` idea you mentioned a couple of years ago,...

I think one of the reasons it might not have been spotted is because it is an associated method to the `Kernel` struct which is rather inconsistent as nearly all...