Bug 161498 - autocontour function is broken (does not take into account PNG transparency)
Summary: autocontour function is broken (does not take into account PNG transparency)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: high normal
Assignee: Patrick (volunteer)
URL:
Whiteboard: target:25.2.0 target:24.2.5 target:24...
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Contour-Editor
  Show dependency treegraph
 
Reported: 2024-06-10 16:17 UTC by pieter kristensen
Modified: 2024-07-17 00:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
to the autocontour function is rectangular (2.49 MB, image/png)
2024-06-10 16:21 UTC, pieter kristensen
Details
image with 100% transparent border. Text wrap contour activated. (788.82 KB, image/jpeg)
2024-06-11 05:25 UTC, pieter kristensen
Details
contour function imho completely working as expected (1.20 MB, image/jpeg)
2024-06-28 05:15 UTC, pieter kristensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pieter kristensen 2024-06-10 16:17:21 UTC
Description:
I insert an png-image in a Writer file with big transparent (alpha channel Gimp) borders.
Then I right-click on it and choose /line wrap/contour from the context-menu. Now LibreOffice used to understand that the 100% transparent borders could be overwritten with text. But it doesn't understand that no more. All images stay rectangular the way the were in the first place.
Then I start the "contour editor" and start autocontour. That also does nothing. 

Steps to Reproduce:
1. try to contour wrap
2. LO doesn't guess contour at first site no more
3. Contour editor auto function also broken

Actual Results:
All images keep their original rectangular contour. In other words contour wrap does nothing

Expected Results:
Libreoffice tries to guess contour to wrap. This used to work fine. In all other cases the contour editor could help but the "auto" function of that seems to be totally broken


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL
Ubuntu package version: 4:24.2.4~rc2-0ubuntu0.22.04.1~lo1
Calc: threaded

Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.5.0-35-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Manufacturer: Dell Inc.
Product Name: Latitude 5480
Comment 1 pieter kristensen 2024-06-10 16:21:12 UTC
Created attachment 194634 [details]
to the autocontour function is rectangular

I selected an elips in this image in Gimp. Then I inverted the selection and removed the border.
I added an alpha channel layer and saved it as png.
Contour wrap sees the image as rectangular.
Comment 2 pieter kristensen 2024-06-11 05:18:46 UTC
I tried on a Windows machine with a recent version of LibreOffice. It behaved the same as my linux machine. 
No autocontour function.
Comment 3 pieter kristensen 2024-06-11 05:25:32 UTC
Created attachment 194638 [details]
image with 100% transparent border. Text wrap contour activated.

This is a screenshot of LO with an inserted image with 100% transparent border and 0% transparent center.
LO sees this image as rectangular.
Years ago I also worked with this functionality and then LO behaved as expected and wrapped the text around the ellipse.
Comment 4 Stéphane Guillou (stragu) 2024-06-25 16:35:11 UTC
Thanks for the report, I can see that regression.

In LO 7.6, using Wrap > Edit contour > Autocontour allows wrapping around the oval area.

Version: 7.6.7.2 (X86_64) / LibreOffice Community
Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

It does not work anymore in:

Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded
Comment 5 Patrick (volunteer) 2024-06-26 17:04:09 UTC
I can also reproduce this on macOS in my local master build:

Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 68e7413b5f9ce4abd2a4e23bf27cfc335e52f03f
CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

I am curious if a bibisect points to the switch from transparency to alpha in bitmaps that was added in 24.2.
Comment 6 Patrick (volunteer) 2024-06-27 00:06:28 UTC
(In reply to Patrick Luby (volunteer) from comment #5)
> I am curious if a bibisect points to the switch from transparency to alpha
> in bitmaps that was added in 24.2.

Did a git bisect and looks like that is the cause:
 81994cb2b8b32453a92bcb011830fcb884f22ff3 is the first bad commit
commit 81994cb2b8b32453a92bcb011830fcb884f22ff3
Author: Noel Grandin <noelgrandin@gmail.com>
Date:   Fri Apr 16 20:33:10 2021 +0200

I am guessing that somewhere in the LibreOffice code, the pixels in the image are examined and the transparent pixels identified (i.e. create an alpha mask). But the transparency values are now flipped so the existing code sees the opaque image area as transparent and the transparent image area as opaque.

I don't know where the code is so I will see if can locate the code that handle's finding the image's transparent area. I'll post again when I have more news.
Comment 7 Stéphane Guillou (stragu) 2024-06-27 08:56:00 UTC
(In reply to Patrick Luby (volunteer) from comment #6)
> (In reply to Patrick Luby (volunteer) from comment #5)
> > I am curious if a bibisect points to the switch from transparency to alpha
> > in bitmaps that was added in 24.2.
> 
> Did a git bisect and looks like that is the cause:
>  81994cb2b8b32453a92bcb011830fcb884f22ff3
Confirmed that it started with 81994cb2b8b32453a92bcb011830fcb884f22ff3 (build [c21a1c45e2403119c90af25cdb5350f978d5c93b] in linux-64-24.2 bibisect repo).

Thanks for looking into it, Patrick.
Comment 8 Patrick (volunteer) 2024-06-27 15:21:35 UTC
(In reply to Patrick Luby (volunteer) from comment #6)
> I am guessing that somewhere in the LibreOffice code, the pixels in the
> image are examined and the transparent pixels identified (i.e. create an
> alpha mask). But the transparency values are now flipped so the existing
> code sees the opaque image area as transparent and the transparent image
> area as opaque.

I think that I have found the code and I have submitted the following patch:

https://gerrit.libreoffice.org/c/core/+/169654
Comment 9 Commit Notification 2024-06-27 20:32:45 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1ac602f6ccd75f3b79d6c7a9d40e64677dd5741a

tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels

It will be available in 25.2.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.
Comment 10 Patrick (volunteer) 2024-06-27 20:41:18 UTC
I have committed a fix this bug. The fix should be in tomorrow's (28 June 2024) nightly master builds:

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev:

xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Comment 11 Commit Notification 2024-06-27 22:34:03 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/8590499c1f382244155624cd3f712d0894faaa2b

tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels

It will be available in 24.2.5.

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.
Comment 12 pieter kristensen 2024-06-28 05:15:33 UTC
Created attachment 195030 [details]
contour function imho completely working as expected

The contour function is now working as expected. But scrolling in the document of the screenshot really goes slow. And that doesn't change when I not use the contour function.
(I hope the qt6 vcl plugin will be in master soon!)
Comment 13 Commit Notification 2024-06-28 11:35:48 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/bed03b80139322dc361291eed76345acc8be9e5c

tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels

It will be available in 24.8.0.0.beta2.

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.
Comment 14 Patrick (volunteer) 2024-06-28 11:53:20 UTC
(In reply to pieter kristensen from comment #12)
> Created attachment 195030 [details]
> contour function imho completely working as expected
> 
> The contour function is now working as expected. But scrolling in the
> document of the screenshot really goes slow. And that doesn't change when I
> not use the contour function.
> (I hope the qt6 vcl plugin will be in master soon!)

I don't see this. On macOS when scrolling using the trackpad or dragging the scrollbar through the wrapped image. So that sounds like a separate, Linux-only bug. But I am not a Linux developer so I don't know.
Comment 15 pieter kristensen 2024-06-28 12:02:56 UTC
(In reply to Patrick Luby (volunteer) from comment #14)
> (In reply to pieter kristensen from comment #12)
> > Created attachment 195030 [details]
> > contour function imho completely working as expected
> > 
> > The contour function is now working as expected. But scrolling in the
> > document of the screenshot really goes slow. And that doesn't change when I
> > not use the contour function.
> > (I hope the qt6 vcl plugin will be in master soon!)
> 
> I don't see this. On macOS when scrolling using the trackpad or dragging the
> scrollbar through the wrapped image. So that sounds like a separate,
> Linux-only bug. But I am not a Linux developer so I don't know.

Thank you for your reply. LibreOffice is great!