Created attachment 180892 [details] Sample slide (PPTX) Opening the sample slide in Impress versus Office 365 it appears that the former does not "show" transparency of the included PNG file. Specifically the background remains white instead of taking on the color of the object below. Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 66b1ebd4ddc7127a923bf81eb569e7f99dd52022 CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and all the way back to Version: 6.4.8.0.0+ Build ID: 99b065ec31d032fc08ab14f66430dac4fef904a5 CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-4, Time: 2020-10-08_08:57:08 Locale: en-US (en_US.UTF-8); UI-Language: en-US
Created attachment 180893 [details] Visual comparison LibreOffice (left) vs Office 365 (right)
Reproduced in Version: 7.4.0.0.beta1+ / LibreOffice Community Build ID: 6ab56a4fc946f6294513f23a3ea47aa0aa154b7d CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: tr-TR (es_ES.UTF-8); UI: en-US Calc: threaded Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3; Locale: es-ES (es_ES.UTF-8); Calc: group threaded Version: 5.3.7.2 Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 8; OS Version: Linux 5.10; UI Render: default; VCL: gtk2; Layout Engine: new; Locale: en-US (es_ES.UTF-8); Calc: group
Also reproduced in Version 4.0.5.2 (Build ID: 5464147a081647a250913f19c0715bca595af2f)
Created attachment 181091 [details] console logs during opening On pc Debian x86-64 with master sources updated today. Considering the number of this kind of log "warn:svx.uno:25379:25379:svx/source/unodraw/unoshape.cxx:1597: Unknown Property", there's some work to be done.
I think the subject is a bit misleading. The referenced image is ppt/media/image26.jpeg so it's not a PNG. Then a color change is applied, that turns white-ish pixels transparent: <p:blipFill rotWithShape="1"> <a:blip r:embed="rId3"> <a:clrChange> <a:clrFrom> <a:srgbClr val="F4FFFF"/> </a:clrFrom> <a:clrTo> <a:srgbClr val="F4FFFF"> <a:alpha val="0"/> </a:srgbClr> </a:clrTo> </a:clrChange> <a:extLst> <a:ext uri="{28A0092B-C50C-407E-A947-70E740481C1C}"> <a14:useLocalDpi xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main" val="0"/> </a:ext> </a:extLst> </a:blip> <a:srcRect l="13478" r="13229"/> <a:stretch/> </p:blipFill> I think this color change is responsible for the artifacts that we see around the geeko in LibreOffice. On the other hand, in PowerPoint the color change replaces all pixels. Maybe PowerPoint uses a different threshold.
E.g. when I changed <a:srgbClr val="F4FFFF"/> to <a:srgbClr val="FFFFFF"/>, the rendering in LibreOffice was almost identical to rendering in PowerPoint, which suggests that my idea about the threshold in color replacement algorithm may be right.
Created attachment 182133 [details] Sample PPTX with transparent setting (1) Good observations! Here's a series of 3 PPTX samples, with the same JPG over a colored background. The JPG has a series of overlapping squares with the following succession of RGB settings (same values for R/G/B): 255 - 250 - 245 - 240 - 235 - 230 - 225 - 220. 1st sample has transparency set on the 1st rectangle (255): - PP shows 1-5. rectangles transparent (255-235), - Impress shows 1-3. rectangles transparent (255-245). 2nd sample has transparency set on the 5th rectangle (235): - PP shows 1-8. rectangles transparent (255-220), - Impress shows 4-6. rectangles transparent (240-230). (note: if the 4th rectangle is sampled, the last rectangle remains opaque in PP) 3rd sample has transparency set on the last rectangle (220): - PP shows 5-8. rectangles transparent (235-220), - Impress shows 7-8. rectangles transparent (225-220).
Created attachment 182134 [details] Sample PPTX with transparent setting (2)
Created attachment 182135 [details] Sample PPTX with transparent setting (3)
Created attachment 182157 [details] colortolerance-tests-jpeg.pptx
Created attachment 182158 [details] Visual: Color Tolerance JPEG
Created attachment 182159 [details] colortolerance-tests-png.pptx
Created attachment 182160 [details] Visual: Color Tolerance PNG
Created attachment 182161 [details] linear-gradient-different-image-formats.pptx
Created attachment 182162 [details] Visual: (After patch) Different Formats I have generated some linearly decreasing color charts where the x axis represents the change amount. (i.e. x=0 means #FF0000, x=1 means #FE0000...) First thing I realized with this was: - Impress wasn't able to color change with #FF0000 Debugging it, realized the Graphic::colorChange had an initialization error that swapped Red and Blue. (i.e. #FF0000 was treated as #0000FF) Fixed that and continued tests w.r.t color change tolerances. With colortolerance-tests-jpeg.pptx (see comparison: "Visual: Color Tolerance JPEG"): - In PP: Colors having other colors in between doesn't have a significant effect. - In PP: Distance the colors change over doesn't have a significant effect. - In PP: Tolerance value appears to be around 15 => So hopefully we should be able to just adjust the tolerance during import and get a similar result. Also tried with pngs to see if that would create a different result and it did: With colortolerance-tests-png.pptx (see comparison: "Visual: Color Tolerance PNG"): - In PP: PNGs have a color tolerance of 1 where JPEGs had 15. Realizing different file formats may have different tolerances in PP. (This might not be directly related to the file format and might be dynamically decided by some algorithm on PP but I couldn't find any clues w.r.t this) Created a test file that tests JPEG, PNG, BMP and TIFF: (linear-gradient-different-image-formats.pptx) Used the tolerance values I've captured from this test and sent a patch. https://gerrit.libreoffice.org/c/core/+/139203 After the patch the comparison looks like ("Visual: (After patch) Different Formats") Also both the tests Aron created and the initial sample slide (whitegeeko2.pptx) seem to give really similar results to PP now. It appears there's also a bug specific to TIFF. Looks like the tolerance amount somehow gets disregarded. I think this could be considered a different bug.
Sarper Akdemir committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2b902b6203a87bdca7856e17a9c0fcc403de4264 tdf#149670 fix color change api and adjust tolerance for ooxml It will be available in 7.5.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.
Verified in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: ee003ca99f94c9a5517ebba67ed02abb2a60dae8 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded @Sarper, thanks for fixing this issue. Should it be closed as RESOLVED FIXED ?
@Xisco, yes I think so! Although the behaviour with TIFF could be reported as another bug.
Sarper Akdemir committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/de325e4b603d6b57fa6b46021a1b4c83e2d44e82 tdf#149670 fix color change api and adjust tolerance for ooxml It will be available in 7.4.2. 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.
*** Bug 119884 has been marked as a duplicate of this bug. ***