Bug 102928 - JPEG image (CMYK?) damaged in the exported PDF
Summary: JPEG image (CMYK?) damaged in the exported PDF
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords: filter:pdf
: 106095 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2016-10-03 07:22 UTC by khanhduongdv
Modified: 2017-08-02 09:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
An image in the pdf exported using 2 different versions of LibreWriter (damaged image is the one exported by 5.2.2 version, intact one is exported by 5.1.5 version) (1.19 MB, application/zip)
2016-10-03 07:22 UTC, khanhduongdv
Details
Test document file with the image (748.41 KB, application/vnd.oasis.opendocument.text)
2016-10-07 15:01 UTC, khanhduongdv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description khanhduongdv 2016-10-03 07:22:47 UTC
Created attachment 127784 [details]
An image in the pdf exported using 2 different versions of LibreWriter (damaged image is the one exported by 5.2.2 version, intact one is exported by 5.1.5 version)

After exporting a document to PDF, an image in the output file is damaged (see attachment), while the rest remains intact. This problem only happens in 5.2.x (0-2) versions.
Comment 1 Ákos 2016-10-07 13:51:04 UTC Comment hidden (obsolete)
Comment 2 khanhduongdv 2016-10-07 15:01:59 UTC
Created attachment 127862 [details]
Test document file with the image

This file contains the image that is damaged after exporting to PDF using 5.2.x (0-2) version
Comment 3 Xisco Faulí 2016-10-08 11:18:43 UTC
Reproduced in

Version: 5.3.0.0.alpha0+
Build ID: ae3ec79354f7b4967e736c6a4cd7c08fc52e2b7d
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 4 Xisco Faulí 2016-10-08 11:22:45 UTC
this is a regression as I can't reproduce it in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
Comment 5 Ákos 2016-10-11 08:26:04 UTC
I can reproduce in LO 5.2.0.0.alpha1+ Build ID: 3d27afd26f7b85c46a7c7d08498000b9dbcea1c8

This is the first version of witch can I reproduce.
Comment 6 Xisco Faulí 2016-10-11 08:45:34 UTC
Something weird is going on here...

I can reproduce the bug in

Version: 5.0.0.0.alpha1+
Build ID: 90e2dabb8d0bb5382234be776c2ad0e2d5d9e224
Locale: ca-ES (ca_ES.UTF-8)

if I use the bibisect repository lo-linux-dbgutil-daily-till50 but I can't reproduce it using bibisect-50max at the same commit, odd.
Comment 7 Ákos 2016-10-11 13:14:25 UTC
I try with LO 5.0.0.1 32 bit (win10 ent 64 bit), Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
and I can NOT reproduce the bug. I don't found earlier version from 5.0.
Comment 8 raal 2016-10-20 06:51:15 UTC
This seems to have begun at the below commit.
Adding Cc: to Michael Meeks; Could you possibly take a look at this one? Thanks

9ff0a94931d5aba1e838c680c9604562eb2e71e2 is the first bad commit
commit 9ff0a94931d5aba1e838c680c9604562eb2e71e2
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Wed Feb 17 07:37:49 2016 -0800

    source sha:76ec54e8c9f3580450bca85236a4f5af0c328588

author	Michael Meeks <michael.meeks@collabora.com>	2016-02-08 14:24:15 (GMT)
committer	Michael Meeks <michael.meeks@collabora.com>	2016-02-09 00:09:08 (GMT)
commit	76ec54e8c9f3580450bca85236a4f5af0c328588 (patch)
tree	1c4d36e921be16426fc8a61c7a85bdc006e0fafa
parent	e07ffae5046e9c91ef96026435cab84c3bcb4534 (diff)
tdf#97662 - Try to preserve original compressed JPEGs harder.
Comment 9 Michael Meeks 2016-10-29 19:55:04 UTC
Hmm - I guess there is something about this JPEG that is messing with PDF viewers' ability to extract and render it. The image itself is somewhat unusual:

JPEG 2072x1372 2072x1372+0+0 8-bit CMYK 749KB 0.000u 0:00.010

The 8-bit CMYK is I guess the problem; the vast majority of images are 8bit gray, or 8-bit sRGB (I guess).

De-compressing to RGB and re-compressing them all to make PDF export happy is an extraordinarily slow and lame thing to do ;-)

It would be good to confirm (with a small image) that the CMYK-ness of the JPEG is the issue here. Beyond that - I guess we'll need an API to cache more detailed feature information from JPEG streams - which I suspect we don't currently have.
Comment 10 Timur 2016-11-10 18:03:15 UTC
Also in Windows.
Comment 11 khanhduongdv 2017-02-01 13:19:34 UTC
The bug still exists in all 5.2.x versions and 5.3.0 release.
Comment 13 Aron Budea 2017-02-03 04:43:41 UTC
Vedran, which is the example image on that page?
Comment 14 Vedran Miletić 2017-02-08 13:07:52 UTC
Whoops, pasted the same link twice. This one: http://www.mathcomp.uni-heidelberg.de/fileadmin/Redakteure/HGS_Templates/HGSMC_blue.jpg
Comment 15 Aron Budea 2017-02-08 22:23:42 UTC
What were the steps you followed? I inserted it in a document, then exported the document to PDF, but the image looked the same (LO 5.3.0.3 / Windows 7). Maybe you did something differently?
Comment 16 Aron Budea 2017-02-20 00:41:08 UTC
So the underlying issue isn't created by the commit identified in comment 8, it just makes the issue occur more frequently. If the original JPGs are preserved and they are CMYK (that's the likely cause), this bug happens.

In fact, the bug can be reproduced by following steps even in 3.3.0:
- Open / create a document with such a JPG included,
- Select File -> Export as PDF...,
- Select Lossless compression, uncheck Reduce image resolution, and click Export.

With these steps, Vedran's image shows similar distortion/decolorization as the reporter's (so probably some settings were different from default).

The regression part is what's been reported in bug 105954, fixing that should reduce the occurrence of this issue. Adjusting keywords and version field.
Comment 17 Timur 2017-02-21 19:11:38 UTC
*** Bug 106095 has been marked as a duplicate of this bug. ***
Comment 18 Steve Edmonds 2017-05-30 22:57:31 UTC
I have just noticed this issue in 5.2. Always reproducible.
I feel it started about the same time as bug 104479 so may be related to the patch that caused that.