use Perl

I'm considering splitting out Imager's file support for those file types that require external libraries, in particular:

• GIF
• TIFF
• JPEG
• PNG

Possibly also the font file handlers:

• Freetype 1.x
• Freetype 2.x
• T1Lib
• Win32

Unlike the current Imager package these would fail to install unless the appropriate library could be found (or built), so your code could depend on Imager::File::GIF and be sure that GIF support was available, which isn't currently the case.

I'd produce file format distributions such as Imager-File-GIF at least six months before removing them from Imager itself. Installing such distributions would add (for example) GIF support to Imager if it wasn't already present, or be ignored if it was.

I'd also release Task::Imager which would depend on Imager and each of the file format support distributions needed to match the Imager

This allows:

• just depend on Imager::Task to get the same file formats you get now (possibly some more)
• depend on Imager::File::Foo to get the format you want and be sure they're present

Reactions?

(I suspect this is going to be more painful for packagers than anyone else.)

Imager's tiff support has been greatly extended to:

• add support for large sample sizes, Imager can now read and write 16 and 32-bit/sample RGB and greyscale images and manipulate them.
• read and write bi-level images
• allow selection of the compression used for the image.
• work around some bugs in various versions of libtiff's RGBA image support, in particular alpha channel handling for grey and cmyk images.

This is a large change, so I've released Imager 0.61_02 as a test release. If you use Imager with TIFF much, please give it a go.

I'm planning on a 0.62 release in a week or so.

Imager 0.57 is a security fix release.

After following up on a buqtraq message describing BMP issues in some viewers I decided to test Imager against the test images.

Unfortunately Imager failed on some of the test images.

Imager 0.57 corrects this.

A new Imager development release 0.51_02 is now on CPAN.

This adds Windows Icon/Cursor file support, an interface for adding new file types, a new variant of flood_fill that fills to a given border color and the usual collection of other tweaks.

Please give it a go if you have a chance.

Something fairly similar to it will be released as 0.52 unless I see some problems reported.

Imager has been released, it fixes a few bugs.

For now work is keeping me busy, so the next feature release (file hooks, ICO support, Changes changed) is delayed for now.

I uploaded Imager 0.47_01 to CPAN last week as a pre-release to 0.48.

Imager 0.48 adds the API I mentioned last month, some other minor features and fixes.

If you get a chance to test it please let me know of any problems. If you're using the CPAN shell you can use:

test T/TO/TONYC/Imager-0.47_01.tar.gz

Over Christmas I made most of Imager's API, such as it is, available to external modules.

This has 2 purposes:

• you can write XS modules that access Imager at the C level for speed. eg. the mandel dynfilt module that has been supplied with Imager for years, is now a perl/XS module installed as part of Imager.
• you can write C level image or fill objects for Imager. eg. I have Imager::SDL in SVN at the moment, which renders whatever you draw to a SDL surface.

I added a hook for Inline::C as well, which makes the API very easy to use, assuming C doesn't scare you too much.

Of course, none of this is released yet, but what's there hangs together.

Currently some of the API isn't exposed - file access, because it's not an image manipulation function, and fonts, because the C level font API is fairly chaotic.

Imager's release cycle has tended to be pretty long, but hopefully I'll get this out in the next few weeks.

Right now I'm going through the file handlers and checking they report errors correctly - in some cases the C level handlers do, but the perl level code is discarding the error <sigh>

I've uploaded a release candidate for Imager 0.46 to CPAN.

If you use Imager, please take the time to test it out, using CPAN shell this would be:

perl -MCPAN -eshell

test T/TO/TONYC/Imager-0.45_02.tar.gz

The major changes in Imager 0.46 include:

• EXIF support when reading JPEG images
• you can read a given page of GIF or TIFF files
• the read method now reads the first image of a GIF instead of consolidating them (the old behaviour is still available if needed)
• you can limit the sizes of images read from files
• significant documentation changes
• many minor bug fixes

A release candidate for Imager 0.45 is now on CPAN, though it may take a little while to get to some mirrors.

If you have time please try to run the test suite, the simplest way to do that is with the CPAN shell, if you've configured it:

perl -MCPAN -eshell
test T/TO/TONYC/Imager-0.44_01.tar.gz

If you see test failures on OS X 10.4 in t/t20fill.t, please send me a copy of the generated fills.o and the result of:

gcc --version

then try running:

gcc_select 3

and attempting to build/test Imager again. You can do:

gcc_select 4

to return to the default gcc 4.0 pre-release.

At this point I'm ready to put out a test release of Imager 0.45, but... 0.44 is failing tests under OS X 10.4.

For a short time I had access to a 10.4 machine, and found that the pre-release of GCC 4.0 that Apple shipped with Tiger was generating incorrect code. When I build the released GCC 4.0 under OS X 10.3.9, and use that to build Imager, all tests pass.

To see the code in question, build Imager and run:

otool -vt fills.o | less +/^_fill_hatch # on OS X

At this point I'm wondering how to handle this. :

• ship and be damned, take test failures from 10.4 testers, take test failures from people trying to install it, and live with it
• attempt to workaround the two sections of code that I know have incorrect code generated, and hope no other code has the same problem.
• probe the compiler GCC version and don't allow building by default if it's the GCC that shipped with OS X 10.4 (the perl -V output indicates GCC 3.3, but 10.4 builds with a GCC 4.0 pre-release by default.)

At the moment I'm inclined to go with the first option, but all the solutions have their problems.