Bug 160125 - Standard Palette - Dark Blue 1 (from COL_DEFAULT_SHAPE_STROKE) is lighter than Blue
Summary: Standard Palette - Dark Blue 1 (from COL_DEFAULT_SHAPE_STROKE) is lighter tha...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
24.2.1.2 release
Hardware: x86-64 (AMD64) All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Color-Palettes
  Show dependency treegraph
 
Reported: 2024-03-09 23:07 UTC by Raymond
Modified: 2024-03-11 09:36 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raymond 2024-03-09 23:07:11 UTC
Description:
The dropdown for selecting a color (used for background color in Calc, etc) is normally set to the Standard Palette. There's a shading issue in the palette:

Color blue: Hex #2a6099, has Saturation 73% Brightness 60%.
Color Dark Blue 1: Hex #3465a4, has Saturation 68% Brightness 64%.

When placed side-by-side, Dark Blue would appear brighter than regular blue. This indicates two entries were swapped around. 



Steps to Reproduce:
1. Open the Background Color dropdown for cell A1, and choose Blue. 
2. Open the Background Color dropdown for cell A2, and choose Dark Blue 1.


Actual Results:
Dark Blue 1 appears to be slightly brighter than Blue.

Expected Results:
Blue should be slightly brighter than Dark Blue 1. 


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded


Was introduced in: https://gerrit.libreoffice.org/c/core/+/48887/

Source mentions something being hardcoded...
Comment 1 Julien Nabet 2024-03-10 13:33:37 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 2 Julien Nabet 2024-03-10 13:34:25 UTC
Heiko: noticing bbde6eeae5c0ca5e106eec53dc7882361897a616

tdf#114719 RYB based color palette
thought you might be interested in this one.
Comment 3 V Stuart Foote 2024-03-10 15:13:08 UTC
This was by design to minimally impact the QA build testing.

For bug 114719 the standard pallet "Light Blue 2" tint and "Dark Blue 1" shade were assigned [1] colors slightly off from the trilinear tensor calculated value to retain standard fill (COL_DEFAULT_SHAPE_FILLING) and stroke (COL_DEFAULT_SHAPE_STROKE) called out by xdef.hxx used extensively in test files used by the existing QA tests.

At the time, it was decided that the shift of these tints/shades in the generated standard pallet was more efficient than reworking the QA tests and sample files, as the xdef.hxx defined colors had to appear on the pallet. 

It is feasible to replace all the impacted QA test files and scripts, but still a lot of effort.

IMHO probably not worth the dev effort, but for a devotee to color theory it might be appealing to tackle the changes.

Otherwise => WF

=-ref-=

[1] https://gerrit.libreoffice.org/48887
where these colors for Standard RYB pallet are defined: 
 <draw:color draw:name="Light Blue 2" draw:color="#729fcf"/> <!-- #85a4c5 actually but hard coded COL_DEFAULT_SHAPE_FILLING in xdef.hxx -->

<draw:color draw:name="Dark Blue 1" draw:color="#3465a4"/> <!-- #2e5d8c actually but hard coded COL_DEFAULT_SHAPE_STROKE in xdef.hxx -->
Comment 4 Julien Nabet 2024-03-10 17:05:22 UTC
Thank you V Stuart for detailed feedback.

I read some comments on tdf#112541 and I just discovered about RYB. (thought it was a typo for "RGB").

I agree with Raymond and it's a pity that "Dark blue" is lighter than "Blue" but don't know at all what to change about QA tests.
=> uncc myself.
Comment 5 Heiko Tietze 2024-03-11 09:36:35 UTC
(In reply to V Stuart Foote from comment #3)
> Otherwise => WF

I see no urgent need to make the base colors appear exactly at some point in the color space. => WF 

(Feel free to reopen, Raymond, ideally with a use case that makes it clear why this is a serious bug.)