Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: libpng16 does no longer read icons

  1. #1

    Default libpng16 does no longer read icons

    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. #2

    Default Re: libpng16 does no longer read icons

    Quote Originally Posted by BerndSpeiser View Post
    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?
    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. #3

    Default Re: libpng16 does no longer read icons

    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:
    Code:
    ** 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:
    Code:
    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. #4

    Default Re: libpng16 does no longer read icons

    Quote Originally Posted by BerndSpeiser View Post
    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.
    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. #5
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: libpng16 does no longer read icons

    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
    Code:
    (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
    Code:
    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?
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  6. #6

    Default Re: libpng16 does no longer read icons

    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:
    Code:
    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
    Code:
    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
    Code:
    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. #7
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: libpng16 does no longer read icons

    Quote Originally Posted by BerndSpeiser View Post

    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.
    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.

    Good luck, happy hunting.
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  8. #8

    Default Re: libpng16 does no longer read icons

    Quote Originally Posted by cmcgrath5035 View Post
    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.
    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.

    Quote Originally Posted by BerndSpeiser View Post
    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.
    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
    Code:
    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. #9

    Default Re: libpng16 does no longer read icons

    Quote Originally Posted by wolfi323 View Post
    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.
    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.
    Last edited by wolfi323; 21-Mar-2014 at 04:38.

  10. #10
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: libpng16 does no longer read icons

    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

    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.
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

Page 1 of 4 123 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •