Created attachment 193405 [details] inverted webp inmage in impress Inserting webp image with transparent background is inverted with the transparent background now colored and the foreground now transparent. No issue with webp images with no transpaency Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
Created attachment 193406 [details] this show examples of other programs that have no issue with the webp file I added this pic with other programs that I inserted the same webp and all displayed it correctly.
Thank you for reporting the bug. I can confirm that the bug is present in Stable Build Version: 24.2.2.2 (AARCH64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Master/Daily Build Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: c4023d3ec604abfff38be2053e2989c7ec2ba8c1 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded For reference, I tested on MacOS 14.1.2 on a M2 Pro Chip MacBook Pro.
Thanks for the report. Could you please share the original picture? Looks like it is converted to a PNG (when looking at the extract ODP's contents), so would be best to test inserting the picture in different versions.
Created attachment 193739 [details] ODT document containing WEBP image I hope this attachment and the associated WEBP image will assist if the OP does not reply.
Created attachment 193740 [details] WEBP image file included in associated ODT document
Could confirm the buggy behavior with LO 24.2.2.2 on OpenSUSE 15.4 64bit rpm Linux. Attached webp-image will be shown black and white…
Couldn't confirm with LO 7.4.7.2 on the same system. Works also on LO 7.6.4.1. First version with the bug I could detect is Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
Not specific to Impress, same issue in Writer. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bdf3b5ce49b0e4ee1b4525d344cfb037ef473059 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Further research with WEBP images shows that it is the transparency which is inverted. Any part of the image which is fully transparent will be shown as black, and anything which is fully opaque will be shown as fully transparent. Partially opaque/transparent areas will appear with their correct colours but as the inverse of their opacity - ie a 75% opaque area will be shown as 25% opaque. A 1% opaque area will look 99% opaque, etc. So we know which property is being incorrectly calculated. Now it's just a question of finding the calculation and correcting it!
Support for WebP format was added in 7.4 https://wiki.documentfoundation.org/ReleaseNotes/7.4#Core_/_General This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Noel Grandin ; Could you possibly take a look at this one? Thanks c21a1c45e2403119c90af25cdb5350f978d5c93b is the first bad commit commit c21a1c45e2403119c90af25cdb5350f978d5c93b Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jul 25 09:06:10 2023 +0200 source 81994cb2b8b32453a92bcb011830fcb884f22ff3 https://git.libreoffice.org/core/+/81994cb2b8b32453a92bcb011830fcb884f22ff3 Convert internal vcl bitmap formats transparency->alpha (II)
In which case libreoffice-2.4.2.2/vcl/source/filter/webp/reader.cxx line 244 looks suspicious. If you've rewritten the code to use alpha rather than transparency, why subtract alpha from 255 before using it? 238 const unsigned char* src = tmpRgbaData.data() + width * 4 * y; 239 unsigned char* dstB = access->GetScanline(y); 240 unsigned char* dstA = accessAlpha->GetScanline(y); 241 for (tools::Long x = 0; x < access->Width(); ++x) 242 { 243 memcpy(dstB, src, 3); 244 *dstA = 255 - *(src + 3); 245 src += 4; 246 dstB += 3; 247 dstA += 1;
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c503b6eef32055f75dc9cf761bd20eda4f161dd4 tdf#160431 Inverts webp file image when inserted It will be available in 24.8.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/414d58e8fe8ecf545549dc960e1599b1035b7564 tdf#160431 Inverts webp file image when inserted It will be available in 24.2.4. 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.
That works for me! Well done. Thanks for fixing it so quickly!
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2-3": https://git.libreoffice.org/core/commit/1e8ac8b7c865d63014c6655e2e7e77979927c4f7 tdf#160431 Inverts webp file image when inserted It will be available in 24.2.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.