Created attachment 89984 [details] green CMYK color When I edit the color palette via the LibreOffice Preferences the colors look far off. Example: when I use CMYK 100-0-100-0 (percent values) I do expect a dark green. Instead this becomes a very bright green with RGB 0-255-0. When I do the same in other programs the color is more what I do expect. Gimp would convert CMYK 100-0-100-0 to RGB 0-153-74, Apple ColorSync Utility converted to RGB 0-166-108. I suppose that conversion might require color profiles which do an optimum conversion. The LibreOffice conversion is too simple or just wrong?
Martin: I'm not a color expert but gave a try to some websites and got the same value as LO. http://easycalculation.com/colorconverter/rgb-color-converter.php http://www.rapidtables.com/convert/color/cmyk-to-rgb.htm http://www.ginifab.com/feeds/pms/cmyk_to_rgb.php Now I don't know if these may be wrong or not. Reading http://en.wikipedia.org/wiki/CMYK_color_model, it seems there's no a simple way to convert CMYK towards RGB. You talked about Gimp but I thought Gimp wouldn't provide CMYK Michael: I thought you might help here. Any idea?
If you have no profile, any CMYK conversion is entirely pointless. It probably uses a naive formula that is never right in real life. I suspect you are trying CMYK colors because some print shop told you to give them a CMYK document. Did they also give you THEIR color profile? If they didn't, don't use them. They have no clue whatsoever and want to free themselves of any responsibility for correct color reproduction. A proper print shop takes your RGB document (which you can properly edit on an RGB display), do the CMYK conversion using their professional knowledge, give you a proof print and print it JUST LIKE THAT after you approved. Also, does LibreOffice support profiles at all?
Thank you Michael for your feedback. According to this: http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/rendering/ColorProfile.idl#26 It seems there's no ICC implemented but perhaps I missed something Caolán: since ICC are related with the rendering, I thought about vcl part, any idea?
We do have lcms2 in the build and we do splat out "emit the sRGB standard profile, in ICC format, in a stream, per IEC61966-2.1" into our pdf files as a dump. We don't make any other use of this stuff as far as I can see so.
Martin: because of the bug put in See Also, Magenta and Yellow values are switched. Could you try "100, 100, 0, 0" instead of "100, 0, 100, 0" ? But even in this case, I got a dark blue and not dark green.
Created attachment 92720 [details] Screenshots of LOv4142 and GIMPv268 (the later with various colour profiles in effect). I can probably confirm this bug as an enhancement to get colour profile support more widely included in LO (currently only sRGB for PDF export as indicated in comment #3 and comment #4). Under Ubuntu 10.04 x86_64 if I install these packages: - gnome-color-manager (which pulls in the argyll package) - icc-profiles ... a variety of ICC profiles will be installed under /usr/share/color/icc/ allowing GIMP to be used in different colour spaces (Edit > Proferences > Color Management > select CMYK profile). The attached screenshots likely indicate what the reporter is seeing. For example, when the CMYK profile is set to use the "ISO coated" profile, the result for CMYK 100-0-100-0 is RGB 0-157-80. For "ISO uncoated" RGB 0-158-66. For "ISO webcoated" RGB 0-161-66, and so on. Tested using GIMP v2.6.8. Screenshot from LO v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 included for comparison. Note: These examples are not intended as accurate representations (I am not running any matching video card adjustment).
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
According to comment 6 this should have been set to NEW.
*** Bug 94211 has been marked as a duplicate of this bug. ***
…so what have been done since regarding rgb / cmyk in LibreOffice ?
Because of the buggy conversion of RGB to CMYK, access to the latter is now (5.3) possible only in the color picker. AFAIR the issue was restricted to the former area style dialog and not the picker. So I'd say it's fixed. But that should be verified => NEEDINFO.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170929
Hi, I have new tested with Debian LibreOffice 5.4.1-1 and with the file sent with the bug report 94211 (marked as duplicated). The colors of the image in LibreOffice are not good. I opened the JPEG file in Gimp and the image in a Writer document. You can see the difference in color. The screenshot is attached. Regards.
Created attachment 136614 [details] Original logo CMYK
Created attachment 136616 [details] Screenshot, comparative colors between Gimp and Writer for original logo CMYK.
Christoph, may I ask you for an advice. On my system (Linux, LXQt) the image has a more blueish pink compared to Gimp. That's true for Firefox, Gwenview, Libreoffice - all look similar but not like Gimp. What's the truth here? Or rather who should we follow.
Hi, The file opened in Gimp has the correct color. Regards.
This really is an import filter issue, not about working in CMYK which as noted we can't do, and on export to PDF we specify the sRGB.icc (comment 4). Frankly for UX the CMYK on the color picker is not very useful and should probably be dropped--I think that was gist of comment 2. So, this is mostly about the graphics filter mishandling CMYK colorspace images on insert into a sRGB color space, with poor results. For what it is worth, the ImagMagick 'convert' utility done without a -profile spec produces the same sRGB hue as LibreOffice's existing import. IIUC, a source image will often identify its color profile, and some image formats will fully embed it. So thinking out loud, while filter inserting a CMYK color space image, could we pull out the color profile if specified, and if one of the "well known" ICC profiles, e.g. supporting PDF/A-1, then use that to control import conversion of the image to our sRGB.icc compliant color space? =-ref-= http://www.color.org/chardata/drsection1.xalter http://www.color.org/srgbprofiles.xalter http://www.imagemagick.org/Usage/formats/#profiles https://www.pdfa.org/wp-content/until2016_uploads/2011/08/tn0002_color_in_pdfa-1_2008-03-14.pdf
Hi, I just tested the display of the CMYK image on a Windows 10. The colors of the image are good with Word, Powerpoint, Paint, IE11 and Edge, the image icon on the desktop has the right colors. Colors are not good with Writer, Firefox and Chrome. On my workstation, Debian Buster and Mate Desktop, the image icon on the desktop does not have the right colors. The colors are not good with Eye of Mate, Eye of Gnome, Firefox and Chromium. They are only good colors with Gimp. Regards.
Import filter issue, no need for UX.