Re: Image transformations

[Eli Zaretskii]

> Date: Tue, 25 Jun 2019 19:33:52 +0100
> From: Alan Third <address@hidden>
> Cc: address@hidden
> 
> Yes. I’m happy to drop :crop entirely. Although we might be as well
> leaving it for ImageMagick, as it provides a RAM saving by actually
> cropping the image, if people care enough about that.

Sure, I didn't mean to remove :crop from ImageMagick images.

> > In my research I found out that the equivalent Windows graphics APIs
> > need a matrix that is the inverse of what we calculate in image.c.  I
> > think that calculating a matrix and then inverting it at draw time is
> > inefficient at best and silly at worst; I'd rather calculate the
> > inverse matrix to begin with.  Calculating the inverse matrix involves
> > reversing all the primitive transformations (translations change sign,
> > rotations change the sign of the angle), and also changing the
> > multiplication order from left-multiplication of matrices to
> > right-multiplication.
> 
> Am I right in thinking we need to invert the scaling too? 1/scale?

Yes, of course.

> > Given these findings, what would you prefer to do in image.c?  We
> > could either (a) make the individual functions (image_set_rotation
> > etc.) return the transformation parameters, and leave the matrix
> > calculation to image_set_transform, or we could have the individual
> > functions accept a flag to tell them whether to generate XRender/Cairo
> > style matrices or NS/Windows style.  Or maybe you ave yet another
> > idea?
> 
> The image size calculation is already a separate function, shared with
> ImageMagick, so I feel we’re halfway towards (a) as it is. I’m happy
> to put all the matrix code into image_set_transform: once we remove
> cropping the resulting function shouldn’t be obscenely large.

OK, I will work on these changes.

>   '((:rotation imagemagick)
>     (:width png gif svg imagemagick)
>     (:height png gif svg imagemagick)
>     ...)
>     
> where png, svg, imagemagick, etc. are types (image backends) that you
> can pass to create-image.
> 
> Or it might be better to spin it round a bit:
> 
>   '((png :width :height ...)
>     (imagemagick :rotation :width ...))
>     
> Whenever I think about this I get a bit carried away and wonder if we
> could do it by image type rather than backend so that we could provide
> a function, that you pass an image type and spec to, which finds the
> first image backend that can handle it:
> 
>   (image-get-type "tiff"
>     '(:rotation 90 :max-width 20))
>   => 'imagemagick
> 
>   (image-get-type "jpeg"
>     '(:rotation 90 :max-width 20))
>   => 'jpeg
> 
> I can’t decide if that’s getting a bit silly, though.

Let me think about this and propose something.

Thanks.