libpng16 does no longer read icons

English Applications
1

Hi,

since a recent opensuse online update, I can’t load png-type icons any more. The icons are to be loaded within a Qt application.
Error messages are:
libpng error: bad parameters to zlib
…
libpng warning: iCCP: bad parameters to zlib
…
libpng warning: Image width is zero in IHDR
libpng warning: Image height is zero in IHDR
libpng error: Invalid IHDR data

From various sites on the internet, I find that this is probably be caused by a change in libpng16 with respect to earlier versions.

Unfortunately, I can not revert to some older libpng version, because Qt uses libpng16.so.16.

Is there any solution to this?

Thanks and Best regards
Bernd

2

You could try to fix your files with optipng.
If that doesn’t work, you would have to use optipng with an earlier libpng (maybe from an earlier openSUSE version) I suppose.

3

Thanks …

By the way: I am using opensuse 13.1, version of libpng16 is 1.6.6. I can not downgrade from this version, because several other packages (in partcular, Qt code automatically links to libpng16.so.16) do rely on this.

I have tried optipng , but it does not do anything to the file, and says the file is optimized already:


** Processing: fileexport.png
16x16 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 8 bits/pixel, 151 colors (28 transparent) in palette
Input IDAT size = 691 bytes
Input file size = 829 bytes

Trying:
  zc = 9  zm = 8  zs = 0  f = 0         IDAT size = 247
  zc = 9  zm = 8  zs = 0  f = 5         IDAT size = 242
  zc = 9  zm = 8  zs = 1  f = 5         IDAT size = 236
  zc = 9  zm = 8  zs = 3  f = 5         IDAT size = 234

fileexport.png is already optimized.

The same happens with pngfix:


IDAT OK  maximum 15 15 691 1040 fileexport.png

So, since the more recent version of optipng/pngfix seem to be fine with the file, an earlier version of optipng does not have to be tested. Or do you think it should?

Could there be a problem with Qt?

Best regards
Bernd

4

Yes, but you said an update caused this. You should be able to switch back to the libpng16 version from the standard OSS repo (click on “Versions” in YaST for that).

I have tried optipng , but it does not do anything to the file, and says the file is optimized already:

Did you try to specify the “-fix” and “-force” options?

So, since the more recent version of optipng/pngfix seem to be fine with the file, an earlier version of optipng does not have to be tested. Or do you think it should?

Well, according to the error messages you posted, those files have invalid dimensions in the IHDR.
Not sure if that’s the issue though.
optipng seems to be able to open them fine though, so I guess it’s not necessary to try with an earlier optipng version.

You could try to open them with an application that doesn’t use libpng16 (xv f.e.) and save it again. Maybe this would help?

Could there be a problem with Qt?

Maybe. You should also be able to roll back libqt4 to the version from the standard repo as a test.

Could you maybe upload one of the icons to http://susepaste.org and post a link, so I could have a look at them myself?

5

Interesting, just last night I decided to tackle this same issue, which I have experienced since at least December 2013 when I first installed 13.1/KDE 4.12.0 on my desktop.
My recollection is imprecise - but I believe I saw same issues when running 12.3 as well

For me, the program I see it on is vuescan, a scanner GUI (not open source).
From on-line search, I see folks running Ubuntu with similar issue.
I’ll note, however, that I only see the error messages when I start the program from CLI, so others could be affected as well.
I have sort of become used to ignoring the red x one gets when the icon fails to appear; otherwise the functionality of vuescan is unaffected.

I had been running with libpng version 1.6.6-12.1x86_64 from 13.1 Update repo.
Following wolfi’s suggestion I reverted to libpng version 1.6.6-1.1-x86_64 from the 13.1 OSS repo.
I still see the same error message.

I chose to focus on the first icon that was listed in error message

(vuescan:8394): Gtk-WARNING **: Error loading icon: Failed to load image '/usr/share/icons/oxygen/16x16/actions/dialog-cancel.png': Fatal error in PNG image file: bad parameters to zlib

I then ran both pngfix and optipng on that file, with results “OK” similar to BerndSpeiser

So I tried this

optipng -force ~/temp/pngplay/dialog-cancel.png
** Processing: /home/carl/temp/pngplay/dialog-cancel.png
16x16 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 8 bits/pixel, 149 colors (67 transparent) in palette
Input IDAT size = 717 bytes
Input file size = 848 bytes

Trying:
  zc = 9  zm = 8  zs = 0  f = 0         IDAT size = 218
                               
Selecting parameters:
  zc = 9  zm = 8  zs = 0  f = 0         IDAT size = 218

Output IDAT size = 218 bytes (499 bytes decrease)
Output file size = 886 bytes (38 bytes = 4.48% increase)

I had made a copy so I could run as user.
I copied (as root) the modified icon file back to /usr/share/icons/oxygen/16x16/actions/dialog-cancel.png.

I reran vuescan from the CLI, still see this icon as an error so no change with the modified icon.

The original file is HERE
The ‘improved’, slightly larger file is HERE
Both display OK in gwenview

I have chatted with vuescan’s author in the past, he believes the issue is in QT4.
Linux is not the primary target for vuescan and his test platform is rather dated.

BerndSpeiser - what program are you seeing this with?

6

Maybe I was mislead when saying that “a recent update” caused libpng to fail. However, I can say that with an opensuse 12.3 installation having libpng15.so.15, the icons load perfectly.
As to wolfi’s suggestion, I tried to use xv to “transform” the icon - the file size changes somewhat, but the error messages are the same.
Also, following his suggestion, I tried optipng with the -fix and -force options (I dodn’t use -force before), and now indeed the output is changed:


optipng -fix -force -out output_opti.png fileimport.png 
** Processing: fileimport.png
16x16 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 8 bits/pixel, 193 colors (75 transparent) in palette
Input IDAT size = 736 bytes
Input file size = 851 bytes

Trying:
  zc = 9  zm = 8  zs = 0  f = 0         IDAT size = 241
  zc = 9  zm = 8  zs = 0  f = 5         IDAT size = 236
  zc = 9  zm = 8  zs = 1  f = 5         IDAT size = 234
  zc = 9  zm = 8  zs = 3  f = 5         IDAT size = 231

Selecting parameters:
  zc = 9  zm = 8  zs = 3  f = 5         IDAT size = 231

Output file: output_opti.png

Output IDAT size = 231 bytes (505 bytes decrease)
Output file size = 1019 bytes (168 bytes = 19.74% increase)

However, the new file is also not read into the Qt application. Anyway, both xv and optipng seem to be able to read the *.png quite well.
The icon has been uploaded to URL: http://susepaste.org/51514864

All this leads me to the conclusion that libpng is not the real problem, but rather zlib - remember the first error message is

libpng error: bad parameters to zlib

or whatever calls this (Qt?).

I have experimented with the code (by the way, to answer cmcgrath’s question, I am maintaining some code for an electrochemical simulation package developed here; this was originally written to use Qt3, but later adapted to Qt4) where the problem appears, and I find that the `bad parameters to zlib’ message appears when the icon is read by Qt into the program. The other error messages

libpng error: Invalid IHDR data

appear some time later during the run (I would assume, when the icons are becoming to be displayed).

The zlib version on the opensuse 13.1 system is 1.2.8, while the opensuse 12.3 has zlib 1.2.7.
I guess it would make sense to downgrade zlib on the 13.1 system as a test. However, unfortunately, I will be quite busy with urgent work for a couple of days, and can only do more testing after the other stuff is finished. So, I might be a little slow in answering questions as well.

7

As part of my investigation this AM I went looking for zlib (Yast Software Mght) and, only seeing zlib-devel rpms in the repos, and a bit of search, concluded that zlib is now part of the kernel, perhaps? A search for zlib with “RPM provides” lists the kernel first.
I am sure wolfi can confirm or correct this comment.

There must be something unique (or should I say, uniquely broken) in the way vuescan and your software make these calls into QT4, since most apps seem OK and these are fairly basic navigation icons that are affected.

You might want to try a Google search on “Gtk-WARNING **: Error loading icon: bad parameters to zlib”.
I see items from ArchLinux and a implication that this started when libpng went from 1.6.2 to 1.6.3.
My 13.1 is at libpng 1.6.6 (from OSS repo)
Perhaps the discussion there will help you - I am not a developer so can read the discussion but not do much with it. :wink:

Good luck, happy hunting.

8

No, zlib is not part of the kernel. But the library package is named “libz1”, according to openSUSE’s shared library packaging policy.

There must be something unique (or should I say, uniquely broken) in the way vuescan and your software make these calls into QT4, since most apps seem OK and these are fairly basic navigation icons that are affected.

Maybe. Gwenview uses libpng16 as well and shows the image correctly as you said.

I just tried with Qt Designer, and that can load both your and BerndSpeiser’s icons just fine. So it doesn’t seem to be a general Qt problem either.

Ah, ok.

All this leads me to the conclusion that libpng is not the real problem, but rather zlib - remember the first error message is

libpng error: bad parameters to zlib

or whatever calls this (Qt?).

Right. I spotted that error message as well. But I hoped optipng would fix that maybe.
The invalid width/height messages are just warnings anyway.

The zlib version on the opensuse 13.1 system is 1.2.8, while the opensuse 12.3 has zlib 1.2.7.

I guess it would make sense to downgrade zlib on the 13.1 system as a test. However, unfortunately, I will be quite busy with urgent work for a couple of days, and can only do more testing after the other stuff is finished. So, I might be a little slow in answering questions as well.

Would be interesting to know whether installing 12.3’s libz1 helps.

I would try to investigate as well, but as it is I cannot really reproduce the problem here.
I may try to install vuescan though.

9

Well, I can reproduce the Vuescan problem.
But this is definitely not a Qt4 problem, as Vuescan is a GTK2 application. Apparently GTK2 has problems reading the oxygen icons. Strange though that it still tries to load them when I select a different GTK2 theme and a different icon set in “Systemsettings”->“Application Appearance”->“Gtk”…

Not sure if that is related in any way to the original problem here, though.

10

Thanks for taking a look at vuescan, wolfi.

I apologize for this obviously incorrect statement

I have chatted with vuescan’s author in the past, he believes the issue is in QT4.
Linux is not the primary target for vuescan and his test platform is rather dated.

My error message is obviously coming from GTK and his comments was "issue is in GTK2 " !, and vuescan started to behave poorly relative to icon display back when GTK2 came along.
Sometimes my typing gets disconnected from my brain :stuck_out_tongue:

Aside from the incorrect icons, vuescan functionality remains OK.

When I get a chance I am going to try and replicate the Test platform (Ubuntu 10.10) vuescan uses in a VM, to see if it helps provide info.
Will report back anything useful.

THIS item from Arch sort of looks similar, but at the moment I am not in to recompiling libpng, the apparent temporary fix for a similar(?) problem there.

11

Yes, I found that bug report. I have downloaded the 1.6.0 src package from the graphics repo (this one is still available for 11.4 only…) and am going to try that.
But I really would say this is a bug/incompatibility in Gtk2. As I said, I can open the oxygen icons with any other libpng16-using application I tried (and I tried some more now, like libreoffice, geeqie, and EOG).
The oxygen icons can obviously also be loaded fine by Qt4, so I don’t think those 2 problems are related.
The question is I think, whether the OP’s problem is caused by a bug/incompatibility in Qt4, or in the way his program loads the icons, or the icons themselves may be broken (but again, I also could open the icon he provided with all those programs, and optipng/png_fix didn’t find errors either, so I guess we could dismiss that possibility).

So @BerndSpeiser:
Could you maybe provide a code snippet how exactly the icons get loaded? Or are they just specified in the UI?
But I did try to load the icon in Qt4-Designer (as an icon for a push button) and that worked fine as well.

Btw, I think now that the “libpng error: Invalid IHDR data” could just be a consequence of the earlier “libpng error: bad parameters to zlib” error, i.e. because the image got decompressed incorrectly/not at all.

12

PS: At least with Vuescan, downgrading libpng16 to 1.6.0 doesn’t change anything. I guess I’ll try downgrading libz1 next…

The last comments in that Arch do also suggest that downgrading libpng16 doesn’t help anymore.

Edit:
Downgrading libz1 to the 12.3 version doesn’t help either.

13

Hm, strange enough, even gtk-demo (included in gtk2-devel, and uses Gtk2 to load images obviously) can load/display the oxygen icons correctly that Vuescan chokes on (and BerndSpeiser’s icon as well).

14

I managed to load Ubuntu 12.04 LTS into a Vbox VM.

Loaded Vuescan, have it initiating and displaying correctly the first icon dialog-cancel.png that fails on oS 13.1.

LTS is running libpng12-0 1.2.46-3ubuntu4 and zlib1g 1:1.2.3.4.dfsg-3ubuntu4
Obviously this is an older libpng.

Your results with gtk-demo are puzzling, yes.

15

Wait a moment.
On openSUSE it cannot load the oxygen icons. I don’t think Ubuntu installs them by default. (or did you use Kubuntu?)
See also your error message:

(vuescan:8394): Gtk-WARNING **: Error loading icon: Failed to load image '/usr/share/icons/oxygen/16x16/actions/dialog-cancel.png': Fatal error in PNG image file: bad parameters to zlib

So that comparison doesn’t really help. And at least the OP’s problem did not exist in openSUSE 12.3 either (with libpng15).

I guess on an openSUSE 13.1 GNOME-only installation vuescan would work as well. I will try that now.

16

I dislike the GNOME interface so have little working knowledge of what a GNOME-only install would look like.

The VM I tested on is Ubuntu 12.04 LTS, not a Kubuntu.
So it is GNOME, and if I really liked double clicking everything I would probably still be running Windows :wink:

I do see a directory /usr/share/icons/oxygen/… as well as several other (themes?)
I am not sure how to tell which theme is running.
I really, really find the UI there ‘limited’, but then I am looking for things with a KDE4 mindset, I suppose

17

Well, I don’t know what exactly Ubuntu installs by default.
But “Oxygen” is KDE’s default icon theme (and widget theme), so I doubt that it gets installed by default on Ubuntu (at least not the full icon set).
/usr/share/icons/oxygen/ might still be there of course, because some applications might install some icons there.

Have you checked whether /usr/share/icons/oxygen/16x16/actions/dialog-cancel.png exists, f.e.?
If it is not there, it cannot cause an error of course.
But I doubt that Ubuntu (i.e. GNOME) would use Oxygen as default icon theme even if it were installed. :wink:

I really, really find the UI there ‘limited’, but then I am looking for things with a KDE4 mindset, I suppose

I can understand that… :wink:

18

There seem to be a lot more icons in oxygen/ (>6300 files) than /gnome, but icons on GUI don’t look like oxygen.
It would appear some support for KDE is loaded with the default install, but there are no install choices or indicators as to what is really loading.
Information hiding almost as bad as Win.

The file /usr/share/icons/oxygen/16x16/actions/dialog-cancel.png does exist.

I looked,

carl@carl-Ubuntu-LTS:/usr/share/icons$ find . -name dialog-cancel.* -type f
./oxygen/48x48/actions/dialog-cancel.png
./oxygen/22x22/actions/dialog-cancel.png
./oxygen/32x32/actions/dialog-cancel.png
./oxygen/16x16/actions/dialog-cancel.png
./HighContrast/scalable/actions/dialog-cancel.svg

What vuescan is using looks more like oxygen than HighContrast, but with modified colors

19

OK, this does sound like the full oxygen icon set. That’s about as much files as I have on my openSUSE with KDE. Strange though that you would have much less in gnome. Here (KDE-only openSUSE install) I have 6495 files in gnome, but only 6389 in oxygen.
OTOH, hicolor is the default fallback in any case, so maybe Ubuntu’s GNOME has more icons in there then?
But anyway, doesn’t really matter for this thread.

As I said, I don’t think that GNOME would use oxygen by default. I suppose it would use gnome, with a fallback to hicolor (as defined by freedesktop.org).
Or maybe Ubuntu even has a different default icon theme.

What vuescan is using looks more like oxygen than HighContrast, but with modified colors

I have installed openSUSE GNOME now in VirtualBox.
GNOME really crawls here in VB (KDE runs fine, even in VB… :wink: ), I would nearly call it unusable.
That’s what you get when using a window manager that requires OpenGL support…

/usr/share/icons/oxygen/ does exist here as well, but is mostly empty except for 132 icons (the menu category icons from the package “desktop-data-openSUSE”). And /usr/share/icons/gnome/ contains 7014 objects…

I tried Vuescan as well, and as expected I don’t get those libpng/zlib errors any more, as the oxygen icons are not there and are not loaded. (I do get thousands of other GdkPixbuf-related messages though that I didn’t get in KDE, must be because of the used Gtk-Theme)
The default GNOME theme doesn’t use any icons on the buttons as well, but I think that’s by design as it shows at least the lighbulb in the help window.
And switching the GTK2 theme to “Adawaita” those images are shown on KDE as well (and I get those GdkPixbuf messages… :wink: ).

But in the meantime I’m not at all sure any more that we’re talking about the same thing. I am talking about the theme’s images and additional icons on the pushbuttons, like the “Close” button in the help window that pops up at startup. That’s where the oxygen icons are used and NOT displayed here. The standard VueScan icons (like the zoom and rotate icons in the standard window) DO show up fine here, even on my standard 13.1 KDE system.
Do you mean that those are not displayed for you?

Here’s a screenshot from my openSUSE KDE system:
http://wstaw.org/m/2014/03/22/vuescan1.png

Do you see something else?

Btw, since only the theme’s buttons/pixmaps are affected, it might even be a bug/incompatibility in gtk2-theme-oxygen.

20

I guess I can dismiss this idea as well, because other Gtk2 applications like audacity, gimp, or xscreensaver-demo do NOT show this problem with the gtk2-oxygen-theme.
Must be something that VueScan does wrong then (supposedly in its usage of Gtk2, which seems not to be compatible with gt2-theme-oxygen). But as it’s closed-source, I don’t know how to further investigate.

I don’t think that this helps the OP in any way, but I still (or even more now) think that the program does something wrong there as well.
Another idea: try to save the icon(s) as GIF. (rename them to the original filename including the .png suffix then, so that the application finds them)
Does it work then?