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).
Created attachment 109969 [details] Screenshot 2: LibreOffice 4.3.4 with antialiasing
This is not a blocker. The reduced-quality antialiasing was enabled because of performance reasons AFAIK.
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.
(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.
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.
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.
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
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.
Created attachment 111556 [details] Sample document
Created attachment 111557 [details] Before and after screenshots
(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.
*** Bug 82870 has been marked as a duplicate of this bug. ***
@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].
Unfortunately the problem shown in sceenshots 1 und 2 still exists using the current master.
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
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!
Created attachment 114206 [details] Version: 4.4.2.1 - bug persists Version: 4.4.2.1 ID: 93fc8832889bf050a10ec6d0171dae213adc9b55 ru_RU bug persists
Version: 4.4.2.1 ID: 93fc8832889bf050a10ec6d0171dae213adc9b55 ru_RU bug persists (screenshot attached)
*** Bug 90536 has been marked as a duplicate of this bug. ***
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 :)
(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
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
(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.
(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)
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.
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.
*** Bug 92933 has been marked as a duplicate of this bug. ***
Can this be back ported to 4.4? It seems that also JPG images are affected.
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).
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)
Still a problem in 4.4.x I assume this issue is going to die when 4.4 is end of file.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
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.
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.
Adding Cc: to Tomaž Vajngerl
Looks pretty good to me with v5.2.3.3 / Windows 7, OpenGL enabled, too. Can others who experienced quality issues test this?
(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
(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.
*** Bug 106415 has been marked as a duplicate of this bug. ***
*** Bug 106618 has been marked as a duplicate of this bug. ***
Created attachment 132970 [details] Additional example
(In reply to Telesto from comment #43) > Created attachment 132970 [details] > Additional example Shrug :(
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.
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
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
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.
I've been watching this thread. 1) Another issue with this is that the Insert:Image of a jpg, gif, png alters the colour. (Macos 10.11.6 with LO6.2a master (Aug 8-13) and, 2) The colour import is OK for an eps image but that image only shows up for a while until it disappears and only a box placeholder + note about the name of the image file is available. When attempting to print or export to PDF, the image has disappeared.
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?
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..
(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?
(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? :)
(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 :-)
(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?
(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!