Bug 33853 - PNG images cannot be loaded from ODF documents
Summary: PNG images cannot be loaded from ODF documents
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images
  Show dependency treegraph
 
Reported: 2011-02-02 14:38 UTC by Thorsten Behrens (allotropia)
Modified: 2018-01-14 14:55 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
bugdoc (76.94 KB, application/zip)
2011-02-02 14:39 UTC, Thorsten Behrens (allotropia)
Details
sample image, see Comment 3 (1.56 KB, image/png)
2011-02-03 03:09 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Behrens (allotropia) 2011-02-02 14:38:36 UTC
There seems to be a class of PNG images that LibO cannot load anymore (but OOo can). See attached bugdoc.
Comment 1 Thorsten Behrens (allotropia) 2011-02-02 14:39:15 UTC
Created attachment 42874 [details]
bugdoc
Comment 2 wope 2011-02-03 01:59:29 UTC
the main difference between working and errornous pictures are in the IHDR chunk of the file. If the colortype byte is 6, the file works, if it is 2, it dosnt
work. In the specification 
(http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.IHDR)
stand:
   Color    Allowed    Interpretation
   Type    Bit Depths
   2       8,16        Each pixel is an R,G,B triple.
   6       8,16        Each pixel is an R,G,B triple,
                          followed by an alpha sample.

If you open the errornous file with MS Paint and save it again, it works.
Comment 3 Rainer Bielefeld Retired 2011-02-03 03:08:59 UTC
[Reproducible] with "LibreOffice 3.3.0 RC4 - WIN7  Home Premium (64bit) German UI  [OOO330m19 (build 6 / tag 3.3.0.4)]"

It's not a WRITER, but a general problem. I extracted the picture 
100000000000007400000060D55E1F69.png
If you try to insert it to a DRAW document or to open it with DRAW, you will get some filter error message ("Grafikfilter nicht gefunden").

No Problem with OOo 3.1.1, 3.4-dev and 1.4.1 (!)

I am pretty sure that all OS will be affected, but currently information is missing. 

@all:
What OS did you use for your test?
Comment 4 Rainer Bielefeld Retired 2011-02-03 03:09:51 UTC
Created attachment 42890 [details]
sample image, see Comment 3
Comment 5 wope 2011-02-03 03:47:28 UTC
I testet it with Win 7 and sUse 1.3, it is OS independ.AMD64 and x86
Comment 6 Björn Michaelsen 2011-12-23 11:52:45 UTC Comment hidden (obsolete)
Comment 7 sasha.libreoffice 2012-01-19 08:42:52 UTC
reproduced in LibO 3.5.0 beta 2 on Fedora 64 bit
some other experiment done:
MSWord 2007 on Windows XP opens this file with part of picture,
MSWord 2010 on Windows 7 opens all correctly
if extract picture from odt file:
Gimp opens part of picture on Windows and Linux
MSWord 2003 and default picture viewer on Windows opens picture correctly
if drag and drop picture to LibO, it creates new section (not recognizes file as picture)
Comment 8 Alex Thurgood 2012-01-23 07:27:50 UTC
Not sure whether this adds any useful information, but :

on Mac OSX, LibO 3.5RC1

1) I open a ODT document made with LIbO 3.3.x containing an *inserted* (not linked) PNG file in it (for example, my signature, which has alpha channel), the image frame holder displays an error and the PNG file is not shown.

2) If I then save that document in 3.5RC1, and then attempt to open it again in 3.3.4, for example, I get an general IO error message, and the document will not open. If I retry once more, the document will open, but the image file is now missing.

3) Once I re-insert the same PNG file via 3.3.4, the same ODT file opens fine in :

LibO 3.3.4
LibO 3.4.3
LibO 3.4.4

LibO-dev 3.5.0 
Build ID: e42dfec-c60ac25-41e7bcd-3b66bd0
 
LOdev 3.6.0 
Build ID: 87ec1f8-b204871-95bcc5e-4c1bcb5

and also LibO 3.5RC1, but the fact remains that the first time such a file is opened, it can not read the PNG file. Somehow, the reference to the file seems to get broken, despite it being inserted.

Quite possibly, this is not the same problem as the bug report.


Alex
Comment 9 bfoman (inactive) 2013-08-14 21:03:55 UTC
Confirmed with:
Version: 4.2.0.0.alpha0+
Build ID: 087a610fcd5c0c354a9ed6bfccd3451b667d62a3
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_21:41:24
Windows 8.1 Enterprise Preview 64 bit

Picture is still not displayed. All good in Word 2013.
Comment 10 Julien Nabet 2013-10-25 23:11:14 UTC
I don't know if it may help since I don't know how to test a newer libpng version but last libpng version is 1.6.6 (see http://download.sourceforge.net/libpng/libpng-1.6.6.tar.gz). Now of course there could be some API incompatibilities.
Comment 11 QA Administrators 2015-04-01 14:42:39 UTC Comment hidden (obsolete)
Comment 12 Buovjaga 2015-04-24 17:07:48 UTC
Still read error.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64)
Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50
Locale: fi_FI
Comment 13 MM 2015-05-09 12:57:39 UTC
If this is an issue with libpng, which one did work back then ?
Last version that worked for me is Go-OO 3.2.0. LO 3.3.4 under win7 didn't work any longer.
Tried different programs, but just a few worked (all microsoft programs), read: loading the extracted sample correctly.

Works:

IE11, paint, windows photo viewer.

Doesn't work:

VLC, Media player classic, xnview, Firefox, palemoon, opera dev (just loads the top). Even online converters can't convert them.

Seems that all of these last programs have updated their libpng or else microsoft found a way to load these images.

When I use pngtest I get the outcome:

'Pass 0: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrw1.png: libpng warning: IDAT: invalid distance too far back
libpng error: IDAT: invalid distance too far back'

When I use pngfix it says:

'In particular the zlib error:
      "invalid distance too far back"

 caused by an incorrect optimization of a zlib stream is fixed in any
 compressed chunk in which it is encountered.  An integrity problem of the
 PNG stream caused by a bug in libpng which wrote an incorrect chunk length
 is also fixed.'

So it could be an error in zlib or an error in libpng or a bit of both.
Maybe the correct way of handling these files are to fix them instead of trying to fix the code.
Comment 14 QA Administrators 2016-09-20 09:42:29 UTC Comment hidden (obsolete)
Comment 15 Telesto 2016-11-15 12:40:56 UTC
Confirmed on
Version: 5.3.0.0.alpha1+
Build ID: bb50b1609abe83265311613db4a18e992dc666c8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-14_23:25:25
Locale: nl-NL (nl_NL); Calc: CL
Comment 16 MM 2017-01-08 01:22:15 UTC
(In reply to Telesto from comment #15)
> Confirmed on
> Version: 5.3.0.0.alpha1+
> Build ID: bb50b1609abe83265311613db4a18e992dc666c8
> CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine:
> new; 
> TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-14_23:25:25
> Locale: nl-NL (nl_NL); Calc: CL

It's still confirmed coz it's (probably) a libpng problem. The author won't/can't fix it, because he wants to move on with the code (or that's how I read it). The changes that have been made to the code is that the 'too-far-back' isn't shown anymore, but not to read the older files. Read some more here: https://bugzilla.mozilla.org/show_bug.cgi?id=841734#c9

So maybe it's better to fix the png's instead ?!
Comment 17 QA Administrators 2018-01-09 03:28:54 UTC Comment hidden (obsolete)
Comment 18 Rainer Bielefeld Retired 2018-01-09 05:59:42 UTC Comment hidden (no-value)
Comment 19 Buovjaga 2018-01-14 14:55:02 UTC
(In reply to MM from comment #16)
> So maybe it's better to fix the png's instead ?!

I think you are right. A developer even wrote a handy utility to fix all the broken pngs on one's computer: http://archscientist.altervista.org/blog/how-to-solve-libpng-error-idat-invalid-distance-too-far-back/