Bug 114719 - New RYB based standard palette: cleanup assigned RGB values and color names (result comment 44)
Summary: New RYB based standard palette: cleanup assigned RGB values and color names (...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0
Keywords:
Depends on:
Blocks: Color-Palettes 87538
  Show dependency treegraph
 
Reported: 2017-12-27 20:23 UTC by Mihkel Tõnnov
Modified: 2018-07-21 15:37 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
swapped columns (20.03 KB, image/png)
2017-12-29 15:45 UTC, Yousuf Philips (jay) (retired)
Details
RYB color palette generated with Gossett & Chen, and correctly assigning RYB Primary, RYB Secondary and traditional Tertiary names (8.91 KB, text/plain)
2017-12-31 04:25 UTC, V Stuart Foote
Details
original RYB palette used in new standard.soc, with color names added (37.76 KB, image/png)
2017-12-31 07:18 UTC, V Stuart Foote
Details
original RYB palette with modern names (70.37 KB, image/png)
2017-12-31 14:50 UTC, V Stuart Foote
Details
stuart palette vs current palette (24.98 KB, image/png)
2018-01-01 01:06 UTC, Yousuf Philips (jay) (retired)
Details
generated RYB color palette with adjusted brighness and "modern" tertiary color names (8.81 KB, text/plain)
2018-01-01 17:16 UTC, V Stuart Foote
Details
screenclip current standard palette vs a generated RYB palette (attachment 138791) (158.14 KB, image/png)
2018-01-01 18:31 UTC, V Stuart Foote
Details
generated RYB color palette (8.80 KB, text/plain)
2018-01-02 22:19 UTC, V Stuart Foote
Details
generated RYB color palette (rev 2) (23.78 KB, image/png)
2018-01-02 22:27 UTC, V Stuart Foote
Details
generated RYB color palette (rev3) Heiko's (21.73 KB, image/png)
2018-01-03 19:04 UTC, V Stuart Foote
Details
generated RYB color palette (rev 3) standard.soc (16.58 KB, text/plain)
2018-01-03 19:06 UTC, V Stuart Foote
Details
10 row version of RYB palette (23.84 KB, image/png)
2018-01-03 20:05 UTC, V Stuart Foote
Details
10 row standard.soc +200 > -180, 5 light 3 dark (16.57 KB, text/plain)
2018-01-03 20:13 UTC, V Stuart Foote
Details
ODT table with the rev3 palette (16.88 KB, application/vnd.oasis.opendocument.text)
2018-01-04 01:21 UTC, V Stuart Foote
Details
ODT table with the rev3 palette (corrected Dark Lime 2 cell) (16.85 KB, application/vnd.oasis.opendocument.text)
2018-01-04 07:20 UTC, V Stuart Foote
Details
10 row standard.soc +200 > -160 (rev4) (19.66 KB, text/plain)
2018-01-04 17:30 UTC, V Stuart Foote
Details
ODT with table showing rev4 palette, 5 light, 3 dark and base RYB (17.17 KB, application/vnd.oasis.opendocument.text)
2018-01-04 17:32 UTC, V Stuart Foote
Details
sample with the rev4 palette (45.33 KB, image/png)
2018-01-09 13:06 UTC, V Stuart Foote
Details
sample with rev4 palette (58.95 KB, image/png)
2018-01-09 14:21 UTC, V Stuart Foote
Details
ODT with table showing rev4 palette, 5 light, 3 dark and base RYB (19.21 KB, application/vnd.oasis.opendocument.text)
2018-01-09 14:23 UTC, V Stuart Foote
Details
rev5 -- standard.soc - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added) (25.87 KB, text/plain)
2018-01-10 03:59 UTC, V Stuart Foote
Details
sample with rev5 palette (72.93 KB, image/png)
2018-01-10 04:01 UTC, V Stuart Foote
Details
ODT with table showing rev5 palette -- tints and shades of hues (18.41 KB, application/vnd.oasis.opendocument.text)
2018-01-10 04:02 UTC, V Stuart Foote
Details
standard.soc (rev5) - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added) (25.96 KB, text/plain)
2018-01-10 04:57 UTC, V Stuart Foote
Details
color picker palette Standard & Tonal and a RBG palette using Canou-Zheng Improved HCI (76.97 KB, image/png)
2018-07-21 15:37 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mihkel Tõnnov 2017-12-27 20:23:57 UTC
The names of "Violet" and "Purple" on the new "standard" colour palette seem counter-intuitive. Admittedly there's a lot of confusion regarding these two terms (at least when not speaking of electromagnetic spectrum), but most sources that do distinguish them, seem to agree that purple is closer to red and violet is closer to blue. (We can ignore violet being a "real colour" at one end of the visible spectrum, since on RGB colourspace it's not.)

Wikipedia: "In the traditional color wheel used by painters, violet and purple are both placed between red and blue. Purple occupies the space closer to red, between crimson and violet. Violet is closer to blue, and usually less intense and bright than purple." (https://en.wikipedia.org/wiki/Purple#Purple_vs._violet)

See also https://en.wikipedia.org/wiki/Line_of_purples, https://jakubmarian.com/difference-between-violet-and-purple/, https://www.quora.com/What-is-the-difference-between-violet-and-purple

Note that the colours themselves in the palette are fine, only their names should be switched. Applies also to "Light/Dark Violet/Purple".
Comment 1 Yousuf Philips (jay) (retired) 2017-12-27 21:40:22 UTC
So the RYB color wheel[1] on wikipedia has violet as the secondary color between red and blue, while other references have purple as the secondary color[2][3][4].

Stuart, Heiko, Adolfo: what is your take on this.

[1] https://simple.wikipedia.org/wiki/Color_wheel#RYB_color_wheel
[2] http://visualfocus.org/wp-content/uploads/2015/08/Ch5-28-colorwheel-Reference-S-03.jpg
[3] https://i.pinimg.com/736x/01/40/5e/01405e89866555b95db805967707415f.jpg
[4] http://web.archive.org/web/20170425072744/http://color-wheel-artist.com/basic-color-wheel.html
Comment 2 Mihkel Tõnnov 2017-12-27 22:05:59 UTC
Another RYB colour wheel that shows both purple (between red and blue) and violet (between purple and blue): https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star-en_(tertiary_names).svg (the "magenta" there is rather misnamed, though)
Comment 3 Heiko Tietze 2017-12-27 22:58:59 UTC
After reading through the references I agree with Mihkel to exchange the color names Purple and Violet.
Comment 4 V Stuart Foote 2017-12-28 20:01:09 UTC
(In reply to Heiko Tietze from comment #3)
> After reading through the references I agree with Mihkel to exchange the
> color names Purple and Violet.

Sorry, as noted the actual colors are fine. What is labeled as Violet is Violet, what is labeled as Purple is Purple.

So we would be "swapping" their column placement on the 12 col x 10 row matrix.
Comment 5 Mihkel Tõnnov 2017-12-28 20:17:30 UTC
(In reply to V Stuart Foote from comment #4)
> What is labeled as Violet is Violet, what is labeled as Purple is Purple.

What is labelled as Violet should be labelled as Purple, and what is labelled Purple should be labelled Violet.
Comment 6 Yousuf Philips (jay) (retired) 2017-12-29 15:45:10 UTC
Created attachment 138734 [details]
swapped columns

(In reply to Mihkel Tõnnov from comment #2)
> Another RYB colour wheel that shows both purple (between red and blue) and
> violet (between purple and blue):
> https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star-
> en_(tertiary_names).svg (the "magenta" there is rather misnamed, though)

The image caption says "RGB color wheel". :D

(In reply to V Stuart Foote from comment #4)
> Sorry, as noted the actual colors are fine. What is labeled as Violet is
> Violet, what is labeled as Purple is Purple.

Noted by whom, as Mihkel is saying the labels should be swapped and i believe they likely shouldnt be based on the many color wheels in comment 1.

> So we would be "swapping" their column placement on the 12 col x 10 row
> matrix.

Swapping the columns isnt the correct solution as that would break the color gradient flow.
Comment 7 Mihkel Tõnnov 2017-12-29 22:18:40 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> Created attachment 138734 [details]
> swapped columns
> 
> (In reply to Mihkel Tõnnov from comment #2)
> > Another RYB colour wheel that shows both purple (between red and blue) and
> > violet (between purple and blue):
> > https://en.wikipedia.org/wiki/Color_wheel#/media/File:Color_star-
> > en_(tertiary_names).svg (the "magenta" there is rather misnamed, though)
> 
> The image caption says "RGB color wheel". :D

Err, no it doesn't?! And even if its caption *would* say it's RGB (which, again, it doesn't), then the image itself is clearly RYB (as red, yellow, blue are the primary colours there, and not red, green, blue).

> (In reply to V Stuart Foote from comment #4)
> > Sorry, as noted the actual colors are fine. What is labeled as Violet is
> > Violet, what is labeled as Purple is Purple.
> 
> Noted by whom, as Mihkel is saying the labels should be swapped and i
> believe they likely shouldnt be based on the many color wheels in comment 1.

I frankly didn't expect this to be such a controversial topic. I don't challenge the position of both purple and violet between red and blue (when not talking about "real colour" violet, which is beyond the blue spectre). It's just that violet is "bluer" than purple by most definitions.

For reference, "purple":
"1. any color having components of both red and blue, such as lavender, especially one deep in tone. /.../ 6. deep red; crimson." [1]
"b (1) : tyrian purple (2) : any of various colors that fall about midway between red and blue in hue" [2]
"a dark reddish-blue colour" [3]
"1. A colour intermediate between red and blue. /.../ 2. A crimson dye" [4]

[1] http://www.dictionary.com/browse/purple?s=t
[2] https://www.merriam-webster.com/dictionary/purple
[3] https://dictionary.cambridge.org/dictionary/english/purple
[4] https://en.oxforddictionaries.com/definition/purple

And "violet":
"5. reddish-blue, a color at the opposite end of the visible spectrum from red, an effect of light with a wavelength between 400 and 450 nm." [5]
"2 : any of a group of colors of reddish-blue hue, low lightness, and medium saturation" [6]
"a bluish-purple colour" [7]
"2. A bluish-purple colour seen at the end of the spectrum opposite red." [8]

[5] http://www.dictionary.com/browse/violet?s=t
[6] https://www.merriam-webster.com/dictionary/violet
[7] https://dictionary.cambridge.org/dictionary/english/violet
[8] https://en.oxforddictionaries.com/definition/violet

Notable parts:
* both purple and violet are "reddish-blue" (which they are; however such definition leaves much playroom and doesn't specify their position relative to each other)
* purple is "about midway between red and blue"
* purple has also a sense of crimson
* violet is "bluish-purple" - meaning it's in the bluer part of aforementioned "reddish-blue" space.

As far as RGB/RYB colour model is concerned, we can ignore the statement that violet is "at the end of the spectrum opposite red" - although in a way it does make it (much) closer (physically speaking) to blue than it is to red.

I hope this explanation helped :)

> > So we would be "swapping" their column placement on the 12 col x 10 row
> > matrix.
> 
> Swapping the columns isnt the correct solution as that would break the color
> gradient flow.

Please no-one swap the columns! :)
Comment 8 V Stuart Foote 2017-12-30 00:12:51 UTC
Purple and Violet are kind of a mess, as Jay shows reversing the columns would not work--we've got a really bad base color for both in the standard.soc--but then most of the base colors are off Hue. We are bouncing all over the hues of the RGB additive color wheel. How theoretically correct should the standard.soc be? 

None the less, we've set Purple to HSV (268°, 69%, 57%) and Violet to HSV (310°, 79%, 64%). The RGB additive color theory suggests we have this wrong if we accept the Wikipedia definitions:

Purple: RGB #800080 (128, 0, 128), HSV (300°, 100%, 50%)

Violet: RGB #7F00FF (128, 0, 255), HSV (270°, 100%, 100%)


Woring with RGB HSV/B -- the Violet(s) should be out the 270° radial, and the Purple(s) out the 300° "Magenta" radial. And build a 

We do pickup the 270° color hue for Violet in the tonal.soc--matching theory at the 68% saturation, but interestingly in the html.soc the X11/HTML/SVG Violet is out the 300° radial with most of the "Purple, violet, and magenta colors".
Comment 9 Heiko Tietze 2017-12-30 09:05:52 UTC
Sorry, but don't we heavily bikeshed here? No one challenged the color palette itself, the question just boils down whether purple is more of a red color or rather blue. In my opinion Mihkel is right with red, he gave a lot of references to proof this. German combines the two terms to "Purpurrot" (purple red), I never heard about "violet red". 

(And I've not seen a good argument in this thread against swapping names.)
Comment 10 Yousuf Philips (jay) (retired) 2017-12-30 14:11:26 UTC
(In reply to Mihkel Tõnnov from comment #7)
> > The image caption says "RGB color wheel". :D
> 
> Err, no it doesn't?! And even if its caption *would* say it's RGB (which,
> again, it doesn't), then the image itself is clearly RYB (as red, yellow,
> blue are the primary colours there, and not red, green, blue).

Sorry that was my mistake, as i ended up looking at this[1] after going through the page. :D

[1] https://en.wikipedia.org/wiki/Color_wheel#/media/File:RBG_color_wheel.svg

But clearly in the image, it shows that purple is a secondary color between red and blue, which is how the current color palette has, and voilet is the color between purple and blue, while the current color palette has indigo in the position. So as Stuart was mentioning in comment 8, the main issue is that we are not using standard base colors in the palette, which is causing problems in the naming. So having Purple (secondary color) follow Red (primary color) breaks the RYB color scheme that the palette follows.

(In reply to Heiko Tietze from comment #9)
> ... the question just boils down whether purple is more of a red
> color or rather blue. In my opinion Mihkel is right with red, he gave a lot
> of references to proof this.

I dont see this as the issue, as according to RYB purple is a mix of red and blue and voilet is a mix of purple and blue. But if you check RGB, voilet is also a mix of magenta and blue.
Comment 11 V Stuart Foote 2017-12-31 04:25:08 UTC
Created attachment 138758 [details]
RYB color palette generated with Gossett & Chen, and correctly assigning RYB Primary, RYB Secondary and traditional Tertiary names

Swap in the attached standard.soc palette, used the Gosett & Chen algorithim based converter put up by Dave Eddy, https://bahamas10.github.io/ryb/about.html

https://bahamas10.github.io/ryb/

at -180, -130, -80, -30, 0, +30, +80, +130, +180

Color names are the correct RYB Primaries: Red, Yellow, Blue; and the correct RYB Secondaries: Orange, Green, Purple. With example George Field RYB Tertiaries found in https://en.wikipedia.org/wiki/Tertiary_color 

So, I used the traditional: 
Magenta rather than our Brick
Violet rather than our Indigo
Chartreuse rather than our Lime
Amber rather than our Gold
Vermilion rather than our Brick

but they could be changed back without fuss.

This layout and color assignment is correct for a RYB based palette. What we had for standard.soc was a mess.  The "levels" of the scales may need to be adjusted--but simple to set a brightness level -255 -> 0 <- +255, higher are lighter.
Comment 12 V Stuart Foote 2017-12-31 05:33:24 UTC
(In reply to V Stuart Foote from comment #11)
> 
> https://bahamas10.github.io/ryb/
> 
> at -180, -130, -80, -30, 0, +30, +80, +130, +180
> 

To use this for generating an RYB based palette as for our standard.soc:

--need to rotate to wheel to Yellow, so 105°.

--take the default 12 divisions (generating Primaries, Secondaries, Tertiaries).  

--then reduce the ring count to 1. 

--finally set the brightness as needed for the SOC palette variant. 

The resulting wheel represents values for one row of our RYB palette.

Save/download as SVG format. Then extract the fill="#HEX" for each of the 12 color values--they are positional in the downloaded SVG--keep them in the correct order when building the SOC palette draw:color stanzas for each row.

Change the brightness for each new row of values in the palette. Generate, download and extract the color in RGB #HEX from the SVG--repeat.

I probably should have used -200, -150, -50, 0, 50, 100, 150, 200 brightness--beyond that the colors are seem dark or too light.  But I think this is a technically correct (and reproducible) way to generate the RYB based color palette that standard.soc now represents. It eliminates some of the arbitrary color choices that had made their way into the palette.
Comment 13 V Stuart Foote 2017-12-31 07:18:56 UTC
Created attachment 138760 [details]
original RYB palette used in new standard.soc, with color names added

Jay, *

So looking at the commit [1] where we switched from HLV to set RYB colors, noticed this PNG https://bug-attachments.documentfoundation.org/attachment.cgi?id=111095

I've annotated the color names (of course the Tertiary could be the modern rather than the traditional) onto it, but if folks are happy with the RGB color representations pulled from this--we could just correct the labeling which got mixed up.

So were you picking RGB from the image, or were they directly computed?

=-ref-=
[1] https://gerrit.libreoffice.org/#/c/36202/
Comment 14 Heiko Tietze 2017-12-31 09:01:18 UTC
(In reply to V Stuart Foote from comment #11)
> Created attachment 138758 [details]

Not bad but I prefer our coverage of red as Vermillion and Red are very close compared to Brick vs. Red. And the hue variation in the lower light area (light 2 and 1 to dark 1) is also quite small.

If we change the color palette again, all subsidiary patches have to be redone. For example the patch for gradients, which is still pending a review (https://gerrit.libreoffice.org/#/c/46428/), makes no sense with different color values. Even worse when we would have started to update the Sky Tango Blue to whatever transition for the hard-coded values.

I still wonder what arguments speak against just swapping the color names.
Comment 15 Yousuf Philips (jay) (retired) 2017-12-31 13:10:03 UTC
(In reply to V Stuart Foote from comment #13)
> So looking at the commit [1] where we switched from HLV to set RYB colors,
> noticed this PNG
> https://bug-attachments.documentfoundation.org/attachment.cgi?id=111095

The old color palette was something heiko came up.

> So were you picking RGB from the image, or were they directly computed?

They were picked directly from the image.
Comment 16 V Stuart Foote 2017-12-31 14:50:06 UTC
Created attachment 138766 [details]
original RYB palette with modern names

(In reply to Yousuf Philips (jay) from comment #15)
> > So were you picking RGB from the image, or were they directly computed?
> 
> They were picked directly from the image.

OK so that is a technical issue with the colors--and using the the generator directly would result in a more correct rendering of a RYB palette--but at this point the only actual "error" is our labeling of Magenta as "Violet". 

Look at the attached image, the Indigo scale is correctly also know as Violet.

Fixing this we would leave the RGB Hex values as are, but need to change all the standard.soc Violet names to Magenta... and would also need to tweak Gabor's work on translation strings (.hxx, .hrc)[1]  

Not sure if the new gradients need any attention.

=-ref-=
[1] https://gerrit.libreoffice.org/#/c/41330
Comment 17 V Stuart Foote 2017-12-31 15:04:02 UTC
I guess the other point to make is that, when corrected to use the Magenta tertiary, the standard.soc (and any derived gradients) would not have a "Violet" color label.

We've switched to the modern RYB tertiary name of "Indigo". 

Do we want Indigo or Violet?
Comment 18 Yousuf Philips (jay) (retired) 2018-01-01 01:06:02 UTC
Created attachment 138777 [details]
stuart palette vs current palette

(In reply to V Stuart Foote from comment #11)
> Created attachment 138758 [details]

Colors are definitely richer as they are standard colors compared to our hued colors, but the colors in rows 2 and 6 are pretty much identical (yellow = ff000, light yellow 1 = ffff0a), and row 7 isnt much darker to row 2, though it is called dark **** 1.

(In reply to V Stuart Foote from comment #16)
> OK so that is a technical issue with the colors--and using the the generator
> directly would result in a more correct rendering of a RYB palette--but at
> this point the only actual "error" is our labeling of Magenta as "Violet". 

If the color fits Magenta, then this would be the correct fix.

(In reply to V Stuart Foote from comment #17)
> Do we want Indigo or Violet?

I'd stay with Indigo.
Comment 19 V Stuart Foote 2018-01-01 17:16:10 UTC
Created attachment 138791 [details]
generated RYB color palette with adjusted brighness and "modern" tertiary color names

(In reply to Yousuf Philips (jay) from comment #18)
> 
> Colors are definitely richer as they are standard colors compared to our
> hued colors, but the colors in rows 2 and 6 are pretty much identical
> (yellow = ff000, light yellow 1 = ffff0a), and row 7 isnt much darker to row
> 2, though it is called dark **** 1.

OK, attaching another standard.soc, this one also using the Eddy's Gosett & Chen based RYB => RGB converter [1] but with row brightness adjusted to -180, -160, -130, -80, 0, +80, +130, +160, +180

0 brightness is row 2 holding the base RYB colors: Yellow, Amber, Gold, Orange, Brick, Red, Magenta, Purple, Indigo, Blue, Teal, Green, Lime using modern tertiary names.

Seem to have a little more distinct gradient by dropping the brightness 30 increment and adding the 160.

=-ref-=
[1] https://bahamas10.github.io/ryb/
Comment 20 V Stuart Foote 2018-01-01 18:31:52 UTC
Created attachment 138792 [details]
screenclip current standard palette vs a generated RYB palette (attachment 138791 [details])
Comment 21 V Stuart Foote 2018-01-01 18:53:35 UTC
(In reply to V Stuart Foote from comment #19)
> 0 brightness is row 2 holding the base RYB colors: Yellow, Amber, Gold,
> Orange, Brick, Red, Magenta, Purple, Indigo, Blue, Teal, Green, Lime using
> modern tertiary names.

Sorry, traditional Amber was replaced by modern Gold--its not included.
Comment 22 Heiko Tietze 2018-01-02 09:14:45 UTC
(In reply to V Stuart Foote from comment #19)
> OK, attaching another standard.soc, this one also using the Eddy's Gosett &
> Chen based RYB => RGB converter [1] but with row brightness adjusted to
> -180, -160, -130, -80, 0, +80, +130, +160, +180

Dark colors 2-4 are almost the same, and since the pastel tones are underrepresented I would move the spectrum two steps. There is no good reason to have equidistant luminescence values.
Comment 23 V Stuart Foote 2018-01-02 22:19:48 UTC
Created attachment 138825 [details]
generated RYB color palette

regenerated a RYB => RGB standard.soc adjusting brightness sequence: 

0  -> base RYB
185 -> light 4
160 -> light 3
130 -> light 2
90 -> light 1
-65 -> dark 1
-120 -> dark 2
-150 -> dark 3
-180 -> dark 4
Comment 24 V Stuart Foote 2018-01-02 22:27:14 UTC
Created attachment 138826 [details]
generated RYB color palette (rev 2)

revised RYB => RGB scale

Brightness values
185, 160, 130, 90, 0, -65, -120, -150, -180

0 is row 2 then, descending light 4 -> dark 4
Comment 25 Heiko Tietze 2018-01-02 23:14:23 UTC
(In reply to V Stuart Foote from comment #23)
> Created attachment 138825 [details]

Still too dark. The palette has two rows of very dark and muted colors but only one with pastel tones. I would make the brightest colors almost white like the dark are almost black. When using as fill color on large areas those colors make a lot of sense.

And what I liked on the current standard palette, the nice green/blue coverage has changed into a better representation of yellow/red. But that was your intention, I guess.
Comment 26 V Stuart Foote 2018-01-03 00:12:01 UTC
(In reply to Heiko Tietze from comment #25)
> (In reply to V Stuart Foote from comment #23)
> > Created attachment 138825 [details]
> 
> Still too dark. The palette has two rows of very dark and muted colors but
> only one with pastel tones. I would make the brightest colors almost white
> like the dark are almost black. When using as fill color on large areas
> those colors make a lot of sense.

OK. Can do that. But maybe give me a brightness level you would like for each of the light and dark values by using the generator:

https://bahamas10.github.io/ryb/

(set the rings count to 1 to see a full slice of the color)

The 180, 160, 130, 90, 0, -65, -120, -150, -180 brightness values are what I've used for revision 2.

> 
> And what I liked on the current standard palette, the nice green/blue
> coverage has changed into a better representation of yellow/red. But that
> was your intention, I guess.

Yes, but the current standard palette is a technically corrupt representation of  RYB--and because we picked the colors off the PNG image we are not able to adjust it. Whereas using the generator and setting its brightness values, we generate theoretical RYB palette colors consistently at each selected brightness level--as represented here.
Comment 27 Heiko Tietze 2018-01-03 09:11:54 UTC
(In reply to V Stuart Foote from comment #26)
> OK. Can do that. But maybe give me a brightness level you would like for
> each of the light and dark values by using the generator:
> 
> https://bahamas10.github.io/ryb/

An option would be 200, 170, 140, 110, 80, 0, -60, -120, -180 but the typical distribution is non-linear. Some formulas can be found with "relative luminance", such as from CIELAB, where I let others understand the math.
Comment 28 V Stuart Foote 2018-01-03 19:04:48 UTC
Created attachment 138862 [details]
generated RYB color palette (rev3) Heiko's

(In reply to Heiko Tietze from comment #27)

> An option would be 200, 170, 140, 110, 80, 0, -60, -120, -180 but the
> typical distribution is non-linear. Some formulas can be found with
> "relative luminance", such as from CIELAB, where I let others understand the
> math.

Attached. And in the standard.soc now have light 1-5 and dark 1-3.
Comment 29 V Stuart Foote 2018-01-03 19:06:55 UTC
Created attachment 138863 [details]
generated RYB color palette (rev 3) standard.soc

not ready to merge, has some of the other brightness rows still included but commented out
Comment 30 V Stuart Foote 2018-01-03 20:05:36 UTC
Created attachment 138864 [details]
10 row version of RYB palette
Comment 31 V Stuart Foote 2018-01-03 20:13:58 UTC
Created attachment 138865 [details]
10 row standard.soc +200 > -180, 5 light 3 dark
Comment 32 V Stuart Foote 2018-01-04 01:21:30 UTC
Created attachment 138868 [details]
ODT table with the rev3 palette

as requested at 2018-01-03 design meeting, a larger table with the rev3 palette with brighness levels: 200, 170, 140, 110, 80, 0, -60, -120, -180 and Light 5 - 1, and Dark 1 -3.
Comment 33 V Stuart Foote 2018-01-04 07:20:15 UTC
Created attachment 138871 [details]
ODT table with the rev3 palette (corrected Dark Lime 2 cell)
Comment 34 Heiko Tietze 2018-01-04 09:45:55 UTC
The last step is too big and I would also increase the 80 step. So my update:

200,170,150,110,60,-50,-100,-160 

also based on the W3 standard formula POWER((x + 0.055) / 1.055; 2.4), which would be more like 200,180,160,130,90,-30,-100,-180.
Comment 35 V Stuart Foote 2018-01-04 17:30:48 UTC
Created attachment 138879 [details]
10 row standard.soc +200 > -160 (rev4)

10 row standard SOC with RYB brightness +200, +170, +150, +110, +60, 0, -50, -100, -160.

Note: this file is not ready to merge as it has these additional RYB brightness rows commented out: +185, +180, +160, +140, +130, +90, +80, -60, -65, -80, -120, -130, -150, -180
Comment 36 V Stuart Foote 2018-01-04 17:32:19 UTC
Created attachment 138880 [details]
ODT with table showing rev4 palette, 5 light, 3 dark and base RYB
Comment 37 Heiko Tietze 2018-01-04 17:51:56 UTC
Noc changes required from my side. Great work, Stuart.
Comment 38 Yousuf Philips (jay) (retired) 2018-01-06 08:18:56 UTC
(In reply to V Stuart Foote from comment #36)
> Created attachment 138880 [details]
> ODT with table showing rev4 palette, 5 light, 3 dark and base RYB

The difference between +60 and base or base and -50 is quite negligible, especially with the base colors. Having 5 light variants still feels like overkill to me and think the 4 light and 4 dark is the better option, else we reduce it to 3 light and 3 dark like google docs.
Comment 39 V Stuart Foote 2018-01-09 13:06:16 UTC
Created attachment 138995 [details]
sample with the rev4 palette

(In reply to Yousuf Philips (jay) from comment #38)
> The difference between +60 and base or base and -50 is quite negligible,
> especially with the base colors. Having 5 light variants still feels like
> overkill to me and think the 4 light and 4 dark is the better option, else
> we reduce it to 3 light and 3 dark like google docs.

Assume we would have to keep the "0" brightness as the base RYB color (from Itten's Color theory work)--but beyond that is the row count even an issue, as we move the base to the top below the grayscale? 

We would not want to go over 10 rows (triggers the scrollbar in the picker) but if not 10, then sure 9 or 8 would also work.

Jay, what would be your splits?
Comment 40 V Stuart Foote 2018-01-09 14:21:05 UTC
Created attachment 138997 [details]
sample with rev4 palette
Comment 41 V Stuart Foote 2018-01-09 14:23:22 UTC
Created attachment 138998 [details]
ODT with table showing rev4 palette, 5 light, 3 dark and base RYB
Comment 42 Yousuf Philips (jay) (retired) 2018-01-09 19:05:54 UTC
(In reply to V Stuart Foote from comment #39)
> Assume we would have to keep the "0" brightness as the base RYB color (from
> Itten's Color theory work)--but beyond that is the row count even an issue,
> as we move the base to the top below the grayscale? 
>
> We would not want to go over 10 rows (triggers the scrollbar in the picker)
> but if not 10, then sure 9 or 8 would also work.

Well the ideal row count is to have 10 (1 grayscale, 1 base colors, 8 base color variants), as that is what we decided was the best size based on the tonal and standard palettes and not to trigger the scrollbar.

> Jay, what would be your splits?

My split has always been 4 light and 4 dark so that it fills the necessary 10 rows, as we have today, and would cover more of the base color variant spectrum, but if we cant find 4 suitable dark colors, then we should reduce it to 3 light and 3 dark.

We initially had 4 light and 3 dark as found in the color wheel, but added the 4th dark when we decided to go for 10 rows and heiko felt the wheel missed darker colors which he had in his color palette[1] that came with LO 5.3.

In the 5.3 and 5.4 color palettes, the base color variants adjusted both brightness and saturation, and maybe we add saturation to the mix for the suggested new color palette to have more differences between the colors.

[1] https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2016/12/Figure3-1.png
Comment 43 V Stuart Foote 2018-01-10 03:59:42 UTC
Created attachment 139003 [details]
rev5 -- standard.soc - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added)

OK another stab at the RYB color theory. Itten work suggests lightning the Hues adding white produces "tints", and darkening the Hues adding black are "shades".

And Eddy's Gossett and Chen implementation seems to be handling "brightness" along the White/Black diagonal of the tesor, fully saturated base hue at 0 tints as white value increases shades as black value increases.

So keeping 4 tints, 4 shades and the base RYB hues give a nice Itten centric palette. 

In this rev 5 of standard soc have generated 4 tints 30% (77), 45% (115), 60% (153) and 75% white (191); and 4 shades 20% (-51), 40% (-102), 60% (-153), 80% black (-204). So back to 4 light and 4 dark, plus base Hue, plus grayscale for 10 rows.

Attaching sample ODT and screen clip.
Comment 44 V Stuart Foote 2018-01-10 04:01:11 UTC
Created attachment 139004 [details]
sample with rev5 palette
Comment 45 V Stuart Foote 2018-01-10 04:02:39 UTC
Created attachment 139005 [details]
ODT with table showing rev5 palette -- tints and shades of hues
Comment 46 V Stuart Foote 2018-01-10 04:19:01 UTC
(In reply to V Stuart Foote from comment #43)
 > along the White/Black diagonal of the tesor ...

s/tesor/tensor/ as in the tensor needed for trilinear interpolation the algorithm performs to assign RGB values.
Comment 47 V Stuart Foote 2018-01-10 04:30:56 UTC
This blog post presents a practical and concise demonstration of why structuring a "Itten" centric RYB palette for standard use is so appealing if we get it right:

https://99designs.com/blog/tips/color-the-world-create-compelling-color-schemes/

Turns out the Itten hues are simple, but holding the tints and shades at correct levels--a bit more of a challenge.
Comment 48 V Stuart Foote 2018-01-10 04:57:59 UTC
Created attachment 139006 [details]
standard.soc (rev5) - Grayscale, Hues, 4 tints (30%, 45%, 60%, 75% white added), 4 shades (20%, 40%, 60%, 80% black added)
Comment 49 Commit Notification 2018-02-08 09:37:54 UTC
heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbde6eeae5c0ca5e106eec53dc7882361897a616

tdf#114719 RYB based color palette

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 50 Flora Canou 2018-07-11 16:58:54 UTC
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?
Comment 51 V Stuart Foote 2018-07-11 17:42:24 UTC
(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 [details] 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.
Comment 52 Flora Canou 2018-07-12 04:10:25 UTC
(In reply to V Stuart Foote from comment #51)
> ...

The flaw consists in the algorithm. If we must keep an RYB-based palette, it is favorable to find one that does not go wrong in dark colors. 

This palette also looks generally too warm in my eyes. Maybe I'll try developing an RGB-based standard palette as an extension
Comment 53 V Stuart Foote 2018-07-12 04:26:21 UTC
(In reply to Flora Canou from comment #52)
> (In reply to V Stuart Foote from comment #51)
> > ...
> 
> The flaw consists in the algorithm. If we must keep an RYB-based palette, it
> is favorable to find one that does not go wrong in dark colors. 
>

OK will close as there is no better RYB palette generator. But as indicated still may move the 4th shade from 80% to ~70%, but Shades are always going to drift from the hue--even mixing paint in real world...

=> RF

> 
> This palette also looks generally too warm in my eyes. Maybe I'll try
> developing an RGB-based standard palette as an extension

Looking forward to it, but would suggest you not name extension as standard palette (standard.soc); rather if you compose a RGB (HSV based) you like, loading the extension can swap it in for the standard.soc palette if that is your goal. 

Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard coded in the unit tests.
Comment 54 Flora Canou 2018-07-21 04:23:36 UTC
(In reply to V Stuart Foote from comment #53)

> Looking forward to it, but would suggest you not name extension as standard
> palette (standard.soc); rather if you compose a RGB (HSV based) you like,
> loading the extension can swap it in for the standard.soc palette if that is
> your goal. 

Just made the standard RGB color palette, using the name "Standard RGB". It's currently available here: https://github.com/FloraCanou/standardrgb-palette-loext (since the official extension site is rather slow). 
I'm also trying to develop an optimized RYB-RGB conversion algorithm. I can't catch the 6.1 release though. 

> Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard
> coded in the unit tests.

I don't quite understand this. Could you please note in detail what I need to do about it?
Comment 55 V Stuart Foote 2018-07-21 15:37:29 UTC
Created attachment 143677 [details]
color picker palette Standard & Tonal and a RBG palette using Canou-Zheng Improved HCI

(In reply to Flora Canou from comment #54)
> 
> Just made the standard RGB color palette, using the name "Standard RGB".
> It's currently available here:
> https://github.com/FloraCanou/standardrgb-palette-loext (since the official
> extension site is rather slow). 

The gradient is smooth, and RGB colors quite acurate, it looks nice, unfortunately the full palette tends toward the pastels. The same issue as with the freecolour-HLC CIELAB reference palette.

Need more highly saturated RGB colors. For example the "tonal" technical palette--perhaps alligh the name/color pairings (from the tonal 58% row) across these two RGB centric palettes adjusting the starting point. But if just an extension--your call on that stylistic facet.

Also, to simplify things for translators should this be added to core, I would suggest you adopt the color naming from the tonal palette of Spring Green and Chartreuse rather than the non-standard Lime and Turquoise you've assigned.

> I'm also trying to develop an optimized RYB-RGB conversion algorithm. I
> can't catch the 6.1 release though. 
> 

6.1 is string and feature frozen, we are committed to a RYB palette. But improving the RGB/HSI color correctness for RYB hue, tints and especially the shades would be a valid patch for the release. Looking forward to see if you can improve on the Gosett & Chen algorithm used by Eddy.

> (In reply to V Stuart Foote from comment #53)

> > Just watch out for Light Blue 2 and Dark Blue 1 as those values are hard
> > coded in the unit tests.
> 
> I don't quite understand this. Could you please note in detail what I need
> to do about it?

IIRC several unit tests pick up the defined COL_DEFAULT_SHAPE_FILLING and COL_DEFAULT_SHAPE_STROKE [1] and automated qa unit tests break when we've removed those specific values from the standard.soc, or have changed their assigned values in the xdef.hxx...  Heiko?


=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/include/svx/xdef.hxx#81