Bug 113918 - 1bpp non-B&W PNG images are mishandled on Linux in all vcl "backends" ("plugins")
Summary: 1bpp non-B&W PNG images are mishandled on Linux in all vcl "backends" ("plugi...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0 target:5.4.4
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-18 16:24 UTC by Tor Lillqvist
Modified: 2018-02-22 14:34 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bug doc (27.78 KB, application/vnd.oasis.opendocument.text)
2017-11-18 16:26 UTC, Tor Lillqvist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Lillqvist 2017-11-18 16:24:51 UTC
Description:
Open attached document on Windows, it shows up in Writer correctly: An empty page with an image that has some grey text on white background. That the image has text is irrelevant, it could be any image, the relevant detail is that the image (a PNG file) is one bit per pixel, i.e. two colours. but not black and white, but grey and white.

On Linux, depending on which VCL "backend" (of "plugin" as they also are called) is used, it either doesn't show at all, the text shows up as black and the background as white, or even the text as black and the background as grey. Not even funny. 

Steps to Reproduce:
.

Actual Results:  
.

Expected Results:
.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0.1 Safari/604.3.5
Comment 1 Tor Lillqvist 2017-11-18 16:26:20 UTC
Created attachment 137842 [details]
bug doc
Comment 2 Tor Lillqvist 2017-11-18 16:26:59 UTC
Seems to work correctly on macOS, too.
Comment 3 Buovjaga 2017-11-18 16:44:49 UTC
kde4, gtk2, gen: doesn't show anything.
gtk3: black text on grey bg

Arch Linux 64-bit
Version: 6.0.0.0.alpha1+
Build ID: 121303615054568c204def97872343d2014af4a0
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 17th 2017
Comment 4 Tor Lillqvist 2017-11-18 17:08:59 UTC
I spent a day trying to understand what goes wrong. Added tons of debugging printouts to the relevant places in VCL. No cigar. I think it will be much easier to just add a workaround: When loading this kind of PNG images into LO, convert them into normal 24bpp non-palettized ones... (with each pixel then being either of the two in the original image's palette).

LO is not some image manipulation software that would need to be able store any esoteric "mode" image exactly internally. This kind of PNG images are presumably fairly rare. And anyway, in this day, images with higher colour depth than 8 bits, or even "HDR" images, are gaining in importance and use, and LO doesn't handle such either. Converting to a normal full-colour image will take more space, sure, but that is outweighed by the benefit of fixing the problem.
Comment 5 Tor Lillqvist 2017-11-18 17:10:43 UTC
Also, storing all images internally in LO as either 24bpp full-colour of 8bpp full-greyscale is where many developers want to go anyway. Death to palettized images!
Comment 6 V Stuart Foote 2017-11-18 18:33:23 UTC
There have been issues with Windows handling as well, though the bilevel PNG of the bug doc here does render to canvas and export to PDF with 5.4.3 Windows build. Some other examples in the bug 103833 see also and dupes.
Comment 7 Tor Lillqvist 2017-11-18 22:46:04 UTC
I wrote:
> I think it will be much easier to just add a workaround

... but of course, it wasn't "easy". Not sure if I will bother trying that approach any more. Just need to debug the actual issue harder. Next week.
Comment 8 Commit Notification 2017-11-20 16:00:08 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=66dbd4da3afcadb1393daf9be9cecff71b86509a

tdf#113918: Workaround: Load 1bpp indexed PNG as 8bpp indexed Bitmap

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2017-11-24 16:23:43 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a53f646df5d295ed5ab21fa1ac467694160cf1f&h=libreoffice-5-4

tdf#113918: Workaround: Load 1bpp indexed PNG as 8bpp indexed Bitmap

It will be available in 5.4.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Xisco Faulí 2017-12-25 14:39:25 UTC
A polite ping to Tor Lillqvist: is this bug fixed? if so, could you
please close it as RESOLVED FIXED ? Thanks
Comment 11 Tor Lillqvist 2017-12-25 20:40:49 UTC
I would say so, yes.
Comment 12 Tor Lillqvist 2017-12-25 20:42:02 UTC
(Even if I did not actually fix the problem, but instead implement a workaround... No doubt some day somebody will complain that the workaround wastes memory (as it does). So sue me.)