Re: Using other applications affine transformation matrixes with Imager
From: Tony Cook (email@example.com)
Date: Mon 09 Nov 2009 - 23:29:42 GMT
On Mon, Nov 09, 2009 at 09:25:49PM +0100, Bernhard Wei?huhn wrote:
> On 07.11.2009, at 23:53, Tony Cook wrote:
> > Hi Bernhard,
> > It seems the main difference is that Imager uses the matrix to convert
> > a location in the destination image to a location in the source image,
> > while ImageMagick uses it to convert a location in the source image to
> > a location in the destination image.
> > I expect what you need is the inverse of the matrix you're using with
> > ImageMagick.
> Thanks Tony, you were spot on with this. I had to swap rx and ry, but
> otherwise everything worked as suggested, thanks.
> Ultimately, I switched back to letting Cairo perform the actual
> transformation. Cairo is so insanely fast, that it is actually
> worthwhile to read the file with Imager, swap colour channels
> according to endianness and dump the imager data as raw to a cario
> image surface, let cairo do the matrix translation, read the surface
> back as a raw file, swap colour channels back and let imager write the
> The solution lacks in terms of elegance, but the achieved performance
> is so superb, it leaves the competition (including graphics magic) in
> the dust: A moderately complex matrix conversion of the same 2M jpeg:
> ImageMagic: 20s
> Imager native: 9.5s
> GraphicsMagic: 5.4s
> Imager + Cairo: 2.4s
That's kind of scary considering how inefficient convert() is as a
simple channel swapper.
Ideally Imager's raw file handler should be able to do all the channel
> This is for moving Imager data to Cairo. A similar conversion it used
> to write back the transformed Cairo surface to Imager for converting
> it to the target filetype.
Well, one solution for the trip back would be an Imager image
interface to Cairo surfaces. It doesn't really work for the read
step since Imager's read method creates a new image.
For an unreleased example, I write an interface to SDL surfaces that
allows you to use Imager methods to draw on the surface.
> Could this be improved upon or would a more elegant handover between
> Imager-data and Cairo Image-Surfaces be a reasonable feature request
> for Imager? Since Cairo Image_Surfaces rarely exist as a written file
> format, I hesitate to implement a filetype handler for Imager.
I don't really see any other simple possiblities - you could write XS
or Inline::C code to improve the channel swap performance, but that
doesn't seem to be a huge performance hit at the moment for you.