Tony Cook [Mon, 5 May 2008 05:02:26 +0000 (05:02 +0000)]
- the gif_screen_height tag was overriding the screen width and being
ignored for the screen height when present.
https://rt.cpan.org/Public/Bug/Display.html?id=35568
Tony Cook [Wed, 30 Apr 2008 10:54:57 +0000 (10:54 +0000)]
- In some cases when an error occurs reading those parts of a JPEG
file after the image the scan-line buffer could be freed a second
time. In cases where the the error occured while reading the image
data it's possible that the buffer could have leaked.
Thanks to Gabriel Vasseur for reporting this and help in tracking
it down.
Tony Cook [Wed, 23 Apr 2008 01:00:02 +0000 (01:00 +0000)]
- fixed a related problem for image fills.
- Possible security issue: The floating point sample path for image
based fills had a buffer overflow. This would overwrite the end of
a malloc()ed buffer with double precision floats.
Tony Cook [Tue, 22 Apr 2008 04:10:06 +0000 (04:10 +0000)]
- Regression: filling a greyscale image with a hatch used the wrong
color channels from the supplied fg/bg colors.
https://rt.cpan.org/Ticket/Display.html?id=35278
Tony Cook [Fri, 18 Apr 2008 04:36:55 +0000 (04:36 +0000)]
- check that the result of fileno($fh) is defined rather than simply
true when read() or write() is supplied with an fh parameter.
http://rt.cpan.org/Ticket/Display.html?id=35139
- i_scale_axis() wasn't checking the result of i_img_new_ch()
resulting in a SIGSEGV when attempting to scale an image to a size
too large to fit in memory. This is a NULL pointer access issue,
not a buffer overflow.
Added a check for the failure.
scale_calculate() (and hence scale()) will now fail if any of the
scale size parameters are a reference.
http://rt.cpan.org/Ticket/Display.html?id=35172
Tony Cook [Tue, 1 Apr 2008 10:23:47 +0000 (10:23 +0000)]
- removed the pointless #! line from lib/Imager/Font/Wrap.pm
Noticed when I saw:
https://bugzilla.redhat.com/show_bug.cgi?id=166254
I'm not changing the #! lines of the sample code, since it's sample
code, not intended for installation.
http://rt.cpan.org/Ticket/Display.html?id=33408
Tony Cook [Tue, 1 Apr 2008 10:12:17 +0000 (10:12 +0000)]
- mixing qtype scaling now sets all channels of a pixel to zero if
the pixel has zero coverage (zero alpha). This should produce more
compressible output files.
http://rt.cpan.org/Ticket/Display.html?id=32324
Tony Cook [Tue, 1 Apr 2008 09:48:59 +0000 (09:48 +0000)]
- writing a 2 or 4 channel image to a BMP file will now write that
image as if composited against a background, black by default,
overridable with the i_background tag/parameter.
http://rt.cpan.org/Ticket/Display.html?id=30075
Tony Cook [Tue, 1 Apr 2008 08:15:22 +0000 (08:15 +0000)]
- writing a 2 or 4 channel image to a PGM/PPM will now write that
image as if composited against a background, black by default,
overridable with the i_background tag/parameter.
http://rt.cpan.org/Ticket/Display.html?id=30074
Tony Cook [Tue, 1 Apr 2008 06:47:28 +0000 (06:47 +0000)]
- writing a 2 or 4 channel image to a JPEG will now write that image as
if composited against a background, black by default, overridable
with the i_background tag/parameter.
https://rt.cpan.org/Ticket/Display.html?id=29876
Tony Cook [Tue, 25 Mar 2008 11:29:06 +0000 (11:29 +0000)]
- some TGA images weren't being detected correctly as TGA images
https://rt.cpan.org/Ticket/Display.html?id=32925
- handling of the left-over bit for 16-bit/pixel TGA images has been
changed to match the behaviour of the GIMP. Previously the bit
being set was treated as an opaque pixel, but one user reported a
problem with loading such an image. I haven't been able to find any
tools beyond the GIMP that handle alpha-channel 16-bit TGAs, so
I'll match it's behaviour. See issue 114913 in the GIMP's
bugzilla.
http://rt.cpan.org/Ticket/Display.html?id=32926
Tony Cook [Mon, 29 Oct 2007 11:11:10 +0000 (11:11 +0000)]
- the SGI RLE compression code could overflow its compression buffer
http://rt.cpan.org/Ticket/Display.html?id=30334
- the 32-bit output function used by the SGI code only handled values
under 0x10000. This was most noticable when writing large RLE images.
http://rt.cpan.org/Ticket/Display.html?id=30335
Tony Cook [Mon, 29 Oct 2007 09:37:22 +0000 (09:37 +0000)]
the code for the transform2() uminus operator was missing a break.
Added tests for better code coverage of the ops.
http://rt.cpan.org/Ticket/Display.html?id=29296
Tony Cook [Fri, 12 Oct 2007 06:38:55 +0000 (06:38 +0000)]
- correct handling of sz in matrix_transform() - this should allow
perspective type transformations to work now.
http://rt.cpan.org/Ticket/Display.html?id=29936