Created attachment 163190 [details] sample files I have dragged and dropped a test image (https://commons.wikimedia.org/wiki/File:FuBK_wide.jpg) into a DOCX in MS Word 365. I also converted the JPG to PNG using gimp and dragged that in the document too. By dragging and dropping the images get a little edited by Word (can be seen by unpacking the DOCX-file) which is not ideal but cannot be circumvented. With the JPG everything is fine. So the focus here is the PNG. When I open the resulting document in writer and Word side by side and make a screenshot there are measurable color reproduction differences. This can be best seen in the orange/brown part at the right side of the image. In the original image this part has an RGB value of 178,127,0 (measured in MS paint with the Color picker). When taking a screenshot of MS Word the color is the same 178,127,0 When taking a screenshot of writer the color is 182,133,0 This has in my opinion not something to do with compression artifacts. I have set the severity to major since correct color reproduction is a must-have for several professional/commercial use cases. I do not know if that is an issue when using the native ODT format or when dragging/dropping images directly into writer or if this is a DOCX issue. That would have to be checked too! Going further if you convert the DOCX to PDF (Export as PDF) and create PNGs out of the PDFs the issue is there too. So this is not only a UI thing but a color reproduction issue for printed output and PDF as well. I have seen the same happening with BMP, TIF, other JPGs and EMF. I attached the sample DOCX along with the input images, output PDFs of writer (Export as PDF) and Word (Printed over a GhostScript printer) and converted PNGs of the PDF pages. Expectation: The color of a PNG stays the same when opening/importing the DOCX and processing the document to PDF/print.
Please look at existing bug reports if already reported. Also test with daily master from https://dev-builds.libreoffice.org/daily/master/current.html
Waiting for test result with 7.1.5 or newer.
Dear rominator, 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
Dear rominator, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA 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 our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp