Created attachment 317405 [details] output of spumux in dvdauthor-0.6.14-5.fc9.i386 and spumux compiled from source. Description of problem: When trying to multiplex subtitles saved as png-images, spumux skips most of images claiming they have too many colours. The png-images contain only four colours and should be added normally. Version-Release number of selected component (if applicable): dvdauthor-0.6.14-5.fc9.i386 How reproducible: always Steps to Reproduce: 1. Audio and video streams in temp.vob. 2. Subtitles in subs_dir/spumux.xml and png-image of each subtitle. 3. spumux -p -s0 subs_dir/spumux.xml < temp.vob > subs.vob Actual results: ERR: Too many colors in base picture ERR: Blank image, skipping line -1 Expected results: Subtitles added to .vob. Additional info: Multiplexing of subtitles works normally when using spumux compiled from dvdauthor-0.6.14 source instead of dvdauthor-0.6.14-5.fc9.i386.
Did your local build from source use ImageMagick, or GraphicsMagick, or just libpng? Couldy you post the output of "ldd spumux" for the spumux you built from source?
Here is output from ldd spumux: linux-gate.so.1 => (0x00110000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x05a09000) libz.so.1 => /lib/libz.so.1 (0x00ac9000) libm.so.6 => /lib/libm.so.6 (0x00a5e000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00d8b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00111000) libc.so.6 => /lib/libc.so.6 (0x008f3000) libdl.so.2 => /lib/libdl.so.2 (0x00a89000) /lib/ld-linux.so.2 (0x008d3000) As far as I understand it is just libpng.I do have have devel-packages for GraphicsMagick / ImageMagick installed.
I can also confirm that rebuilding spumux by hand (I grabbed the source rpm and used the tarball from there) does help. I ended up with a bit more stuff in my spumux, so it doesn't seem to be libMagick that's causing the problems ...and this is a x86_64 system: % ldd /usr/local/bin/spumux linux-vdso.so.1 => (0x00007fff315ff000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003dfae00000) libz.so.1 => /lib64/libz.so.1 (0x0000003deee00000) libm.so.6 => /lib64/libm.so.6 (0x0000003dee200000) libWand.so.10 => /usr/lib64/libWand.so.10 (0x0000003ded800000) libMagick.so.10 => /usr/lib64/libMagick.so.10 (0x0000003ded000000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003df1600000) libc.so.6 => /lib64/libc.so.6 (0x0000003dede00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003dee600000) liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x0000003e03200000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x0000003e03a00000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003dfb200000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003df1e00000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003df0e00000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003dfda00000) libbz2.so.1 => /lib64/libbz2.so.1 (0x0000003dfbe00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003deea00000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003df5600000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003df5a00000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003df0600000) /lib64/ld-linux-x86-64.so.2 (0x0000003decc00000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003df1200000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003defe00000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003df4e00000) libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x0000003df0200000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003defa00000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003df0a00000)
Ok, thanks for the info - the difference between your two builds and the Fedora one is that Matti's uses plain libpng, Otto's libpng+ImageMagick, but the Fedora one uses libpng+GraphicsMagick (ImageMagick or GraphicsMagick is needed to support other image types than PNG, and GraphicsMagick pulls in less dependencies that are not relevant for dvdauthor). Do you happen to have a set of (smallish) vob, xml and png files that you could upload somewhere that I could use for testing this?
Try this one: http://personal.inet.fi/koti/marketta/spumuxtst.tar.bz2 There is a 12 MB piece of vob and just four subtitles.
Created attachment 317539 [details] Output from dvdauthor-0.6.14-5.fc9.x86_64 Thanks for the test data. I tried it out with dvdauthor-0.6.14-5.fc9.x86_64 and it (spumux -s0 Jappervokkitst.d/spumux.xml < temp.vob > subs.vob) worked just fine. dvdauthor-0.6.14-5.fc9.i386 on the other hand shows the same error as in your output. Downgrading the i386 GraphicsMagick to 1.1.10-3.fc9 did not have any effect. I'm a bit at loss here. Otto mentioned that he had problems with the Fedora originated x86_64 binaries, while they appear to work fine for me. Otto, could you try with Matti's test data with your Fedora originated spumux and ensure that it is indeed the x86_64 one, not i386 (file /usr/bin/spumux)? I'm trying to figure out if this is something that happens with the i386 build only.
I tested compiling dvdauthor and ldd output with either ImageMagick-devel or GraphicsMagick devel installed. Don't know if this has any impact, but below the difference of those two cases. Spumux actually work for me ok in both cases. GraphicsMagick-devel installed: ------------------------------' ... checking for Magick-config... no checking for GraphicsMagick-config... GraphicsMagick-config checking for ExportImagePixels... no configure: ImageMagick/GraphicsMagick does not support the function ExportImagePixels. Please upgrade to ImageMagick 5.5.7 or newer (or the corresponding GraphicsMagick version) checking for zlibVersion in -lz... yes ... [matti@belarus dvdauthor-0.6.14]$ ldd src/spumux linux-gate.so.1 => (0x00110000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x05a09000) libz.so.1 => /lib/libz.so.1 (0x00ac9000) libm.so.6 => /lib/libm.so.6 (0x00a5e000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00d8b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00111000) libc.so.6 => /lib/libc.so.6 (0x008f3000) libdl.so.2 => /lib/libdl.so.2 (0x00a89000) /lib/ld-linux.so.2 (0x008d3000) =========================================================================== ImageMagick-devel installed: ------------------------------ ... configure:4785: checking for Magick-config configure:4801: found /usr/bin/Magick-config configure:4812: result: Magick-config configure:4832: checking for ExportImagePixels configure:4888: gcc -o conftest -g -O2 conftest.c -lWand -lMagick -lWand -lMagick >&5 configure:4894: $? = 0 configure:4911: result: yes ... [matti@belarus dvdauthor-0.6.14]$ ldd src/spumux linux-gate.so.1 => (0x00110000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x05a09000) libz.so.1 => /lib/libz.so.1 (0x00ac9000) libm.so.6 => /lib/libm.so.6 (0x00a5e000) libWand.so.10 => /usr/lib/libWand.so.10 (0x00192000) libMagick.so.10 => /usr/lib/libMagick.so.10 (0x05548000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0025c000) libc.so.6 => /lib/libc.so.6 (0x008f3000) libdl.so.2 => /lib/libdl.so.2 (0x00a89000) /lib/ld-linux.so.2 (0x008d3000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x0550e000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x00cba000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0086c000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00db5000) libXext.so.6 => /usr/lib/libXext.so.6 (0x0078d000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00111000) libbz2.so.1 => /lib/libbz2.so.1 (0x05192000) libpthread.so.0 => /lib/libpthread.so.0 (0x00a90000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00891000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00830000) libX11.so.6 => /usr/lib/libX11.so.6 (0x05c49000) libexpat.so.1 => /lib/libexpat.so.1 (0x00d62000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00d3e000) libuuid.so.1 => /lib/libuuid.so.1 (0x0081a000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x006d4000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x005a8000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x0079f000)
I experienced the old "too many colors" spumux problem with clean x86_64 Fedora 9 (with dvdauthor-0.6.14-5.fc9.x86_64) and Fedora 10 (dvdauthor-0.6.14-6.fc10.x86_64) installations. Peculiarly enough, Matti's spumux test data worked just fine (maybe this is why Ville couldn't see it?), but my 4 megabyte test package is available at: http://www.otto.net/~otto/spumux.problem.tar.bz % file `which spumux` /usr/bin/spumux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped % spumux -m dvd spumux.d/spumux.xml < chunk.mpg > temp.mpg DVDAuthor::spumux, version 0.6.14. Build options: gnugetopt graphicsmagick iconv freetype Send bugs to <dvdauthor-users.net> INFO: Locale=LC_CTYPE=fi_FI@euro;LC_NUMERIC=en_US;LC_TIME=en_DK;LC_COLLATE=fi_FI@euro;LC_MONETARY=fi_FI@euro;LC_MESSAGES=en_US;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C INFO: Converting filenames to ISO-8859-15 INFO: Picture spumux.d/00+00+02.02.png had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Picture spumux.d/00+00+05.46.png had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Max_sub_size=5036 INFO: Picture spumux.d/00+00+19.74.png had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Picture spumux.d/00+00+24.15.png had 8 colors INFO: Constructing blank hlt INFO: Constructing blank sel ERR: Too many colors in base picture ERR: Blank image, skipping line -1 INFO: Picture spumux.d/00+00+29.27.png had 9 colors INFO: Constructing blank hlt INFO: Constructing blank sel ERR: Too many colors in base picture ERR: Blank image, skipping line -1 INFO: Picture spumux.d/00+00+35.66.png had 8 colors INFO: Constructing blank hlt INFO: Constructing blank sel ERR: Too many colors in base picture ERR: Blank image, skipping line -1 INFO: Picture spumux.d/00+00+42.94.png had 8 colors INFO: Constructing blank hlt INFO: Constructing blank sel ERR: Too many colors in base picture ERR: Blank image, skipping line -1 INFO: Found EOF in .sub file. INFO: 3 subtitles added, 4 subtitles skipped, stream: 32, offset: 0.12 Statistics: - Processed 0 subtitles. - The longest display line had -1 characters. - The maximum number of displayed lines was 0. - The normal display height of the font arial.ttf was 0. - The bottom display height of the font arial.ttf was 0. - The biggest subtitle box had 5036 bytes.
Fedora 10, i386 same thing happens, color counts like 8, 13, 15 etc were reported on my (4-color) pictures... yum installed dvdauthor yesterday (2009-01-06): rpm -qi dvdauthor tells Name : dvdauthor Relocations: (not relocatable) Version : 0.6.14 Vendor: Fedora Project Release : 6.fc10 Build Date: Tue 08 Jul 2008 08:17:14 PM EEST Install Date: Tue 06 Jan 2009 09:07:29 PM EET Build Host: x86-2 Group : Applications/Multimedia Source RPM: dvdauthor-0.6.14-6.fc10.src.rpm Size : 355822 License: GPLv2+ Signature : DSA/SHA1, Tue 28 Oct 2008 08:04:20 PM EET, Key ID bf226fcc4ebfc273 Packager : Fedora Project URL : http://dvdauthor.sourceforge.net/ Summary : Command line DVD authoring tool Description : dvdauthor is a program that will generate a DVD movie from a valid mpeg2 stream that should play when you put it in a DVD player. --8<----8<-- I test self-compiled dvdauthor today -- and I can provide some test files is needed.
Self-compiled spumux, not using either ImageMagick or GraphicsMagick, seems to work: the problem would seem to be in the way spumux uses these libraries? % spumux -m dvd spumux.d/spumux.xml < chunk.mpg > temp.mpg DVDAuthor::spumux, version 0.6.14. Build options: gnugetopt iconv freetype Send bugs to <dvdauthor-users.net> INFO: Locale=LC_CTYPE=fi_FI@euro;LC_NUMERIC=en_US;LC_TIME=en_DK;LC_COLLATE=fi_FI@euro;LC_MONETARY=fi_FI@euro;LC_MESSAGES=en_US;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C INFO: Converting filenames to ISO-8859-15 INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Max_sub_size=5036 INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Max_sub_size=5408 INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Max_sub_size=5566 INFO: PNG had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Found EOF in .sub file. INFO: 7 subtitles added, 0 subtitles skipped, stream: 32, offset: 0.12 Statistics: - Processed 0 subtitles. - The longest display line had -1 characters. - The maximum number of displayed lines was 0. - The normal display height of the font arial.ttf was 0. - The bottom display height of the font arial.ttf was 0. - The biggest subtitle box had 5566 bytes.
I also get self-compiled spumux working like that: $ ldd spumux linux-gate.so.1 => (0x00110000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x03e80000) libz.so.1 => /lib/libz.so.1 (0x007ba000) libm.so.6 => /lib/libm.so.6 (0x004f5000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00325000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00b11000) libc.so.6 => /lib/libc.so.6 (0x005f6000) libdl.so.2 => /lib/libdl.so.2 (0x00797000) /lib/ld-linux.so.2 (0x005d1000) The problem I still have is that when I test the result with 'mplayer -sid 0 output.mpg' I can not see any subtitles. Same mplayer, but files spumuxed on Fedora 8 the subtitles works OK Otto: Do you see the subtitles you've spumuxed in ?
This on a f10 x86_64 system: % ldd `which spumux` linux-vdso.so.1 => (0x00007fff32bfe000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003c51e00000) libz.so.1 => /lib64/libz.so.1 (0x0000003c48800000) libm.so.6 => /lib64/libm.so.6 (0x0000003c47c00000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003c4bc00000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003c0e000000) libc.so.6 => /lib64/libc.so.6 (0x0000003c47800000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003c48000000) /lib64/ld-linux-x86-64.so.2 (0x0000003c46400000) True, mplayer doesn't show the subtitles, which is a bit strange. However, the subtitle stream is certainly there, "xine -u 0 output.mpg" (which really should do the same thing as the mplayer command?!) works just fine and dvdstyler is able to properly convert it into a vob on dvd with the subtitle.
Interesting. I used to get xine sigsegv when trying these material. Now it does not sigsegv (yum update today), but says 'unsupported codec'. Well, nothing official fedora can do about that, have to look elsewhere... Anyway, vlc shows subtitles OK when playing video with subtitles muxed with self-compiled spumux. But at this time, vlc can not show subtitles from FC8-spumuxed video files (no menu item to activate subtitles).
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just upgraded from F10 x86_64 -> F11 x86_64 and now spumux appears to work ok with my original test data. Ref. comments from Otto & Tomi on Mplayer's etc ability to show subtitles: In my case Totem and mplayer do not show them, but xine does. ldd output just in case it might help: [matti@belarus spumuxtst]$ ldd `which spumux` linux-vdso.so.1 => (0x00007fff94bfe000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f188c655000) libm.so.6 => /lib64/libm.so.6 (0x00007f188c3d1000) libGraphicsMagick.so.1 => /usr/lib64/libGraphicsMagick.so.1 (0x00007f188c053000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f188bdb9000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f188bb9d000) libc.so.6 => /lib64/libc.so.6 (0x00007f188b82f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f188b62b000) libz.so.1 => /lib64/libz.so.1 (0x00007f188b416000) liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x00007f188b1de000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f188afcc000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f188adc4000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f188aba8000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f188a86d000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f188a65c000) /lib64/ld-linux-x86-64.so.2 (0x00007f188c9a5000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f188a45a000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f188a256000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f188a03b000)
I did some more testing with new material and can confirm that spumux behaviour in F11 x86_64 is exactly like in comment #10 for F10. Spumux built with Graphicsmagick or Imagemagick skips some 80% of subtitles due to too many colours. For some reason with the test file I used in comment #15 there were no problems.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I still don't know what to do about this, but reopening because it isn't reportedly fixed.
Created attachment 355877 [details] Patch for the PNG reader in GraphicsMagick It appears that the bug actually lies within GraphicsMagick and here's a patch against Fedora 10's GraphicsMagick that has made the issue go away for me in at least one test.
Ian, thanks for spending time investigating this. Have you asked GraphicsMagick upstream's thoughts about the patch? GraphicsMagick package maintainers, any thoughts about patch in comment 19? Based on comment 16, it sounds like ImageMagick (or dvdauthor with it) has issues at well. However, the change proposed for GraphicsMagick by Ian is already included in F-11's and later ImageMagick, so maybe there are additional issues lurking or ImageMagick is additionally affected by something else that GraphicsMagick isn't.
I can confirm also what Matti said in comment #16, dvdauthor-0.6.14-8.fc11.x86_64 as delivered with Fedora 11 still has this problem. Using the data from my comment #8, the same error of "too many colors" occurs.
I'm primarily interested in results with a spumux build using ImageMagick on F-11 at the moment in case someone has it handy. If not, I'll try to arrange one myself. The build with GraphicsMagick has already been pointed out as having this problem several times (the dvdauthor as shipped in F-11 is one of these builds).
Ok, some additional findings: ImageMagick 6.4.8-4's changelog has this entry: * Properly set alpha channel in PNGs with palette and tRNS. It tracks down to this patch: http://studio.imagemagick.org/pipermail/magick-developers/2009-January/003087.html So, if this fixes it for ImageMagick, spumux+ImageMagick should _not_ work currently in F-10 but _should_ work in F-11+.
GraphicsMagick upstream bug report/inquiry: https://sourceforge.net/tracker/?func=detail&aid=2831240&group_id=73485&atid=537937
Referring to comment #22 I compiled again dvdauthor with ImageMagick-6.5.1.2-1.fc11 and this spumux works ok without the "too many colors"-error (I don't know what I messed in the test for comment #16, but now it is ok). With GraphicsMagick still no success stories to tell. Here is ldd output for this local build: [matti@belarus work]$ ldd /home/matti/spumux linux-vdso.so.1 => (0x00007fff301ff000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003123000000) libz.so.1 => /lib64/libz.so.1 (0x0000003119200000) libm.so.6 => /lib64/libm.so.6 (0x0000003118600000) libMagickCore.so.2 => /usr/lib64/libMagickCore.so.2 (0x0000003fa7800000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003c87a00000) libc.so.6 => /lib64/libc.so.6 (0x0000003118200000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003118a00000) liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x0000003126000000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x0000003485800000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003127400000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003c87e00000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003fa7400000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003124000000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003123800000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003fa7000000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003fab600000) libbz2.so.1 => /lib64/libbz2.so.1 (0x0000003128800000) libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x000000311b200000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003118e00000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x000000312f400000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003122400000) /lib64/ld-linux-x86-64.so.2 (0x0000003117e00000) libexpat.so.1 => /lib64/libexpat.so.1 (0x000000311ba00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000311aa00000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003122c00000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003fb4200000) librt.so.1 => /lib64/librt.so.1 (0x0000003119600000)
GraphicsMagick upstream accepted the ImageMagick patch (it hasn't been applied yet though), but given others' reports and since the patch fixes test cases for me on F-10, I'm ready to point finger at GraphicsMagick. Cc'ing Rex who has done most of GraphicsMagick packaging work lately it seems. Scratch builds for testing, please report how they work for you: - F-10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1577173 - F-11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1577207 - Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=1577219 Patches applied in the above: F-10 and F-11: http://scop.fedorapeople.org/patches/GraphicsMagick/GraphicsMagick-1.1.14-png-alpha-463258.patch Rawhide: http://scop.fedorapeople.org/patches/GraphicsMagick/GraphicsMagick-1.3.6-png-alpha-463258.patch
Upstream reports that the fix has been committed (practically same one as in comment 26) and will appear in GM 1.2.8 and 1.3.7. Here's the 1.3.x one: http://cvs.graphicsmagick.org/cgi-bin/cvsweb.cgi/GraphicsMagick/coders/png.c.diff?r1=1.424;r2=1.425
GraphicsMagick-1.1.14-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/GraphicsMagick-1.1.14-4.fc10
koffice-1.6.3-25.20090306svn.fc11, dvdauthor-0.6.14-9.fc11, GraphicsMagick-1.3.7-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update koffice dvdauthor GraphicsMagick'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9839
GraphicsMagick-1.1.14-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update GraphicsMagick'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9898
koffice-1.6.3-25.20090306svn.fc11, dvdauthor-0.6.14-9.fc11, GraphicsMagick-1.3.7-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
GraphicsMagick-1.1.14-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.