Bug 103833 - Mishandling in VLC of sRGB encoded bilevel PNG with OpenGL rendering--result in Black rectangle rather than bitmap image, also affects PDF export filters
Summary: Mishandling in VLC of sRGB encoded bilevel PNG with OpenGL rendering--result ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: All All
: low normal
Assignee: Not Assigned
: 89473 (view as bug list)
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
Reported: 2016-11-10 17:41 UTC by Timur
Modified: 2019-03-27 13:16 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:

Timur - Compare with LO versions (88.56 KB, image/jpeg)
2016-11-14 09:42 UTC, Timur
Timur - OpenGL report (162.39 KB, text/xml)
2016-11-14 09:43 UTC, Timur
tweakpng details for one of the images from attachment 113502 (16.81 KB, image/png)
2017-02-09 00:09 UTC, V Stuart Foote
tweakpng details for one of the images from attachment 131025 (23.17 KB, image/png)
2017-02-09 00:11 UTC, V Stuart Foote

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2016-11-10 17:41:26 UTC
Looks like regression from 5.2.1 from unknown bug with which Bug 77525 is also resolved. Bibisect could be useful. Tested in Windows.

Steps to Reproduce:
1. open attachment 113502 [details] from Bug 89473 

Actual Results:  
Images shown as black squares.

Expected Results:
Images shown normally.

Reproducible: Always

User Profile Reset: 

Additional Info:
1. Right click on the image and select "Compress Graphic"
2. In the Compress Graphic dialogue click "Calculate"

Should this be done automatically on fileopen?

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Comment 1 Xisco Faulí 2016-11-11 00:30:23 UTC
Confirmed when OpenGL is enabled

Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
CPU Threads: 4; OS Version: Linux 4.2; UI Render: GL; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 2 Xisco Faulí 2016-11-11 00:41:26 UTC
I can reproduce it in

Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: ca_ES
Comment 3 Timur 2016-11-14 09:42:16 UTC Comment hidden (no-value)
Comment 4 Timur 2016-11-14 09:43:08 UTC
Created attachment 128742 [details]
Timur - OpenGL report

Can the difference in version stem from OpenGL? I attach mine.
Comment 5 Timur 2016-11-17 08:46:16 UTC
Contrary to bug 77525, this was problem from 5.2.1. up to master 5.3, but then recently started to work again. 

Master tested with:
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-26 (works OK)
Build ID: bbd44f8f89839b5abb4ec6c7ea195431de5b2f48

TinderBox: Win-x86@39, Branch:master, Time: 2016-11-15 (problem again)
Build ID: 074f0ab1d76f16fe92493868e2f2de75e67792ef

Since flopping, I raise to "high". In bug 77525 I asked for bibisectRequest and that should reveal both.
Comment 6 Timur 2016-12-05 11:39:24 UTC
After driver reinstallation for AMD Radeon 6450, I have OpenGL blacklisted and I can't reproduce this, only if I force OpenGL.
Comment 7 V Stuart Foote 2017-02-07 16:34:44 UTC
Attachment 113502 [details] (from bug 89473) is a MS Word .doc file that contains a set of diagrams as PNG images.

Extracting the images, the ImageMagik "identify -verbose" shows them to be "Bilevel" with depth of 8/1-bit in sRGB color space--but with an alpha color, background color, and border color defined.

With OpenGL rendering enabled--inserting any of these odd PNGs to document canvas (Writer, Draw, Impress) renders each as a black rectangle.  While processing with GPU enabled, or just with CPU, the image is well formed to canvas--and on print/export.

Removing regression as this has clearly been an issue with our OpenGL rendering in VCL when implemented for 4.4.0

=-tested with-=
Windows 10 Pro 64-bit en-US
nVidia GTX 750Ti w/driver

Version: (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Build ID: 2670ca3fc597decae78499d1397539668eb84e5e
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-31_05:32:46
Locale: en-US (en_US); Calc: CL
Comment 8 V Stuart Foote 2017-02-07 18:41:31 UTC
At least easy to reproduce on Windows builds, extract the PNGs from attachement 113502 and insert into any new document. With OpenGL rendering enabled, result in the black rectangles for the images. With CPU, or GPU rendering--bitmaps are rendered to canvas no issue.

Not sure of behavior on Linux / macOS will check those a bit deeper. 

Sidebar question though is how unusual/broken is this set of PNGs? They seem kind of scarce.

@Tomaž, could you have a look?
Comment 9 V Stuart Foote 2017-02-08 23:54:10 UTC
*** Bug 89473 has been marked as a duplicate of this bug. ***
Comment 10 V Stuart Foote 2017-02-09 00:09:16 UTC
Created attachment 131026 [details]
tweakpng details for one of the images from attachment 113502 [details]

The tweakpng utility is a helpful validator, and shows the PNGs we are having issues with are 8bit, paletted "bilevel" PNG.

As here with PNG images extracted from attachment 113502 [details] and also now duplicated with attachment 131025 [details] "bilevel" PNG from dupe bug 89473
Comment 11 V Stuart Foote 2017-02-09 00:11:50 UTC
Created attachment 131027 [details]
tweakpng details for one of the images from attachment 131025 [details]

tweakpng shows this problem image is also 8bit, paletted with two colors--so another "bilevel" PNG.

Comment 12 ace_dent 2017-10-24 00:34:16 UTC
Hmmm... rendering PNGs is still tricky 11yrs later ;-) https://bz.apache.org/ooo/show_bug.cgi?id=60481
Comment 13 Luboš Luňák 2019-03-27 11:23:36 UTC
I can reproduce this with 6.1.something, but it works with with recent master, so apparently this has got fixed somewhen between 6.1 and 6.3. Closing.
Comment 14 Timur 2019-03-27 13:16:01 UTC
I confirm that it's OK with 6.3+ while not with 6.2.2. WFM then.