Bug 85757 - FILEOPEN: Background image in docx looses 'transparency' (brightness/contrast settings) (see comment #16)
Summary: FILEOPEN: Background image in docx looses 'transparency' (brightness/contrast...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium major
Assignee: Not Assigned
Whiteboard: interoperabillity
Keywords: filter:doc, filter:docx, filter:pdf
: 92436 107112 125108 (view as bug list)
Depends on:
Blocks: DOCX-Images DOC 38233
  Show dependency treegraph
Reported: 2014-11-02 12:58 UTC by Anonymous Helper
Modified: 2022-03-21 15:47 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:

Sample document (48.98 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-11-02 12:58 UTC, Anonymous Helper
image_transparency_MSOffice (98.79 KB, image/jpeg)
2014-11-02 12:59 UTC, Anonymous Helper
last edited with Word2003. LO sets image to white background on save (76.50 KB, application/msword)
2016-01-18 13:45 UTC, Justin L
cleaner test case with only background image and no other objects (441.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-04-12 10:58 UTC, Cor Nouws

Note You need to log in before you can comment on or make changes to this bug.
Description Anonymous Helper 2014-11-02 12:58:29 UTC
Created attachment 108792 [details]
Sample document

Writer fails to preserve the background image transparency settings in this sample document. Attached is also a picture showing how it looks like in Office.
Comment 1 Anonymous Helper 2014-11-02 12:59:32 UTC
Created attachment 108793 [details]
Comment 2 tommy27 2014-11-02 16:44:39 UTC
I confirm bug under Win7x64 using LibO master, and
Comment 3 Cor Nouws 2014-11-03 08:34:01 UTC
Transparency isn't set in 3.3.4 too. So prolly never worked. (However the position is much better now then in 3.3.4)
Comment 4 Alex Thurgood 2015-07-01 07:49:01 UTC
*** Bug 92436 has been marked as a duplicate of this bug. ***
Comment 5 Alex Thurgood 2015-07-01 07:50:36 UTC
*** Bug 89442 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2016-01-18 13:45:04 UTC Comment hidden (doc_not_docx, no-value)
Comment 7 Björn Michaelsen 2016-08-24 22:00:28 UTC
Assuming bisected to imply bibisected, thus adding the latter. This is to make queries for "bibisected" not miss out bisected bugs.
Comment 8 Thomas Bertels 2016-08-30 12:27:58 UTC
I've checked it with
- docx: it doesn't work on read and write
- doc: it doesn't work on write
- pdf : it doesn't work on read

+filter keywords
Comment 9 Cor Nouws 2016-08-30 12:40:43 UTC Comment hidden (obsolete)
Comment 10 Thomas Bertels 2016-08-30 12:42:48 UTC Comment hidden (obsolete)
Comment 11 Cor Nouws 2016-08-30 12:49:42 UTC Comment hidden (obsolete)
Comment 12 Cor Nouws 2016-08-30 13:26:18 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2016-09-14 14:41:02 UTC
Deleting 'bisected' and 'bibisected' from keywords as the problematic commits hasn't been identified.
Comment 14 Xisco Faulí 2016-09-14 14:45:05 UTC
Only regressions should use the keyword 'preBibisect'. Removing it...
Comment 15 Xisco Faulí 2017-04-12 09:47:45 UTC
*** Bug 107112 has been marked as a duplicate of this bug. ***
Comment 16 Cor Nouws 2017-04-12 10:17:23 UTC
see simple test file https://bugs.documentfoundation.org/attachment.cgi?id=132506
and screenprint from Word settings https://bugs.documentfoundation.org/attachment.cgi?id=132507 from bug 107112
Comment 17 Cor Nouws 2017-04-12 10:19:19 UTC
(In reply to Cor Nouws from comment #16)
> see simple test file
> https://bugs.documentfoundation.org/attachment.cgi?id=132506

  ( You can get the pictures context menu, using Navigator, clicking
    WordPictureWatermarkxxx, then F6, F6, ESC, Shift+F10 ... )

after saving and reopening in Writer, it is a 'normal' image, of which transparency can be set in the image toolbar.
Comment 18 Cor Nouws 2017-04-12 10:58:19 UTC
Created attachment 132514 [details]
cleaner test case with only background image and no other objects
Comment 19 Xisco Faulí 2017-10-03 15:32:17 UTC
Still reproducible in

Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 20 QA Administrators 2018-10-04 02:55:20 UTC Comment hidden (obsolete)
Comment 21 Robert Gonzalez MX 2018-10-06 22:28:04 UTC
Tested with Version: (x64)
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: es-MX (es_MX); Calc: CL
and Microsoft Word 2007

The first and last test documents when are opened in Word 2007, the transparency is present in their original state. Which can be verified in the “Image Format” option of the context menu of the image, that has set a predefined “Watermark” preset. This condition is not imported to Writer.

With the second test document I can confirm what Justin L said in comment 6

My original bug 89442 it was about the transparency lost in a Writer file with an image background that had set a transparency and this definition was not saved when opening again the file. But this issue is fixed now.

But I am glad that had the opportunity to test this issue.
Comment 22 Justin L 2020-04-14 08:23:00 UTC
Still not fixed in 7.0 master. OP's 2014 X-Country Schedule v 4.docx still opens with a very black watermark image.

The image opens as a "drawing object" instead of an "image". When round-tripped, it is considered as a regular image as noted in comment 17.

https://askubuntu.com/questions/570789/fading-image-in-libre-office indicates how you can set transparency on the image itself. Note that the properties tab for "transparency" is for the Area color and not the image itself.

So the key would be to figure out why this background image is first inserted as a draw object, and then exported as a regular image. If it could be imported as a regular image, then for sure the transparency settings could be applied.

Alternatively, it MIGHT be possible to set transparency on the drawing object, and just wasn't done?
Comment 23 Justin L 2020-04-14 10:59:11 UTC
OK - I was mislead and therefore became misleading again in return.
This really is about brightness/contrast as noted in the subject heading, not transparency.

Also the picture is anchored in the header. I believe that also automatically makes it slightly transparent in Word.

There are two images in the header2.xml.  One is a true picture, but the one we are focusing on is an auto-shape/picture, which has
<v:imagedata r:id="rId3" o:title="" gain="19661f" blacklevel="22938f"/>

LO recognizes blacklevel as a legit tag, but doesn't do anything with it. So this is a missing feature problem.
Comment 25 NISZ LibreOffice Team 2020-11-30 10:10:42 UTC
*** Bug 125108 has been marked as a duplicate of this bug. ***
Comment 26 Vincent Duvernet 2021-10-30 13:08:29 UTC
Problem still exists en x64 Win.
Comment 27 Xisco Faulí 2022-03-21 15:47:22 UTC
This issue is fixed by:

author	Miklos Vajna <vmiklos@collabora.com>	2021-12-16 10:16:02 +0100
committer	Miklos Vajna <vmiklos@collabora.com>	2021-12-16 12:43:11 +0100
commit 90556b6df0f6378fb60d7dee18b2f5d275ece530 (patch)
tree 14bad912d7f464f360146c4b01631995d2498d16
parent 69a68bc38d29964ef9af8c30ea457975f9e568fe (diff)
VML import: handle <v:imagedata gain="..." blacklevel="...">

@Miklos, thanks for fixing this issue!!