Component conversion

[andrewbaxter]

I ran into some issues while trying to convert from srgb to oklch.

My code is

        println!("c-h-border {:?}", Oklch::from_color(palette::Srgb::new(0xbf, 0xbf, 0xbf)));

I get a slew of missing trait errors like

error[E0277]: the trait bound `{integer}: Cbrt` is not satisfied
  --> src/main.rs:33:55
   |
33 |         println!("c-h-border {:?}", Oklch::from_color(palette::Srgb::new(0xbf, 0xbf, 0xbf)));
   |                                     ----------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Cbrt` is not implemented for `{integer}`
   |                                     |
   |                                     required by a bound introduced by this call
   |
   = help: the following other types implement trait `Cbrt`:
             f32
             f64
   = note: required for `Oklab<{integer}>` to implement `FromColorUnclamped<palette::rgb::Rgb<Srgb, {integer}>>`
   = note: 1 redundant requirement hidden
   = note: required for `Oklch<{integer}>` to implement `FromColorUnclamped<palette::rgb::Rgb<Srgb, {integer}>>`
   = note: required for `Oklch<{integer}>` to implement `FromColor<palette::rgb::Rgb<Srgb, {integer}>>`

-> Powf Hypot Trigonometry RealAngle.

I'm coming from html, so I was using the hex trick, but I think this leaves me with u8 components. My guess is (haven't tried this out yet) I need to convert from u8 to f32 or something.

I don't see any documentation on component conversions rather than color space conversions, but maybe this error is unexpected. It looks like there's a potential solution at #267 (into_format) - if that's right, as an additional note the name into_format might not be clear (it's not what I'd expect when trying to convert components). I found that via #268 - the discussion title doesn't suggest it's relevant but the issue is clearer.

Thanks for the awesome library!

[andrewbaxter]

Ah, I also needed to make sure they were unsigned, ended up with these monstrous hex literals 0xbfu8 etc.

error[E0277]: the trait bound `i32: IntoStimulus<f32>` is not satisfied
   --> src/main.rs:37:94
    |
37  |         println!("c-background {:?}", Oklch::from_color(palette::Srgb::new(0xf8, 0xf8, 0xf8).into_format::<f32>()));
    |                                                                                              ^^^^^^^^^^^ the trait `IntoStimulus<f32>` is not implemented for `i32`
    |
    = help: the following other types implement trait `IntoStimulus<T>`:
              <f32 as IntoStimulus<f64>>
              <f32 as IntoStimulus<u128>>
              <f32 as IntoStimulus<u16>>
              <f32 as IntoStimulus<u32>>
              <f32 as IntoStimulus<u64>>
              <f32 as IntoStimulus<u8>>
              <f64 as IntoStimulus<f32>>
              <f64 as IntoStimulus<u128>>
            and 34 others
    = note: required for `f32` to implement `FromStimulus<i32>`

[Ogeon]

Ah, yes, there's currently not an automatic conversion there, but you are also hitting another quirk with the language. It assumes i32 when it's ambiguous, which it would be in this case. i32 could theoretically work in some cases. You only need to annotate the first number, though. The rest will be inferred from that: Srgb::new(0xbfu8, 0xbf, 0xbf). Or mention it as a type parameter to Srgb: Srgb::<u8>::new(0xbf, 0xbf, 0xbf). You can also use a full u32 and the from function: Srgb::from(0xbfbfbf) (may need the u32 suffix).

I think it should be possible to add automatic format conversion but it's going to break type inference a bit, so that has to wait for version 0.8. For now, I would usually recommend using the .into_linear::<f32>() function when it can't auto-convert:

println!("c-h-border {:?}", Oklch::from_color(palette::Srgb::new(0xbfu8, 0xbf, 0xbf).into_linear::<f32>())); // The ::<f32> bit may be unnecessary

It uses a u8 -> f32 lookup table that may make it a bit faster if you are working with a lot of data, like in a full image, but not necessarily in your case. There's probably some documentation work that need to be done to make it the more prominent option, but automatic would be even nicer.

[andrewbaxter]

Oh good to know, thanks!

What about having non-generic aliases? Like OklchF32::from_color(SrgbU8::new(1, 1, 1)).

(edit: I tried

            let x = <Oklch<f32>>::from_color(<Srgb<u8>>::new(1, 1, 1));

and got

error[E0277]: the trait bound `Oklch: FromColorUnclamped<palette::rgb::Rgb<Srgb, u8>>` is not satisfied
   --> src/main.rs:188:46
    |
188 |             let x = <Oklch<f32>>::from_color(<Srgb<u8>>::new(1, 1, 1));
    |                     ------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `FromColorUnclamped<palette::rgb::Rgb<Srgb, u8>>` is not implemented for `Oklch`
    |                     |
    |                     required by a bound introduced by this call
    |
    = help: the following other types implement trait `FromColorUnclamped<T>`:
              <Oklch<T> as FromColorUnclamped<Alpha<_C, _A>>>
              <Oklch<T> as FromColorUnclamped<Hsl<_S, T>>>
              <Oklch<T> as FromColorUnclamped<Hsluv<D65, T>>>
              <Oklch<T> as FromColorUnclamped<Hsv<_S, T>>>
              <Oklch<T> as FromColorUnclamped<Hwb<_S, T>>>
              <Oklch<T> as FromColorUnclamped<Lab<D65, T>>>
              <Oklch<T> as FromColorUnclamped<Lch<D65, T>>>
              <Oklch<T> as FromColorUnclamped<Lchuv<D65, T>>>
            and 10 others
    = note: required for `Oklch` to implement `FromColor<palette::rgb::Rgb<Srgb, u8>>`

so not quite I guess)

[Ogeon]

That would be the automatic conversion that's missing. The type ambiguity is gone but it can still only convert when the input and output component types are the same as it's defined right now. That restriction makes sense from a more generic perspective (where in the conversion chain should we switch type?), but specifically with RGB, it's much easier to make an educated guess.

What I mean with the "conversion chain" is that a conversion from color type A to color type B usually involves multiple steps. So going from sRGB8 to Oklch would be Srgb<u8> -> LinSrgb<f32> -> Oklab<f32> -> Oklch<f32>. There can only be one obvious path, so making it too generic would sen the compiler into a type inference crisis: Srgb<A> -> LinSrgb<B> -> Oklab<C> -> Oklch<D>. It wouldn't be able to know if any of A, B, C and D should be different or the same. Only what A and D (u8 and f32) would be from the context you give it. That's why the current assumption is that they all should be the same. But for RGB, we can use that .into_linear::<T>() function and decide that T should be the same as the output component type. That way, it could in theory (I have only briefly tested it) allow that to be inferred for sRGB and some other formats. That would be a reasonable assumption, work well for most people, and use an optimal path by default.

That said, your suggestion with more type aliases could also help to give more useful error messages. You get a bit of that from the default types (just writing Oklch is already the same as Oklch<f32> in many cases), but they mostly have an effect on the left hand of the =, so I think that if you would write let x: Oklch = Srgb::<u8>::new(1, 1, 1).into_linear().into_color();, it would infer everything but the u8. The downside with more aliases is that there's going to be more stuff in the documentation. It can be done for a select number of common types, though, so specifically SrgbU8 would at least solve the ambiguous input. Or a new_u8 function. Or both.