Bug 75788 - certain inserted JPEG images appear black
Summary: certain inserted JPEG images appear black
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.0.0 target:5.4.0.1
Keywords: bibisected, regression
: 95431 (view as bug list)
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2014-03-05 07:34 UTC by Tzafrir Cohen
Modified: 2017-06-16 09:55 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Image reproducing the issue (859.27 KB, image/jpeg)
2014-03-05 07:34 UTC, Tzafrir Cohen
Details
Another image triggering the bug (in .zip file) (1.11 MB, application/zip)
2014-12-19 12:53 UTC, Lorenzo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tzafrir Cohen 2014-03-05 07:34:56 UTC
Created attachment 95142 [details]
Image reproducing the issue

This is an issue reported to a local users forum and reproduced with various versions of most users.

To reproduce:

1. create a new Writer document
2. intert the attached file into the document.

Expected result: a document showing that imagee.

Actual result: a document with a black square.

Various tweaks to the image will render it usable. Not exactly sure which.
Comment 1 Jorendc 2014-03-05 12:48:06 UTC
Reproducible, tested using Mac OSX 10.9 with LibreOffice Version: 4.2.2.1
Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f
Comment 2 Jorendc 2014-03-05 12:52:36 UTC
Also reproducible tested using Mac OSX 10.9 with LibreOffice Version: 4.1.5.3
Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24
Comment 3 Maxim Monastirsky 2014-03-05 16:45:08 UTC
Reproducible under Fedora with 4.2.1 build from libreoffice.org, but not with the build from Fedora repositories (of the same version).

One difference that I see is that the former was built with '--without-system-jpeg', see http://opengrok.libreoffice.org/xref/core/distro-configs/LibreOfficeLinux.conf#10.
Comment 4 Lorenzo 2014-12-19 12:53:14 UTC
Created attachment 111044 [details]
Another image triggering the bug (in .zip file)
Comment 5 Lorenzo 2014-12-19 12:57:19 UTC
Every program of the suite (Writer, Draw, Calc, Impress...)is not able to open this image correctly, but only a black square appears.

I am experiencing the same issue on Libreoffice 4.3.4.1 on Windows 8.1 x64.
I have attached another image triggering the bug (in a zip file).

If the image is opened with an image editor and saved again, the newly created image is opened correctly, so it's something specific to the format of these images.
Comment 6 tommy27 2015-06-22 19:28:42 UTC
still reproducible under Win8.1 x64 using LibO 4.4.3.2 and recent 5.1.0.0 alpha daily build

it seems a very old regression... 
I can reproduce it too on LibO 3.5.0 but not in LibO 3.4.6
Comment 7 Michael Weghorn 2015-07-18 22:02:11 UTC
(In reply to Maxim Monastirsky from comment #3)
> Reproducible under Fedora with 4.2.1 build from libreoffice.org, but not
> with the build from Fedora repositories (of the same version).
> 
> One difference that I see is that the former was built with
> '--without-system-jpeg', see
> http://opengrok.libreoffice.org/xref/core/distro-configs/LibreOfficeLinux.
> conf#10.

It also does not occur with the LibreOffice version shipped with Debian Jessie (Version: 4.3.3.2, Build ID: 430m0(Build:2))


bibisect result (using the bibisect-43all repository):

5da527e58c09a5e88e94b73289c2cc15c32b851e is the first bad commit
commit 5da527e58c09a5e88e94b73289c2cc15c32b851e
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Apr 24 20:01:19 2012 +0200

    source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
    
    commit 9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
    Author:     Luboš Luňák <l.lunak@suse.cz>
    AuthorDate: Thu Dec 8 16:33:22 2011 +0100
    Commit:     Luboš Luňák <l.lunak@suse.cz>
    CommitDate: Thu Dec 8 16:36:19 2011 +0100
    
        add docx starmath testing documents
    
        It's simply a bunch of documents with various math features in them.
        It'd be nice to have an automated test built on top of them that
        checks the formula is the same (roughly, in the meaning, it can't be
        precise because import adds e.g. extra {}'s) after an export+import
        roundtrip.

:100644 100644 70dfab35f16f30a2c2b97a32e92f6ebff188f4a4 ea95fe97e43b16b1fdb7ca5cff03bfb2dd94f21b M	autogen.log
:100644 100644 57029d0a394a4ec9f3cdc15a71cbaec65c90a55f f4d33ca8c705b891284fd45b42723573d5b777ec M	ccache.log
:100644 100644 288e6c9cf04b39bd7c342c2214d1934df0abfd89 00467179a23368572a5fe6d5a81cfa7a286ddf16 M	commitmsg
:100644 100644 0a7e1faf4c31b2d58fc5a86b7131a2cc9a9899d9 e8662d50fcf81076ca9917c1820bbbbdb03782d2 M	dev-install.log
:100644 100644 0e2d907381ecc68712660a9dcf633d0c2ec9080a f1be889d147387181bc9a11a18e62efadb66d430 M	make.log
:040000 040000 528453660be68a258459036a41ffb5c7e3cf8046 4405e99f642f7be21ed5711f128078a02d987d6d M	opt

---

$ git bisect log
# bad: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf
# good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
git bisect start 'last36onmaster' 'last35onmaster'
# bad: [5071c2206541a2db45ead3ead86da2de873fa2c2] source-hash-b36a42fb831b853120928e05dcf322898a92a731
git bisect bad 5071c2206541a2db45ead3ead86da2de873fa2c2
# bad: [e1ed92feeeb51078dcf7ab6d30e080321609049d] source-hash-ba8918aebd2b9f030e0fd684accc9bf21bd1eac3
git bisect bad e1ed92feeeb51078dcf7ab6d30e080321609049d
# bad: [c2511d0f8524babacf90c6c2060a66fc2c8ac919] source-hash-4eedf5dc54ab19af39d7033462421082d1abb86d
git bisect bad c2511d0f8524babacf90c6c2060a66fc2c8ac919
# bad: [d202b17d88ecb0b608d81518624021c832c7dfdb] source-hash-ce97851773a06103504972eb2771eecd7dd81e36
git bisect bad d202b17d88ecb0b608d81518624021c832c7dfdb
# bad: [0641af017cb9ec5ecca3eb879dded60fadf3ac78] source-hash-a1b970a10e00b34ab6d8608cb02247b8f0195573
git bisect bad 0641af017cb9ec5ecca3eb879dded60fadf3ac78
# bad: [5da527e58c09a5e88e94b73289c2cc15c32b851e] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
git bisect bad 5da527e58c09a5e88e94b73289c2cc15c32b851e
# first bad commit: [5da527e58c09a5e88e94b73289c2cc15c32b851e] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
Comment 8 MarjaE 2015-09-17 17:59:56 UTC
Similar bug in Draw, persisting into 5.0.1.2.

I have scads of draw files I can't use because of this bug. I reported it a year ago, but was unable to provide examples because of file size issues.
Comment 9 Robinson Tryon (qubit) 2015-12-13 11:09:39 UTC Comment hidden (obsolete)
Comment 10 Aron Budea 2016-10-18 04:59:21 UTC
The original 879888-byte JPEG is truncated to 57344 bytes upon insertion.
Comment 11 Telesto 2016-12-23 11:39:17 UTC
*** Bug 95431 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2016-12-23 22:17:23 UTC
@Tomaž,

The two JPEG images here and the one in dupe bug 95431 are all manifesting the same way.  On insert or open into any module, the first lines of the image are brought in, and then the rest goes bad--and the entire image shows up black on canvas.

Looking at the image recorded into a saved ODF archive's Pictures directory you can see the first lines of the raster before they are cut off.

I tried several times, but I could not get any kind of stack trace as the the image is imported without any error I could track, and I tried to follow it with Process Monitor but could not isolate the insert image--but something does seem wrong in importing these three JPEGs.

Any time to look at it?
Comment 13 Caolán McNamara 2017-06-15 20:06:53 UTC
If I remove the configure flag --with-jpeg8 from our embedded libjpeg then this image works, with it in place again it doesn't work. Which is a little odd so there's something about jpeg8 support in libjpeg-turbo/libjpeg8 which causes this.
Comment 14 Commit Notification 2017-06-16 08:04:28 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#75788 build jpeg-turbo without --with-jpeg8

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2017-06-16 09:55:58 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bfc270b86bb74a087c09caf318d5a4d1a38afa0f&h=libreoffice-5-4

Resolves: tdf#75788 build jpeg-turbo without --with-jpeg8

It will be available in 5.4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.