Bug 599000

I have the same issue, and also a proposal for a patch in dvdauthor sources.
Something definitely changed when GraphicsMagick transitioned from version
1.3.7 (fc12) to version 1.3.12 (fc13), however there is a piece of code
in file src/subgen-image.c of package dvdauthor that reads as follows
(from line 206):

#if defined(HAVE_MAGICK) && MagickLibVersion >= 0x600
            p.t=pdata[x*4+3];
#else
            p.t=255-pdata[x*4+3];
#endif

this piece of code is compiled only if dvdauthor is linked against
ImageMagick (HAVE_MAGICK is defined in that case) or against
GraphicsMagick (HAVE_GMAGICK is defined).  It seems that the first
of the two mutually optional lines is used instead of the other.  Here
is my proposal:

--- src/subgen-image.c.orig     2010-06-03 18:35:33.421183962 +0200
+++ src/subgen-image.c  2010-06-03 18:44:29.665436079 +0200
@@ -203,7 +203,7 @@
             p.b=pdata[x*4+2];
             // the meaning of RGBA swapped with ImageMagick 6.0.0...
             // ...but not with GraphicsMagick
-#if defined(HAVE_MAGICK) && MagickLibVersion >= 0x600
+#if (defined(HAVE_MAGICK) && MagickLibVersion >= 0x600) || (defined(HAVE_GMAGICK) && MagickLibVersion >= 0x90000)
             p.t=pdata[x*4+3];
 #else
             p.t=255-pdata[x*4+3];

the symbol MagickLibVersion has a somewhat strange value defined in
/usr/include/GraphicsMagic/magick/version.h, which seems to have nothing
to do with the textual version; it was 0x050200 in version 1.3.7 of
GraphicsMagick (fc12) and is now 0x090600 in version 1.3.12, so the comparison
value 0x90000 is just an arbitrary proposal.

Thanks for investigating, Maurizio.  Could you or "redtux" provide a set of files (spu.xml, *.png and *.mpg, link in private mail if you prefer especially if the mpg is large) that can be used to reproduce this?  I'd like to verify this myself and to dig deeper to find in which GraphicsMagick version things changed.

(In reply to comment #2)
> Thanks for investigating, Maurizio.  Could you or "redtux" provide a set of
> files (spu.xml, *.png and *.mpg, link in private mail if you prefer especially
> if the mpg is large) that can be used to reproduce this?  I'd like to verify
> this myself and to dig deeper to find in which GraphicsMagick version things
> changed.    

You can find sample files in http://dmf.unicatt.it/~paolini/spumux/

menu.xml
buttons*.png
menu.mpg

are input files for "spumux menu.xml <menu.mpg >menu_with_subtitles.mpg

there are also two resulting mpg: menu_nofix.mpg obtained with the last
dvdauthor rpm (dvdauthor-0.6.18-1.fc13.i686.rpm), whereas menu_fix.mpg
was obtained with my proposed fix.
You should note that spumux wrongly finds only 1 color in the png images:
[...]
INFO: Picture buttons.png had 1 colors
[...]
whereas it shoud find 2 colors.

Thanks, revised patch submitted upstream:

https://sourceforge.net/mailarchive/forum.php?thread_name=1275825478-17482-1-git-send-email-ville.skytta%40iki.fi&forum_name=dvdauthor-developer

Lawrence, can we expect a new upstream dvdauthor release soon?

(In reply to comment #4)
> Thanks, revised patch submitted upstream:
> 
> https://sourceforge.net/mailarchive/forum.php?thread_name=1275825478-17482-1-git-send-email-ville.skytta%40iki.fi&forum_name=dvdauthor-developer
> 
> Lawrence, can we expect a new upstream dvdauthor release soon?    

Thank you! I had a look and realized that my patch would be problematic because
it would require some dependency between dvdauthor and graphicsmagick rpm packages. If the next upstream dvdauthor release is not due shortly it could make sense to include your patch as part of an updated rpm...

(In reply to comment #5)

> Thank you! I had a look and realized that my patch would be problematic because
> it would require some dependency between dvdauthor and graphicsmagick rpm
> packages.

Sure, but it's not your fault, the problem already existed for ImageMagick in upstream code...

> If the next upstream dvdauthor release is not due shortly it could
> make sense to include your patch as part of an updated rpm...    

That's the plan; if no new upstream release is imminent, I'll take a look at shipping a patched package next week.

I’ve been doing a lot of major changes to DVDAuthor, and there’s still some more I’d like to do before calling it another release. So yes, probably best if you do this patch for Fedora for now.

I made a slight change (moved the test outside of the loops), and committed my version of the patch here:

http://github.com/ldo/dvdauthor/commit/b48152519fd189b19a85b89d7d9330164c840e24

I would also like to invite anybody who’s serious about using DVDAuthor to please try out the Git version here

http://github.com/ldo/dvdauthor

and let me know of any bugs.

Lawrence D’Oliveiro
principal developer, DVDAuthor

dvdauthor-0.6.18-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/dvdauthor-0.6.18-2.fc13

dvdauthor-0.6.18-2.fc13 has been pushed to the Fedora 13 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 dvdauthor'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/dvdauthor-0.6.18-2.fc13

dvdauthor-0.6.18-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.