https://bugs.documentfoundation.org/show_bug.cgi?id=114719
--- Comment #51 from V Stuart Foote <vstuart.fo...@utsa.edu> ---
(In reply to Flora Canou from comment #50)
> After checking this color palette I find it dissatisfactory for its
> inaccuracy in some extreme cases. In particular, when it comes to dark
> colors:
>
> <draw:color draw:name="Dark Blue 4" draw:color="#362413"/>
> <draw:color draw:name="Dark Teal 4" draw:color="#302709"/>
>
> If I interpret the numbers correctly (like R36, G24, B13), this is not blue
> but is an orange/brown color.
>
> The problem is probably rooted in this RYB color space. The space is
> generated by something like a translation from an RGB color space, where
> every color is mapped in a certain way with a little orange in order to
> obtain yellow as the primary color. One of the consequences is the general
> decrease of saturation in blue--green colors. Actually the gray scale turns
> orange too (Clearly 7f7f7f becomes 9c744a by the transformation in
> https://bahamas10.github.io/ryb/). Since turning the brightness off base
> naturally reduces saturation, in extreme cases the blue itself is overriden
> by the translation of the space.
>
> With scientific minds, modern standard color spaces should be either RGB
> (for screen) or CMYK (for print). A reduced-saturation version of them can
> be more favorable. Why do we bother to use an RYB instead and get all the
> messes?
True, see attachment 139004 for where the 80% shade ends up a bit smeared--but
then that is exactly the outcome of doing additive colors isn't it? The model
holds nicely. And simply put, majority of our LibreOffice casual users prefer a
RYB for additive color design for their default standard palette.
Using a Tensor based algorithm to generate colors may have flaws--but its use
offers consistency--so if rather than the 80% shade (i.e. 204/255 on the white
black diagonal), a user could generate a set of 65% shades that might have a
bit more RGB accuracy to parent hue. But the reality is we can not support CMYK
nor HSL color models in the LibreOffice document canvas--so an algorithmicly
generated RYB color palette is just as viable.
And, we could tweak the dark end of the gradient 70% rather than 80%,
lightening the colors and aligning them more with the hue--beyond that
deviating from the algorithm's generated values is really not justified.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
