Bug 86675 - Bad-quality antialiasing for PNG images, looks terribly ugly ..
Summary: Bad-quality antialiasing for PNG images, looks terribly ugly ..
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.6.2 release
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 82870 90536 92933 106415 106618 (view as bug list)
Depends on:
Blocks: Writer-Images VCL-OpenGL
  Show dependency treegraph
 
Reported: 2014-11-24 23:39 UTC by Thorsten Wagner
Modified: 2019-03-15 19:36 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot 1: LibreOffice 4.4.0 Beta 1 without antialiasing (181.63 KB, image/png)
2014-11-24 23:39 UTC, Thorsten Wagner
Details
Screenshot 2: LibreOffice 4.3.4 with antialiasing (217.31 KB, image/png)
2014-11-24 23:40 UTC, Thorsten Wagner
Details
screen print with image in three versions (311.68 KB, image/png)
2014-12-03 10:46 UTC, Cor Nouws
Details
Sample document (313.00 KB, application/vnd.oasis.opendocument.text)
2014-12-31 06:56 UTC, Matthew Francis
Details
Before and after screenshots (681.26 KB, image/png)
2014-12-31 06:57 UTC, Matthew Francis
Details
Version: 4.4.2.1 - bug persists (127.25 KB, image/jpeg)
2015-03-20 09:27 UTC, Bat1
Details
screen shot from Daily20150330 (138.19 KB, image/png)
2015-04-13 07:39 UTC, Cor Nouws
Details
another screen shot showing 442 and 45 master (184.19 KB, image/png)
2015-04-13 10:30 UTC, Cor Nouws
Details
screenshot with three LibreOffice versions (141.49 KB, image/png)
2015-05-22 15:47 UTC, Cor Nouws
Details
sample with various PNG and JPEG images (572.15 KB, application/vnd.oasis.opendocument.text)
2015-08-07 22:46 UTC, Jeff Fortin Tam
Details
Additional example (2.24 MB, application/vnd.oasis.opendocument.graphics)
2017-04-30 09:31 UTC, Telesto
Details
Screenshot (231.74 KB, image/png)
2019-02-06 13:18 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Wagner 2014-11-24 23:39:31 UTC
Created attachment 109968 [details]
Screenshot 1: LibreOffice 4.4.0 Beta 1 without antialiasing

PNG images are displayed without antialiasing (see attached screenshot 1). The problem exists in all applications (Writer, Calc, Impress, etc.).

The problem appears on Mac OS X 10.9.5 with LibreOffice 4.4.0 Beta 1. It is not present in LibreOffice 4.3.4 (see screenshot 2).
Comment 1 Thorsten Wagner 2014-11-24 23:40:30 UTC
Created attachment 109969 [details]
Screenshot 2: LibreOffice 4.3.4 with antialiasing
Comment 2 Adolfo Jayme Barrientos 2014-11-26 00:52:08 UTC
This is not a blocker. The reduced-quality antialiasing was enabled because of performance reasons AFAIK.
Comment 3 Thorsten Wagner 2014-11-26 01:40:33 UTC
Without antialiasing PNG images are looking very ugly. It would be very nice to reenable good quality antialising or to get the information how to do it.

As bad quality rendering is not state of the art today, I recommend to deal with it as a blocker for releasing LibreOffice 4.4 - expecially compared with LibreOffice 4.3.4.
Comment 4 Cor Nouws 2014-11-27 10:08:08 UTC
(In reply to Adolfo Jayme from comment #2)
> This is not a blocker. The reduced-quality antialiasing was enabled because
> of performance reasons AFAIK.

@Adolfo: I'm quite shocked when I paste an image in draw :\
Really looks bad.
We must be sure what is going on here, IMO.
Comment 5 Thorsten Wagner 2014-11-29 23:30:44 UTC
I doublechecked bad performace with image processing with the following results using LibreOffice 4.3.4 and Writer:

(1) Indeed performance of image handling is bad with larger images. It's not possible to scroll without bucking.

(2) Performance issues exist with PNG images as well as with other image formats too, e.g. JPEG.

With the same files (and images) no performance issus exist with AOO 4.1.1. Maybe a look at according AOO code makes sense.
Comment 6 Cor Nouws 2014-12-03 10:46:00 UTC
Created attachment 110400 [details]
screen print with image in three versions

For reference a screen print.
From what I understood, developers are working on OpenGL stuff currently, which is where this has to be fixed.
Comment 7 Matthew Francis 2014-12-30 06:50:09 UTC
The behaviour changed as of the below commit. Despite the discussion above, the commit message doesn't make it sound like decreased quality was an intended side effect or trade-off.

Adding Cc: to quikee@gmail.com (Tomaž Vajngerl). Could you possibly comment on this one? Thanks


commit 1b23e46051d8cc7c01fd8b4d0ea51bfec145db8e
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Date:   Sat May 31 21:03:34 2014 +0200

    vcl: Refactor scale "super" out of bitmap and make it independent
    
    Introduce BitmapFilter as a general bitmap filtering class, and
    make scale "super" algorithem independent as BitmapScaleSuper
    which uses BitmapFilter as superclass.
    
    This is an ongoing work to make some bitmap algorithms structured
    and more independent from the big bitmap class This will make them
    easier to work with, test and optimize.
    
    Change-Id: I37d29709b2af95cab2f6da21129302f5be79318b
Comment 8 Tomaz Vajngerl 2014-12-31 05:31:23 UTC
The commit in question just refactors the "super" bitmap scaler out of Bitmap to its own class. It is possible that I made a mistake and produced a bug when refactoring, but I don't see any difference in image scaling between 4.3.4 and 4.4 RC1 or master (tested on Linux). An example document would be helpful.
Comment 9 Matthew Francis 2014-12-31 06:56:23 UTC
Created attachment 111556 [details]
Sample document
Comment 10 Matthew Francis 2014-12-31 06:57:12 UTC
Created attachment 111557 [details]
Before and after screenshots
Comment 11 Matthew Francis 2014-12-31 07:01:31 UTC
(In reply to Tomaz Vajngerl from comment #8)

Please see the attached sample document and screenshots (attachment 111556 [details] and attachment 111557 [details]).

The screenshots are from builds exactly at (right) and one commit before (left) the commit I mentioned above. Current master still looks like the shot on the right to me.
Comment 12 Matthew Francis 2015-01-01 04:38:04 UTC
*** Bug 82870 has been marked as a duplicate of this bug. ***
Comment 13 Yousuf Philips (jay) (retired) 2015-01-01 09:16:58 UTC
@Matthew: My bug seems different then this as the problem in my bug is between 4.1 and 4.2+ as shown attachment 104986 [details].
Comment 14 Thorsten Wagner 2015-01-01 12:19:16 UTC
Unfortunately the problem shown in sceenshots 1 und 2 still exists using the current master.
Comment 15 Tomaz Vajngerl 2015-01-01 12:31:05 UTC
Ups.. I commited a fix under fdo#82870 and not this bug as I intended. Still this requires an explanation as it doesn't actually fix this or fdo#82879 bug.

There indeed was a bug in scale super which made "bilinear" scaling into "nearest neighbor" like scaling introduced in [1] but in a later commit [2] we reverted the fix that pre-scaled the images with our built-in scaler - instead of that a fast native "nearest neighbor" scaler is used. So indeed this is the issue Adolfo was talking about which now makes this bug a duplicate of [3]. 

I fixed the issue with super scaler in master by first reverting [2] and looking for the cause of the low quality. 

fdo#82870 is also a duplicate of this and [3] bug.. 

[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b23e46051d8cc7c01fd8b4d0ea51bfec145db8e

[2] http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee36fc7add892690c95a969530ecdcfc1bc9decc

[3] https://bugs.freedesktop.org/show_bug.cgi?id=74124
Comment 16 Jan Holesovsky 2015-01-01 17:34:54 UTC
Tomaž: Let me dump some thoughts here...  The cause is the code at

http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/outdev/bitmap.cxx#n672

This started being used a lot after one of the Armin's/drawinglayer commits.  I tried to work that around by

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3cf3700b7a903e88f5296076c40ae854bce91cdc ,

but that's not the correct fix here, and I'd avoid reverting

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

Luckily the situation should be better at least on Windows now after

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

and follow-up commits in this area, because now we use the native scaling and alpha rendering much more; but I guess on Linux it is still bad :-(

So if you can make the code around bitmap.cxx:672 using some better scaling algorithm while it still remains fast (enough), that would be awesome :-)  The ultimate solution would be that the drawinglayer would cache the scaled images, and consequently we wouldn't have to do any scaling here at all, but that's a big change...

Hope this helps - thanks so much for looking at this!
Comment 17 Yousuf Philips (jay) (retired) 2015-01-02 21:19:08 UTC
*** Bug 82870 has been marked as a duplicate of this bug. ***
Comment 18 Bat1 2015-03-20 09:27:14 UTC
Created attachment 114206 [details]
Version: 4.4.2.1 - bug persists

Version: 4.4.2.1
ID: 93fc8832889bf050a10ec6d0171dae213adc9b55
ru_RU

bug persists
Comment 19 Bat1 2015-03-20 09:27:59 UTC
Version: 4.4.2.1
ID: 93fc8832889bf050a10ec6d0171dae213adc9b55
ru_RU

bug persists (screenshot attached)
Comment 20 Matthew Francis 2015-04-13 05:04:39 UTC
*** Bug 90536 has been marked as a duplicate of this bug. ***
Comment 21 Cor Nouws 2015-04-13 07:39:17 UTC
Created attachment 114754 [details]
screen shot from Daily20150330

The bug does not appear in master
Version: 4.5.0.0.alpha0+
Build ID: 9efd80ac32a80656ed6482df69615227d12bc6d9
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-30_16:43:31
Locale: nl_NL

Would be lovely to have some 4.4.x version that is back normal too :)
Comment 22 Yousuf Philips (jay) (retired) 2015-04-13 08:45:27 UTC
(In reply to Cor Nouws from comment #21)

Still available in master as seen in attachment 114706 [details]. It has to be tried on a resized image Cor. :D
Comment 23 Cor Nouws 2015-04-13 10:30:43 UTC
Created attachment 114757 [details]
another screen shot showing 442 and 45 master

(In reply to Jay Philips from comment #22)
> Still available in master as seen in attachment 114706 [details]. It has to
> be tried on a resized image Cor. :D

Not for me Jay.
The broken display from 4.4.2 is definitely gone in 4.5 master
Comment 24 Yousuf Philips (jay) (retired) 2015-04-13 12:49:55 UTC
(In reply to Cor Nouws from comment #23)
> Created attachment 114757 [details]
> another screen shot showing 442 and 45 master

Not sure what i'm seeing in the screenshot as there seems to be one image in 4.4 and two images in 4.5. Maybe you can upload your doc so we can test the same and include screenshots.
Comment 25 Cor Nouws 2015-04-13 13:30:17 UTC
(In reply to Jay Philips from comment #24)
> Not sure what i'm seeing in the screenshot as there seems to be one image in
> 4.4 and two images in 4.5. 

In 4.4 it i not resized. In 4.5 one is resized and one not.

> Maybe you can upload your doc so we can test the
same and include screenshots.

I have no test document. Just make a print from part of the screen and paste it in Writer.
Did the same for attachment https://bugs.documentfoundation.org/attachment.cgi?id=110400 (comment#6)
Comment 26 Thorsten Wagner 2015-04-13 21:32:31 UTC
Retesting with current revision from master the problem still exists. Further investigations show that bad quality only occurs with PNG images including an alpha channel. Images without alpha channel seem to be rendered properly.
Comment 27 Cor Nouws 2015-05-22 15:47:11 UTC
Created attachment 115835 [details]
screenshot with three LibreOffice versions

A document with a png opened in three LibreOffice versions.
Looks fine in 5.0.0.beta1 (as in 4.3.7.2)
But 4.4.3.2 still horrible.
Comment 28 V Stuart Foote 2015-07-30 22:20:02 UTC
*** Bug 92933 has been marked as a duplicate of this bug. ***
Comment 29 Gerhard Schaber 2015-07-31 18:17:41 UTC
Can this be back ported to 4.4? It seems that also JPG images are affected.
Comment 30 Jeff Fortin Tam 2015-08-07 22:46:04 UTC
Created attachment 117761 [details]
sample with various PNG and JPEG images

I'm seeing this in all versions: 4.4.4.3, 5.0 (final) and the opengl-enabled git version that Markus was running in front of me today. Attached here is a sample file I made containing various images that have text, which makes it easy to spot bad scaling. When you export the document to PDF, the resulting PDF looks great when viewed in Evince. The images only look terrible in live view in Writer (or Impress, or any component).
Comment 31 Jeff Fortin Tam 2015-08-07 22:48:06 UTC
To add to my previous comment: I can understand having crappy scaling in a non-accelerated renderer, but I would expect nice scaling in the upcoming opengl version (at least bicubic)
Comment 32 Cor Nouws 2015-11-26 14:15:36 UTC
Still a problem in 4.4.x
I assume this issue is going to die when 4.4 is end of file.
Comment 33 Robinson Tryon (qubit) 2015-12-13 11:10:56 UTC Comment hidden (obsolete)
Comment 34 Oystein Sture 2016-03-04 10:54:29 UTC
Still a problem with libreoffice 5.1.0.3 on Windows 10. Zooming in/out to anything other than the native size. Bilinear or bicubic interpolation would make wonders.
Comment 35 Aron Budea 2016-08-26 02:58:59 UTC
Attachment #10 ( sample with various PNG and JPEG images):

-looks nice in v5.2.1.1/Windows 7 with OpenGL turned off,
-looks terrible with OpenGL turned on.
Comment 36 Xisco Faulí 2016-09-26 15:09:38 UTC
Adding Cc: to Tomaž Vajngerl
Comment 37 Aron Budea 2016-11-12 23:38:25 UTC
Looks pretty good to me with v5.2.3.3 / Windows 7, OpenGL enabled, too.

Can others who experienced quality issues test this?
Comment 38 Cor Nouws 2016-12-05 21:28:44 UTC
(In reply to Aron Budea from comment #37)
> Looks pretty good to me with v5.2.3.3 / Windows 7, OpenGL enabled, too.
> 
> Can others who experienced quality issues test this?

in Version: 5.4.0.0.alpha0+
Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-01_23:51:31
Locale: nl-NL (nl_NL.UTF-8); Calc: group

I take screen shot from Styles and Formatting, paste in Writer doc.. result still ugly
Comment 39 Aron Budea 2016-12-05 22:07:01 UTC
(In reply to Cor Nouws from comment #38)
> I take screen shot from Styles and Formatting, paste in Writer doc.. result
> still ugly

Indeed, still not okay.

In Windows 7:
-with default rendering it looks fine at all zoom levels,
-with GL rendering it looks fine until zoom level 220%, but looks bad when zoomed in to 250%.

In Linux:
-with default rendering it looks fine until zoom level 220%, but looks bad when zoomed in to 250%,
-can't test with GL rendering.
Comment 40 Buovjaga 2017-03-11 20:24:16 UTC
*** Bug 106415 has been marked as a duplicate of this bug. ***
Comment 41 Regina Henschel 2017-03-18 14:26:26 UTC
*** Bug 106618 has been marked as a duplicate of this bug. ***
Comment 42 Xisco Faulí 2017-03-20 15:49:00 UTC Comment hidden (obsolete)
Comment 43 Telesto 2017-04-30 09:31:33 UTC
Created attachment 132970 [details]
Additional example
Comment 44 Cor Nouws 2017-04-30 12:36:46 UTC
(In reply to Telesto from comment #43)
> Created attachment 132970 [details]
> Additional example

Shrug :(
Comment 45 David Novák 2017-11-03 08:13:32 UTC
Just encountered this.. WTH?

How can I recommend LO to anyone if default settings on Windows creates terribly ugly text in PNG? On Linux, everything is nice and working.
Comment 46 Roman Kuznetsov 2017-11-29 20:19:36 UTC
still repro in 6.0 beta1
on Windows 7 without OpenGL - looks OK
on Windows 7 with OpenGL - looks bad
on Xubuntu 16.10 without! OpenGL - looks bad!

AMD HD6450 with last drivers in Windows and with opensource driver in Xubuntu
Comment 47 Telesto 2018-07-07 08:08:00 UTC
Still repro

based on attachment 132970 [details] (Draw)
with OpenGL - looks ok
without OpenGL - looks bad (and rather slow; Hi-res images)

based on screen shot from Styles and Formatting (Writer)
with OpenGL - bad
without OpenGL - looks ok (and rather slow; Hi-res images)

Version: 6.2.0.0.alpha0+
Build ID: bb1d5780226bb1b9156580972eea9aa849178742
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-07-03_05:56:48
Locale: nl-NL (nl_NL); Calc: C
Comment 48 Thorsten Wagner 2018-07-09 20:47:42 UTC
Issue is still present using macOS with LO from master:

macOS with Open GL:    bad
macOS without Open GL: bad
Linux:                 good

PNG portion of thumbnail image looks bad with macOS (with and without Open GL) as well as with Linux.

JPEG portion of drawing looks good in all cases and within main window as well as within thumbnail bar.
Comment 49 bunkem 2018-08-22 17:42:34 UTC Comment hidden (obsolete)
Comment 50 Cor Nouws 2019-02-06 12:20:10 UTC
dear people,

I tend to close this one as resolved. The initial problem does not exist any more for at least on Linux. And influence from openGL, as given by some, I don't see either.
So there still seem to be problems, but different then initial one.

More specific:
If I create an image as I did here:
(In reply to Cor Nouws from comment #6)
> Created attachment 110400 [details]
> screen print with image in three versions
it is now fine (63 master)

(In reply to Telesto from comment #43)
> Created attachment 132970 [details]
> Additional example
Booth jpg (left) and png image look nice, also with openGL, also at 300%

So the initial problem is the summary: "Bad-quality antialiasing for PNG images, looks terribly ugly"
Thus I started Writer, took screenshot of Stylist and pasted that. Was really ugly; is just fine.
Has anyone still that effect?
Comment 51 Telesto 2019-02-06 13:18:28 UTC
Created attachment 148952 [details]
Screenshot

(In reply to Cor Nouws from comment #50)
I still repro this. Only without OpenGL enabled. It's depending on the amount of scaling of the image & zoom-level. Would prefer a clean bug report though..
Comment 52 Cor Nouws 2019-02-06 13:23:02 UTC
(In reply to Telesto from comment #51)
> Created attachment 148952 [details]
> Screenshot
On my screen, the image left on the screen print is less clear than the one right. Correct?
Comment 53 Cor Nouws 2019-02-06 13:26:16 UTC
(In reply to Cor Nouws from comment #52)
> On my screen, the image left on the screen print is less clear than the one
> right. Correct?
though a tiny bit.
And - contrary to the Draw example from comment #43 - the png is left? :)
Comment 54 Telesto 2019-02-06 15:13:42 UTC
(In reply to Cor Nouws from comment #53)
> (In reply to Cor Nouws from comment #52)
> > On my screen, the image left on the screen print is less clear than the one
> > right. Correct?
> though a tiny bit.
> And - contrary to the Draw example from comment #43 - the png is left? :)

True. I tested it in Writer, to be sure, and swapped both images. Anyhow, this proofs the issue is still visible :-)
Comment 55 Cor Nouws 2019-02-06 23:17:01 UTC
(In reply to Telesto from comment #54)
> True. I tested it in Writer, to be sure, and swapped both images. Anyhow,
> this proofs the issue is still visible :-)
Wow... smart test! :)
But I also understand you agree that it's different (in effect and in cause) from this original bug. Can you then please close this one and write a new bug?
Comment 56 Cor Nouws 2019-02-11 14:48:06 UTC
(In reply to Cor Nouws from comment #50)
> I tend to close this one as resolved. The initial problem does not exist any
> ...
Doing so now!

(In reply to Telesto from comment #51)
> ...
> amount of scaling of the image & zoom-level. Would prefer a clean bug report
> though..
Anyone please do so: one bug per report as much as possible of course.
And please mention the bug number here.
thanks a lot!