I'm having a problem with ImageMagick as built on trustix-2.2, version
6.2.9, 6.3.0 (trustix provided) and 6.3.2.

Test files are located at:
http://thwartedefforts.org/software/imagemagick-trustix-busted/

The script imagemagick-test001.txt is a perl script that exhibits
strange behavior on trustix-2.2 but not on debian (with a self compiled
ImageMagick and PerlMagick, various versions) nor on Fedora Core 5.

The script can be run with:

        perl imagemagick-test001.txt testimage.jpg > /tmp/output.jpg

The script loads an image, cuts out the white around the image by
creating a mask that doesn't include the white, and then composites that
image over a solid background.

The problem is that the mask specified for an image composite operation
does not respect gravity.  The gravity specified is East, but the mask
seems to either stay anchored in the upper left or only move slightly.
I suspect it doesn't move at all, if gravity West is specified, the mask
is positioned correctly.

The file testimage.jpg is layed out in such a way that, when run through
the test script, makes the problem visually obvious (the right edge of
the triangle is a little wavy, which can be used to see that the mask is
not properly offset).

The file output-fc5.jpg was generated on my Fedora Core 5 desktop
machine with ImageMagick-6.2.5-4.2.1.fc5.7.  

The file output-other.jpg was generated on a CentOS 4.4 machine running
ImageMagick 6.2.9.  It is identical to output-fc5.jpg.  A file generated
on debian was also identical.

The file output-trustix22.jpg was generated on my trustix-2.2
installation.  The problem persists no matter what version of
ImageMagick is installed/in use on the trustix-2.2 machine (trustix rpm
of 6.3.0, self compiled 6.2.9 (rpm), self compiled 6.3.2 (rpm).

I've ruled out that this isn't related to ImageMagick versions, and the
dependent libraries (as reported by ldd) all report the same version
numbers (although not necessarily the same RPM versions, of course).
But not sure that comes into play.  libjpeg has been 6b for as long as I
can remember -- but nothing is happening with the JPEG image being
loaded.  The mask is generated internally and JPEG can't store a
mask/alpha channel anyway.  I am not sure if dependent libraries are the
culprit, but I don't know what else or how to check specifically.

Could this be related to trustix compile-time options, or overflow or
something like that?  How should that be tested?  If I turn off the
trustix rpmbuild options of -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1
-D_LARGEFILE64_SOURCE=1, will the result library be compatible with
everything else on the system (like perl)?

Can someone else run this test script on their machine and on other
distributions (trustix-3, perhaps; I don't have a trustix-3
installation) and see what happens?

-- 
Andy Bakun <[EMAIL PROTECTED]>

_______________________________________________
tsl-discuss mailing list
[email protected]
http://lists.trustix.org/mailman/listinfo/tsl-discuss

Reply via email to