Bug 136012 - Regression: embedded png files look extremely bad in Impress 7.0.x, OK in 6.4.6
Summary: Regression: embedded png files look extremely bad in Impress 7.0.x, OK in 6.4.6
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-22 10:25 UTC by Callegar
Modified: 2020-09-25 23:37 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
File showing the issue (93.21 KB, application/vnd.oasis.opendocument.presentation)
2020-08-22 10:55 UTC, Callegar
Details
Screenshot on LibO 7 (269.90 KB, image/png)
2020-08-22 10:57 UTC, Callegar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2020-08-22 10:25:04 UTC
Description:
I am producing some slides with a university logo, which unfortunately I cannot share.

The logo is available both in SVG and PNG format (the latter at 2.5 x 2.5 cm, 300 dpi).

If I insert in the slides the SVG, this looks OK in edit mode, but bad-ish in presentation, both in LibO 6.4.6 and 7.0.1.1, because in presentation some thin lines disappear. So I decided to resort to the PNG.

If I insert the PNG "as is" (no scaling) it looks perfect in 6.4.6 and extremely bad (as if it was rescaled and an extremely bad resolution) in 7.0, either in edit and presentation mode. Interestingly:

- if I save the odp file and reopen it, then the file keeps opening with the png looking OK in 6.4.6 and bad in 7.0.

- if in 7.0 I play with the image compress dialog, at times I can make LibO 7.0 draw the PNG correctly, but typically it does not survive a save reload roundtrip.

I guess that impress caches images and uses the cached images for display. In LibO 7, my impression is that PNGs are rendered at the wrong resolution before caching.

I'll try to see if I can reproduce with another image that I can share to provide an example.

In the meantime, note that the quality of the PNGs in 7.0 is unfortunately so bad that if you run in a case where you have one image that is problematic with LibO 7.0, then impress 7.0 cannot be an option to deliver presentations at all.

Steps to Reproduce:
1. Open impress, create a new presentation
2. Insert a PNG image with small size, high resolution a lot of detail
See that it does not display acceptably in LibO 7 while it is OK in LibO 6.4.x

Actual Results:
Image does not display acceptably in LibO 7 while it is OK in LibO 6.4.x

Expected Results:
Image should always display well.


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: PresentationDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Comment 1 Callegar 2020-08-22 10:55:04 UTC
Created attachment 164557 [details]
File showing the issue
Comment 2 Callegar 2020-08-22 10:57:02 UTC
Created attachment 164558 [details]
Screenshot on LibO 7
Comment 3 Telesto 2020-08-22 18:19:59 UTC
No repro on Windows
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8700bace8c0714d853f5df6918ab9c8bb3d81f77
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Vulkan; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Which backend are we talking about? GTK3/QT/X11. Help/about would be helpful
Comment 4 Paul W. 2020-09-21 22:47:01 UTC
No repro on Windows
Version: 7.1.0.0.alpha0+ (x64)
OS: Win 10
Comment 5 Timur 2020-09-25 10:13:36 UTC
Sergio, you are a devoted reporter with 196 reports, so you should follow some rules, because otherwise you put a burden on QA volunteers. 
You have 85 new and fixed bugs, but 109 other bugs - meaning you should search more before reporting and follow your bugs.

With so many reports, you should always test with daily master from https://dev-builds.libreoffice.org/daily/master/current.html or easier from https://libreoffice.soluzioniopen.com/daily-version/.

Since you use Linux, for graphical issues you should also test with SAL_USE_VCLPLUGIN=gen path/to/soffice to see if UI AND with SAL_ENABLESKIA=1 SAL_USE_VCLPLUGIN=gen path/to/soffice to check Skia.

You should be concise and focused on a singe issue with steps. 
"note that the quality of the PNGs in 7.0 is unfortunately so bad that.." is useless, you should search for PNG bugs. 

"User Profile Reset" is there to try that before report and then write Yes. 

As for this bug, I also don't reproduce in Linux.
Comment 6 Callegar 2020-09-25 23:37:06 UTC
I apologize for the issues that I may have caused. I am really no devoted reporter, or at least I'd rather not be. I am a mere user of linux and LibO in a huge education institution that pays and gives for free MS Office to all its staff and students. While I see some value in exposing my colleagues and students to an open source tool, showing it can be used for our daily work, and occasionally trying to help them (e.g., attempting to make their problem into reproducible steps to report), this is not really my daily business or something that I earn from, rather an extra that often risks conflicting with my limited time resources. In this sense, it is also volunteer work. As such it is a bit striking to realize that it really ends up conflicting with other volunteer work in place of leading to something useful.

Testing with daily master is really impossible for me. Because the reporting is something I do at home, I cannot really afford downloading 300MB each time and the best I can do is testing on tip of still (on which I usually work) and of fresh (that I try early, to make sure I'll not encounter disruption when it gets still).

What I can certainly do is a bit more testing with other VCLs.

For the issue ad hand, I do not see it anymore on the test document either (now on 7.0.2.1).