Description: I build book covers using LO Draw and save them out as PNG files. This bug, apparently new in 7.0.0.0, kills that. All my existing LO book cover templates are absolutely total crap now. I really don't feel like having to find a new program to do them in at this point. That's a lot of rework. In 7.0.0.0 beta v2, when a transparent object, like a title shade box, is placed over an image, LO Draw now assigns the underlying picture the same transparency property as the object on top of it. BAD. Steps to Reproduce: 1. Launch LO Draw. 2. Paste a photo onto the canvas. 3. Draw a geometrical shape, like a square, on top of the photo. 4. Set the transparency property of the geometrical shape to solid 40%. 5. Export the page as PNG. Actual Results: The entire canvas is rendered as dark as the transparent object. Doesn't even matter if the transparent object is not black. A pink transparent object will produce the exact same darkening of the underlying photograph. Expected Results: The underlying image should not be affected by the properties of any object on top of it. I am using hardware rendering, not SKIA, because SKIA is too slow with high-resolution images and zooming in and out with SKIA is pure death. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 8; OS: Windows 10.0 Build 20150; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 162279 [details] LO Draw file containing 2 slides, one with a transparency. This is a mock-up of a cover. Actual covers are far more complicated, but I just created enough of one to get the point across. The first slide has no transparency set on the title bar at the bottom and exports as PNG normally. The second slide's title bar at the bottom of the book cover has a solid 40% transparency on it. That property subsequently is applied to the underlying photograph when the image is exported as a PNG.
Created attachment 162280 [details] This slide's appearance is what is expected upon PNG export. This is an export of the first slide of the LO Draw file attached to this submission.
Created attachment 162281 [details] Unacceptable PNG output with a transparent object This is the second slide in the LO Draw document attached to this bug submission as output as PNG. The result is unacceptable. It's quite obvious what happened, when you compare the 2nd page in LO draw with this output, is that the underlying photograph has been assigned the same transparency property as the object on top of it.
(In reply to mwtjunkmail from comment #3) I am using hardware rendering, not SKIA, because SKIA is too slow with high-resolution images and zooming in and out with SKIA is pure death. Please create a bug report for this
I hope this graphical bug doesn't take as long as this one https://bugs.documentfoundation.org/show_bug.cgi?id=123973 to get addressed, which I logged back in March of 2019 and STILL hasn't been touched because of the huge backlog of graphical problems. This transparency issue really sucks, and considering that this is a new version of LO going out, shouldn't involve such problems.
The work around is to export as TIFF, and then go into some other program and convert the TIFF file to PNG (the final program that needs what I create in LO Draw can't read TIFF, just PNG). So me and everyone who has ever downloaded my carefully crafted LO Draw templates containing transparent effects: https://i.imgur.com/d21po0Z.png must now wait an interminable amount of time before jumping on the 7.0x LO bandwagon when this bug is fixed, or forever remain on 6.4.x and employ an extra step post-production to convert the images to PNG.
Created attachment 162434 [details] smaple cover with text and transparent backing moved to new layer So for OP, if your sample attachment 162279 [details] is an indicator of how you have been doing your layouts, why are you not placing the cover text with transparency into a layer of its own? When I do so, moving the Draw Text box, and rectangular shapes into a new layer. Setting Z-order with an Arrangement action, so Text box is on top of its backing shape and the base image is on the bottom--I get correct transparency of just the title backing. So, is it a simple layering issue?
Can't tell if this is intentional. But confirm export to PNG of transparent Draw shapes changed from 6.4 -> 7.0 If intentional need documentation change guiding use of additional layers when set transparent over default Layout layer.
(In reply to V Stuart Foote from comment #7) > why are you not placing the cover text > with transparency into a layer of its own? The position of the gray box is not always going to be 1:1 with the text within it, and by design, the final product very well have a vector-converted set of text that extended well above and below that transparent box.
(In reply to mwtjunkmail from comment #9) > (In reply to V Stuart Foote from comment #7) > > why are you not placing the cover text > > with transparency into a layer of its own? > > > The position of the gray box is not always going to be 1:1 with the text > within it, and by design, the final product very well have a > vector-converted set of text that extended well above and below that > transparent box. Plus I've never had to before. And things get worse, and I'll probably have to log a separate bug for this, but placing an SVG vector graphic, something that I've done countless times before, if it is made up of multiple paths and not just one path, causes the bounding rectangle of the graphic to export the entire thing as black, or worse, exporting leaves it alone and the rest of the entire page turns black. Again, this messes up with PNG but fine with TIFF, but I don't have any use for TIFFs and would have to convert everything post-process once done with Draw.
This is what I mean about the text not necessarily being placed within the gray box, i.e., why the text is its own object and not an object with its area black with a transparency applied: https://i.imgur.com/BE76ypv.png
(In reply to V Stuart Foote from comment #8) > Can't tell if this is intentional. But confirm export to PNG of transparent > Draw shapes changed from 6.4 -> 7.0 > > If intentional need documentation change guiding use of additional layers > when set transparent over default Layout layer. Which is information that I'll have to spread far and wide to everyone using my various templates. Some of them have adopted using my templates without any experience having used LO before, so they'll be in absolute tears if they upgrade to 7.0 and still using these templates with this bug in it, nothing they do will come out right, and like me, are forced to use PNG, not TIFF, because we're all using the same program to import our work. This change to how PNG handles transparency upon export is highly impactful, and not just for myself.
Created attachment 162437 [details] riff on the sample document with textual elements moved into a new Draw layer, and layers Z-order arranged (In reply to mwtjunkmail from comment #11) > This is what I mean about the text not necessarily being placed within the > gray box, i.e., why the text is its own object and not an object with its > area black with a transparency applied: > > https://i.imgur.com/BE76ypv.png Hmm, I've really no problem arranging multiple layers and transparency. Here is a riff on your sample document with the Lucida Calligraphy 96pt w/Scaled width 75%. Not seeing an issue, other than there *has* been an export filter change requiring the transparent layers be separated--here I moved them out of the default "Layout" layer to a new "Textual_elements" layer.
Created attachment 162438 [details] 7.0.0b2 export to PNG with a new transparent layer
https://i.imgur.com/JpyvCYG.png is a side-by-side comparison of the original non-transparent image next to me cutting up the image (on a new slide because I had no idea how to move layers above and below each other). I don't know if you can tell, but the image on the right has lost detail. The overall image is dimmer, the highlights in the hat are far fainter, and her face has lost detail. I hope that's not the permanent end result of these changes, because I've no way to compensate for that. If it comes down to it, I can rebuild all 30-odd template documents into layers and republish them, not that everyone will get the memo to use the new templates, and Lord knows how long it'll take me to cut them all up. The point of using LO was 1. Free and 2. point-and-click for the end users just to replace the pictures. That was the glory of using this technique. That said, there's no promising that someone won't attempt to modify one of my templates in such a way, while making their own book cover, painting template for a Sims4 object mesh, or whatever, that they correctly place each and every element in its own layer to accommodate the PNG export. This change from 6.4 to 7.0 produces a lot more work, only to achieve the same result. Changes in LO should not force users to update all their drawing documents to retrofit these changes. This retrofit will be huge.
(In reply to mwtjunkmail from comment #15) > https://i.imgur.com/JpyvCYG.png is a side-by-side comparison of the original > non-transparent image next to me cutting up the image (on a new slide > because I had no idea how to move layers above and below each other). > > I don't know if you can tell, but the image on the right has lost detail. > The overall image is dimmer, the highlights in the hat are far fainter, and > her face has lost detail. I hope that's not the permanent end result of > these changes, because I've no way to compensate for that. > Careful, the source PNG embedded in the ODF archive is sized 473 x600 x 24 BPP. It will be scaled to place on a canvas you've defined (here 8.5 x 11 inches of the cover). So the loss of detail is the resampling that has to occur to expand the pixel count--nearest neighbor, bilinear, bicubic--I don't know which gets used, just that a resampling occurs, and can appear fuzzy. Very noticeable on the pillow tassel. To compare "apples to apples" for image quality on export the Draw page/canvas size would have to be set to the size of the image.
That's confusing, because the two images in the side-by-side example are identical in size, and in the same document just different slides, so sorry for me being dense, but I'm not understanding why one slide's content would would be resampled but the other not. I can play with it and see what's going on.
(In reply to mwtjunkmail from comment #17) > That's confusing, because the two images in the side-by-side example are > identical in size, and in the same document just different slides, so sorry > for me being dense, but I'm not understanding why one slide's content would > would be resampled but the other not. I can play with it and see what's > going on. The source PNG is held in the ODF archive. Unzip it and look in the /Pictures directory. If the source PNG is not the size of the drawing page it is being scaled. When filter parsed onto canvas, or when canvas selection is filter exported to a new PNG (or other format), it is being resampled. Resulting pixels are not the same size as the original, and color bands for each resulting pixel will also change depending on the sampling type and also for any filter applied (color, gamut, transparency). So, to eliminate effects of scaling (and isolate the filtering) the drawing page size would have to match the size of the source PNG. But that is not the issue here of changed handling of transparency on the 'Layout' layer.
Created attachment 162440 [details] Bibisect log Bisected to: author Mike Kaganski <mike.kaganski@collabora.com> 2020-05-28 20:13:50 +0200 committer Mike Kaganski <mike.kaganski@collabora.com> 2020-05-29 10:31:40 +0200 commit c644b2b4abe3051c0e0fc91674154c796fd326f6 (patch) tree 391c0d15daa02bae90325a2d44b9a4cbbba01756 parent f510bdfa98014ca0ae596dcd0dfd487cfc90f3eb (diff) Use buffer with alpha in VclProcessor2D::RenderUnifiedTransparencePrimitive2D This allows UnifiedTransparencePrimitive2D to produce truly transparent image, usable later in the stack - specifically by glow and soft edge effect. https://cgit.freedesktop.org/libreoffice/core/commit/?id=c644b2b4abe3051c0e0fc91674154c796fd326f6
Adding cc: to Mike Kaganski
The loss of detail that I mentioned when a transparent element is placed over a picture is a real phenomenon. I created a new template and used layers to use for transparent objects. One LO draw page has a transparent object, the other does not, but otherwise they are duplicates of each other. I exported both LO draw pages as PNG, then opened both exported PNG files in paint.net. Paint.net reveals that what's happening is that the underlying image has a transparency effect applied to it at the time of export (I say time of export, because the transparency property of the object itself in LO Draw not modified, it's still set to 0, so the only way it could have gotten transparent was during the export process). This https://i.imgur.com/QX6wNcF.png is a side-by-side comparison in paint.net of the PNG exports of the two LO drawing pages. One page has a transparent object, the other does not. Again, I used layers this time, I didn't just put everything on the layout layer like I've done prior to LO 7.0. If you examine https://i.imgur.com/QX6wNcF.png, the red stripe on the right actually spans the distance of the entire side-by-side comparison, in its on paint.net layer in the comparison beneath the two exported PNG images. That red stripe is actually behind both pictures, but only shows up on the right picture because a transparency effect has been inappropriately assigned to the underlying image residing beneath the transparent object (that being the Liberation Sans narrow text box). That inappropriate transparency effect on the underlying image upon PNG export is what's causing the loss of detail and blanching. I'll attach the LO Draw document that I used to demonstrate this as transparency bug comparison.odg.
Created attachment 162445 [details] LO ODG side-by-side transparency bug comparison LO ODG file containing two identical slides, one has a transparent object on it, the other does not. Exporting them as PNG causes the one with the transparent object to appear blanched with a loss of detail. That's happening because the image beneath the transparent object is being inappropriately assigned a transparency effect, causing blanching and loss of detail, most apparent when flipping between the exported PNG files in Windows' default Photos program, but also obvious in paint.net (which does well to indicate when transparency is applied to something).
Created attachment 162446 [details] expected appearance of exported PNG image This is what I expect any PNG export to look like. There is no transparent object on this.
Created attachment 162447 [details] inappropriate appearance of exported PNG image This is not what an LO PNG export should look like. This export had a transparent object on it (the Liberation Sans Narrow text box). Compared to attachment 162446 [details], which is what the image SHOULD look like, you can see the difference: 1. The overall image is dimmer. This is occurring because there's no solid background beneath the image. The image (of the glass) is transparent but shouldn't be. 2. Because of this transparency, detail is lost (compare the white area of the lemon rind in both pictures).
I should have said the overall image in 162447 is blanched, but the reason is the same.
I've just discovered something: In Microsoft Windows, the default photo viewing program depicts the image with the transparent object on it as dimmer than the original. In my Firefox browser, that same image is blanched compared to the original. Regardless how viewed, the loss of detail is apparent. Regardless how created, the intensity and tone of the colors shouldn't change.
(In reply to mwtjunkmail from comment #25) > I should have said the overall image in 162447 is blanched, but the reason > is the same. No need for some many examples :-) First is obvious enough. The font rendering has changed too, in notice comparing 6.4 with 7.1. I would say improved
Still an issue with this Version: 7.1.0.0.alpha0+ (x64) Build ID: 9bef09cb2f0c9c9e6819f28ed8e83c0edd6eadb6 CPU threads: 8; OS: Windows 10.0 Build 20152; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL both with everything on the layout layer and well as when separated out into other layers.
Perhaps this may help -- transparent elements imported from other graphics programs (I used paint.net) render just fine (I only tried with hardware rendering), even when the transparent element and everything else on the LO Draw reside on just the layout layer. It's when I draw a shape from within LO Draw, fill it, set its transparency property to other than none/0, that I see the bug.
This bug kills. I wish I knew how to program LO. Is there anyway to get this elevated?
(In reply to mwtjunkmail from comment #30) > This bug kills. I wish I knew how to program LO. Is there anyway to get this > elevated? I'm skeptical (and also no clue if it's needed), but lets add a QA manager
(In reply to Telesto from comment #19) > > Bisected to: > author Mike Kaganski <mike.kaganski@collabora.com> 2020-05-28 20:13:50 +0200 > committer Mike Kaganski <mike.kaganski@collabora.com> 2020-05-29 10:31:40 > +0200 > commit c644b2b4abe3051c0e0fc91674154c796fd326f6 (patch) > tree 391c0d15daa02bae90325a2d44b9a4cbbba01756 > parent f510bdfa98014ca0ae596dcd0dfd487cfc90f3eb (diff) > Use buffer with alpha in VclProcessor2D::RenderUnifiedTransparencePrimitive2D > This allows UnifiedTransparencePrimitive2D to produce truly transparent > image, > usable later in the stack - specifically by glow and soft edge effect. > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=c644b2b4abe3051c0e0fc91674154c796fd326f6 Reverting that patch solves the problem. Tested with reverting on Version: 7.1.0.0.alpha0+ (x64) Build ID: b54f7fd93cc300fedac2f1b007dfc4e6a704b515 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
Created attachment 162922 [details] LO Draw comparison test 2020.07.12 First, thank you for your attention on this bug. The latest fix on the July 12 daily build still is not working for me. On the left is the expectation, on the right is the result. Failed for both hardware rendering and Skia. Version: 7.1.0.0.alpha0+ (x64) Build ID: 10d42094e6e478823bac047a5afb3d8268eb990a CPU threads: 8; OS: Windows 10.0 Build 20161; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to mwtjunkmail from comment #33) > The latest fix on the July 12 daily build still is not working for me. What fix do you mean? I see no fix that is related to this bug.
(In reply to Regina Henschel from comment #34) > (In reply to mwtjunkmail from comment #33) > > > The latest fix on the July 12 daily build still is not working for me. > > What fix do you mean? I see no fix that is related to this bug. Then I misunderstood this comment: Reverting that patch solves the problem. Sorry.
(In reply to mwtjunkmail from comment #35) > (In reply to Regina Henschel from comment #34) > > (In reply to mwtjunkmail from comment #33) > > > > > The latest fix on the July 12 daily build still is not working for me. > > > > What fix do you mean? I see no fix that is related to this bug. > > Then I misunderstood this comment: Reverting that patch solves the problem. > > Sorry. No problem. I have reverted it on my personal, local build to verify, that the mentioned commit has indeed introduced the problem here. I will not revert it on master, because I do not know, which problem Mike Kaganski wants to solve with that commit.
(In reply to Regina Henschel from comment #36) > I will not > revert it on master, because I do not know, which problem Mike Kaganski > wants to solve with that commit. Please check soft edge effect with overlapping semi-transparent objects.
*** Bug 134911 has been marked as a duplicate of this bug. ***
*** Bug 134905 has been marked as a duplicate of this bug. ***
I believe it's fixed by https://git.libreoffice.org/core/commit/bf021c369f2306ee507da9bd3cc4cd10ac5d234c
(In reply to Mike Kaganski from comment #40) > I believe it's fixed by > https://git.libreoffice.org/core/commit/ > bf021c369f2306ee507da9bd3cc4cd10ac5d234c Has this hit the daily builds then to test?
(In reply to mwtjunkmail from comment #41) Of course - it's been several days since then. https://dev-builds.libreoffice.org/daily/
Getting close but we're not there yet. With Skia rendering, there is a white/gray outline around a transparent box on the PNG export where there is no border defined at all in the drawing document.
Created attachment 164433 [details] Expectation of PNG output with a transparent object This is a screen shot of an LO document. There are no borders set on the transparent box in the upper left of the picture. This is the expectation.
Created attachment 164434 [details] PNG export result with skia rendering This is the output of using Skia rendering with a transparent object with no borders. There should not be the gray outline around it.
Forgot the version information. Tested 2020.08.18 with Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 8; OS: Windows 10.0 Build 20190; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Skia rendering.
And the <build version> is what came from the link off of the Help, About window, so apparently that's broken too.
And the <build version> is what came from the link off of the Help, About window, so apparently that's broken too.(In reply to mwtjunkmail from comment #45) > Created attachment 164434 [details] > PNG export result with skia rendering > > This is the output of using Skia rendering with a transparent object with no > borders. There should not be the gray outline around it. And I'm talking strictly about the white/gray outline around the transparent box, not the big white lines on the edges of the screenshot, that's me being sloppy with the screen grab.
(In reply to mwtjunkmail from comment #47) > And the <build version> is what came from the link off of the Help, About > window, so apparently that's broken too. That is bug 135133, meanwhile correct MD5 hash signature for build is available in the install's program\version.ini if anyone asks.
(In reply to mwtjunkmail from comment #43) > Getting close but we're not there yet. With Skia rendering, ... No that doesn't work like that. This bug is about Skia-independent problem with export of slide with transparent object, where transparency gets applied to everything. It is fixed now. This issue should be closed, and if there's another issue with Skia, then a new issue should be created to track that.
(In reply to mwtjunkmail from comment #44) > Created attachment 164433 [details] > Expectation of PNG output with a transparent object > > This is a screen shot of an LO document. There are no borders set on the > transparent box in the upper left of the picture. > This is the expectation. And please use pre-existing sample files or upload the file you're using.. Else it hard to help out :-)
(In reply to Mike Kaganski from comment #51) > (In reply to mwtjunkmail from comment #43) > > Getting close but we're not there yet. With Skia rendering, ... > > No that doesn't work like that. This bug is about Skia-independent problem > with export of slide with transparent object, where transparency gets > applied to everything. It is fixed now. This issue should be closed, and if > there's another issue with Skia, then a new issue should be created to track > that. So while I cannot use the output because the fix leaves artifacts behind, you want that to be a new bug? The output is still very much unusable.
(In reply to mwtjunkmail from comment #53) > (In reply to Mike Kaganski from comment #51) > > (In reply to mwtjunkmail from comment #43) > > > Getting close but we're not there yet. With Skia rendering, ... > > > > No that doesn't work like that. This bug is about Skia-independent problem > > with export of slide with transparent object, where transparency gets > > applied to everything. It is fixed now. This issue should be closed, and if > > there's another issue with Skia, then a new issue should be created to track > > that. > > So while I cannot use the output because the fix leaves artifacts behind, > you want that to be a new bug? The output is still very much unusable. Multiple causes, multiple bugs :-). Or different developer responsible; anyhow suggest to create a new bug, this one bit long anyhow with 54 comments
(In reply to mwtjunkmail from comment #53) > So while I cannot use the output because the fix leaves artifacts behind, > you want that to be a new bug? The output is still very much unusable. Bug tracker is a tool *for developers*. It is not about your usage, it is about specific bugs and their status. One bug is one issue. Otherwise it's impossible to check what is done and what is not. It is *not* about "someone is not satisfied with the program; let's use this issue to track this user satisfaction level". It's about users helping us to find bugs and do that in manageable manner. Thank you for helping making LibreOffice better.
I don't consider this bug "resolved" because the fix leaves crap behind on the PNG output, meaning the output is just as useless as it was before, but I'll log a "new" bug reflecting that this fix is flawed, and mark this bug "resolved"
@Mike Is it not possible to get some kind of unit test for png export; Kohei did point this out: sheet 26 https://www.slideshare.net/kohei101/life-after-calc-core-change The whole approach is currently annoying frustrating, straining, tiresome.. 1) From user perspective quality wise; brokenness not great 2) From user perspective, reporting bugs and bugs over in over in the same area. (I assume mwtjunkmail can vouch for that) 3) From QA perspective, having to confirm/bibisect those bugs 4) From developer perspective, being hunted by those fall out It can't be that hard to run an export and do an (automatic) image comparison. Ideally on content/and maybe also file size (compression) and maybe the header of the file format (as extension bmp was stores actually stored as jpg) Not asking for doing all possibility's, but a plain case with some transparency to png. samples are there now plenty. Simply to check if the most common thing works A single unit test would save so much trouble. They only person who does it rather consistently - from my perspective - is Justin L. (and maybe few more people at DOCX/DOC). This really should be the ideal, IMHO. Bug fixes should ideally come with a unit tests by default, or go without it but coming with an explanation. (Deviate + Explain). The current workflow is not maintainable in the long term.. And Kohei pointed this out long long ago. But somehow people missed the memo? Or interpreted it as Calc only :-). It's waste of time in short time, but is worth the effort in the long term. Of course 'bugs' are the QA yard. So developers might not experience time consuming business.. but it is. For users, bug reports & QA members.
(In reply to Telesto from comment #57) > A single unit test would save so much trouble. Single test multiplied by ten thousand. This is not a case of having to educate developers. We can all do our part. I am sure you are capable of converting certain UI tests to cppunit tests, for example: https://lists.freedesktop.org/archives/libreoffice-qa/2020-July/010903.html https://lists.freedesktop.org/archives/libreoffice-qa/2020-July/010905.html Note that these kinds of tests are actually "integration tests", testing functionality in a dirty way rather than purely algorithms without affecting state or something. We should probably clarify the terminology in the wiki.