[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Image transformations
From: |
Eli Zaretskii |
Subject: |
Re: Image transformations |
Date: |
Tue, 25 Jun 2019 21:57:56 +0300 |
> 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.
- Re: Image transformations, (continued)
- Re: Image transformations, Eli Zaretskii, 2019/06/24
- Re: Image transformations, Stefan Monnier, 2019/06/24
- Re: Image transformations, Eli Zaretskii, 2019/06/25
- Re: Image transformations, Stefan Monnier, 2019/06/25
- Re: Image transformations, Eli Zaretskii, 2019/06/25
- Re: Image transformations, YAMAMOTO Mitsuharu, 2019/06/25
- Re: Image transformations, Eli Zaretskii, 2019/06/26
- Re: Image transformations, YAMAMOTO Mitsuharu, 2019/06/26
- Re: Image transformations, Eli Zaretskii, 2019/06/27
- Re: Image transformations, Alan Third, 2019/06/25
- Re: Image transformations,
Eli Zaretskii <=
- Re: Image transformations, Eli Zaretskii, 2019/06/27
- Re: Image transformations, Alan Third, 2019/06/28
- Re: Image transformations, Eli Zaretskii, 2019/06/28
- Re: Image transformations, Eli Zaretskii, 2019/06/29
- Re: Image transformations, Alan Third, 2019/06/29
- Re: Image transformations, Alan Third, 2019/06/29
- Re: Image transformations, Lars Ingebrigtsen, 2019/06/29
- Re: Image transformations, Alan Third, 2019/06/30
- Re: Image transformations, Lars Ingebrigtsen, 2019/06/30
- Re: Image transformations, Stefan Monnier, 2019/06/29