Bug 103614 - Black square instead of jpg image when insert image from file. updated to Java 1.8.0_111
Summary: Black square instead of jpg image when insert image from file. updated to Ja...
Status: RESOLVED DUPLICATE of bug 103803
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-11-01 08:26 UTC by Trevor Caldwell
Modified: 2016-11-11 17:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
600dpi jpg pic apparently causing LibreOffice to malfunction (3.05 MB, image/jpeg)
2016-11-04 13:47 UTC, Trevor Caldwell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Trevor Caldwell 2016-11-01 08:26:18 UTC
Only applicable to download today (1 Nov 2016) of ver 5.1.5.2.  Previous version worked well.  Black square only applied to color pic.  Adjacent B&W pic was OK
Comment 1 steve -_- 2016-11-01 08:57:50 UTC
Could you retry w 5.1.6? http://www.libreoffice.org/download/libreoffice-still/

If the problem persists please provide precise reproduce steps as in

1. open writer and select menu xyz 
2. ... etc

Also please add detailed information of which OS you are running.

After doing all that set the bug back to unconfirmed.
Comment 2 Aron Budea 2016-11-01 11:28:53 UTC
Can you save the document with the inserted pic, rename extension to .zip, unzip it, and check if the image stored in the zip is the same as the original or not? If the image in the zip appears black as well, then this is a duplicate of bug 75788.
Comment 3 Trevor Caldwell 2016-11-02 02:23:40 UTC
I downloaded ver 5.1.6.2 - same result.
However - I noted that some similar pics inserted OK.  I examined the differences and found the offending pic was modified with Photoshop to 600dpi.  Other pics modified by Photoshop to 300dpi inserted OK
LibreOffice seems sensitive to the photo resolution.
Any comments about where the parameters may lie between success and failure?
Thanks for input
Comment 4 Aron Budea 2016-11-02 06:35:44 UTC
Could you do the steps outlined in comment 2, and report back with your findings?
Is the image the same file size (in bytes/KBytes) and appearance when extracted from a saved document, or it's smaller size, and appears black?
Comment 5 Trevor Caldwell 2016-11-02 13:41:37 UTC
(In reply to Aron Budea from comment #4)
> Could you do the steps outlined in comment 2, and report back with your
> findings?
> Is the image the same file size (in bytes/KBytes) and appearance when
> extracted from a saved document, or it's smaller size, and appears black?

I did try the zip idea, however I had to download Winzip and then try to unzip the renamed Libre file.  It gave an error message:"Cannot open - not a valid archive" Would another zip product have succeeded?
I then changed the pic file to 300dpi and it was immediately inserted correctly.
I have since tried to re-create the scenario by creating the same pic again with 600dpi.  Whenever I tried to insert this 600dpi file I got various messages as I tried different times: "Bad Allocation" - program crashed  Then "Image filter not found" (no crash).  Only once did I get a black rectangle, which was replaced when I tried to save it by a message inside the pic area "Read Error" and the black disappeared.
The large file size or high resolution seemed to be the sticking point.  There must be some boundary parameters that cause the failure.  I would like to know these so I can avoid too-large files in future. The previous version was not troubled, so maybe the new version can be modified in time.
Incidentally, I am now using ver 5.1.6.2 from Libre "Still Site".  My system is Windows 10 on an MSI GE70 laptop.
Comment 6 Aron Budea 2016-11-04 10:08:37 UTC
Thanks for giving unzipping the file a try. ODF files are supposed to be correct zipped files, I have no idea why Winzip didn't want to open it (unless something went really, really wrong during save, but then LibreOffice would complain as well later).

I tried with some random 600dpi high resolution images from the internet, but unfortunately couldn't reproduce the bug with those.
Is there a chance you could share the JPEG? Or if it's not something to be shared, alter the image to make it unrecognizable, and see if it's still imported in the document erroneously.
Comment 7 Trevor Caldwell 2016-11-04 13:47:52 UTC
Created attachment 128487 [details]
600dpi jpg pic apparently causing LibreOffice to malfunction

Part of my reply to Aron Budea's request.
....Trevor Caldwell
Comment 8 Trevor Caldwell 2016-11-04 13:58:31 UTC
(In reply to Aron Budea from comment #6)
> Thanks for giving unzipping the file a try. ODF files are supposed to be
> correct zipped files, I have no idea why Winzip didn't want to open it
> (unless something went really, really wrong during save, but then
> LibreOffice would complain as well later).
> 
> I tried with some random 600dpi high resolution images from the internet,
> but unfortunately couldn't reproduce the bug with those.
> Is there a chance you could share the JPEG? Or if it's not something to be
> shared, alter the image to make it unrecognizable, and see if it's still
> imported in the document erroneously.

I thought I had replied but cannot see it in this page.  In case it got lost I shall repeat it.
I always use the DOC or DOCX format rather than the Libre ODF format.  Perhaps this could explain the abberations?
I have uploaded as an attachment, the jpg 600dpi pic that seemed to cause the variety of problems, crashes and the black square.  The identical pic in 300dpi format was trouble free.
cheers
Trevor Caldwell
Comment 9 Trevor Caldwell 2016-11-04 14:02:22 UTC Comment hidden (obsolete)
Comment 10 Aron Budea 2016-11-04 18:31:02 UTC
(In reply to Trevor Caldwell from comment #9)
> I always use the DOC or DOCX format rather than the Libre ODF format. 

DOC is not a ZIP archive, but DOCX is. It doesn't seem to be relevant in the end, I tried to reproduce the issue with the attached image, but it looks fine here (which means it doesn't get corrupted in the document).

Can you do steps 2-3 from [1], and see if either of those matter? (one is about resetting user profile, the other is disabling OpenGL acceleration)

[1] https://wiki.documentfoundation.org/QA/FirstSteps
Comment 11 Trevor Caldwell 2016-11-05 13:14:43 UTC
Step 1 - My system showed "UI Render: GL"
Step 2: I ticked the box "Use Open GL on restart"
I restarted LibreOffice and tried to insert the 600dpi file - a black rectangle ensued.
I then went back and unticked the box to return the system to what it was.

I think I have finished for now.  I will just avoid any large jpg files. Shall I change the status to "resolved" or "unconfirmed" or just leave it as "needinfo"?

thanks for your input - a pity we didn't get to resolve it, but at least I have a work-around.

Trevor
Comment 12 Trevor Caldwell 2016-11-05 13:27:24 UTC
After I had sent my last comment I realised I hadn't unticked the Open GL acceleration.  I went back in and did that.  I then successfully inserted my 600dpi file.  A modicum of success?
Are there any issues I could face by leaving the acceleration unticked?  Or shall I re-tick it and just avoid large insert files in future?
cheers

Trevor
Comment 13 Aron Budea 2016-11-09 04:08:04 UTC
Great, now we know the issue is caused by OpenGL acceleration. Having it turned off should be absolutely fine, the only drawback is slower UI if there are many and/or large images in the document. That might actually be relevant, but you can judge if it's significantly slower for you now, or workable.

There are two additional steps that would be interesting:
-as there aren't going to be further updates to version 5.1, test in 5.2 (5.2.3 is the current release at the moment) to see if the bug is still there,
-if the issue still occurs, the wiki page mentions an <user profile>/cache/opengl_device.log file containing information on the graphics device, attaching it to the bug report could help us finding an environment where the bug is reproducible.

If you could do that sometimes in the future, that'd be appreciated.
Comment 14 Tomaz Vajngerl 2016-11-11 10:56:27 UTC
Sounds like tdf#103803
Comment 15 Aron Budea 2016-11-11 17:56:06 UTC
Indeed it looks very similar, thanks for the notification, Tomaz.

Trevor, I'm going to assume this is the same issue as bug 103803. If you're not using Intel graphics, please reset status to UNCONFIRMED. Otherwise the fix will be available as part of v5.2.4, expected to be released sometimes between December 19-25.

*** This bug has been marked as a duplicate of bug 103803 ***