Description: If I specify any kind of color (e. g. text color or cell background color) in LibreOffice Calc, it is displayed in the wide-gamut P1 color space of my iMac monitor. This doesn’t make sense to me, as you specify the color in sRGB with 8 bits per RGB channel, while the monitor has a higher color depth. Similar to web browsers and image editing applications (take inspiration from GIMP), you should be able to specify the color management behavior in LibreOffice. The issue occurs independent of the fact whether Skia is enabled or not. Steps to Reproduce: For example, open the color selector or the custom color window. The issue occurs everywhere in the application where colors are displayed. Actual Results: Colors like #FF0000, #00FF00, #0000FF are displayed at the monitor’s highest possible saturation. Expected Results: Colors like #FF0000, #00FF00, #0000FF are displayed according to the sRGB gamut, which is less saturated than the monitor’s gamut would allow. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.1.2 (AARCH64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 8; OS: macOS 12.7.5; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded ---- NOTE: I did not reset my user profile as I noticed the issue on the day of installation.
Created attachment 196684 [details] Google Sheets vs LibreOffice Calc color gamut Left side: Google Spreadsheets in Firefox displays sRGB properly, with standard saturation. Right side: LibreOffice Calc displays sRGB colors in Display P3 (wide-gamut) color space, which appears oversaturated. You might need to have a wide-gamut monitor or adjust your computer’s color management to see a difference.
(In reply to gowildler from comment #1) > Created attachment 196684 [details] > Google Sheets vs LibreOffice Calc color gamut > > Left side: > Google Spreadsheets in Firefox displays sRGB properly, with standard > saturation. > Right side: > LibreOffice Calc displays sRGB colors in Display P3 (wide-gamut) color > space, which appears oversaturated. > > You might need to have a wide-gamut monitor or adjust your computer’s color > management to see a difference. P.S.: I recommend viewing the image in a color-managed application such as GIMP or Adobe Photoshop if you don’t see any difference.
Have you testing modifying Skia options?
Created attachment 196700 [details] HTML file with red, green, and blue rectangles for comparing to LibreOffice
Created attachment 196701 [details] Calc file with red, green, and blue cells for comparison to Safari
Created attachment 196702 [details] Snapshot of Calc on left and Safari on right
I can reproduce this bug on my M1 MacBook Pro. I opened attachment #196701 [details] in Safari as it is likely on of Apple's "gold standard" applications for sRGB color rendering. Then I opened attachment #196702 [details] in Calc and took a side-by-side snapshot of both in attachment #196702 [details]. Note: open the snapshot in Safari to see the color differences as for some unknown reason I cannot see any significantly color differences when I open the snapshot in Firefox. Anyway, when viewing the snapshot in attachment #196702 [details] in Safari or in the Finder preview pane, I can see higher saturation in the red and green on the left (i.e. in Calc). From what I have seen of the macOS native code in LibreOffice, all drawing surfaces already use an sRGB colorspace. But I will experiment with the code and see if I can find anything that looks like it might be causing this bug.
Created attachment 196703 [details] Snapshot of Skia/Raster with patch in https://gerrit.libreoffice.org/c/core/+/173962 I think I found a fix for Skia/Raster and Skia disabled (see attached snapshot). The fix does not work with Skia/Metal so I will need to go on a deep dive into the Skia source code when I get some time. But in the meantime, can anyone with a macOS LibreOffice build try out the following patch?: https://gerrit.libreoffice.org/c/core/+/173962
I think I have a fix for Skia/Metal and I have added into the following patch: https://gerrit.libreoffice.org/c/core/+/173962
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e4ab68142c7bc4e04ffe429567dda974b86985a7 tdf#163152 don't convert image's sRGB colorspace It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed a fix this bug. The fix should be in tomorrow's (27 September 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/903f23d3eeb84b2b658251876c78c0b0d6ba1616 tdf#163152 don't convert image's sRGB colorspace It will be available in 24.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/4056b31465e72e0a9e262639444fc5a3249f548d tdf#163152 don't convert image's sRGB colorspace It will be available in 24.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.