Created attachment 130487 [details] photo of logo color changed after opening in libreoffice + original slide Logo color changed after openning a pptx document in Libreoffice. please see the attachment. The original log is all white, but the Libreoffice one is half black half white.
Comment on attachment 130487 [details] photo of logo color changed after opening in libreoffice + original slide wrong mime type
Comment on attachment 130487 [details] photo of logo color changed after opening in libreoffice + original slide .
Confirmed in Version: 5.4.0.0.alpha0+ Build ID: 36afb355ac37122d32d624db079def123ef548a2 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Created attachment 130490 [details] pptx document
Created attachment 130491 [details] comparison
This is slide master with PNG images. It's obvious MSO and LO are different, but if you open .pptx as .zip and there \ppt\media\image2.png, you'll see that original Gainsight PNG has color changed, just like on http://www.gainsight.com/. So, I'd say that LO preview is better. Or MSO prevents effects, because they are none, and displays simple image. I update the title but I cannot confirm this as a bug. Please mark as Resolved-NotaBug or wait until someone explains why this is a bug. PS after I wrote that and before submitted, Xisco confirmed, but I disagree again, triage is not proper.
Hm.. the image is converted to B&W and it looks like the threshold what color is black and what is white is different between MSO and LO. Changing the threshold to match MSO is an option but that would be a regression for existing documents. A solution is to convert it to B&W bitmap using MSO compatible threshold in the input filter but only if image is different.. maybe. This solution would cause a loss down the road, because the original image would be replaced, but at least the reproduction would be exact. I'm not sure if this is worth the effort, but at least we could document somewhere that the difference exists. Tomaž
In my non-export view, solution as explained is not required and I propose this be marked as NotaBug, after "document somewhere" is precised. Compatibility pages in Help should be proper, I guess.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The problem is that the image uses as color mode 'black & white 25%' which is translated to 'black & white 50%' in LibreOffice
We don't take into account a value like <a:biLevel thresh="25000"/> Starting point: https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/fillproperties.cxx?r=09cd0e36#750
the value 128 is passed hardcoded to BitmapMonochromeFilter in https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/bitmap3.cxx?r=f93a345a#253, changing it to 64 is like using 25% black/white
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: a5d68a4f959804f93ddda61a45cedaadb504e3f2 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This has the same b/w 25% effect applied on the image as bug #89928 *** This bug has been marked as a duplicate of bug 89928 ***