[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Image transformations
From: |
Alan Third |
Subject: |
Re: Image transformations |
Date: |
Tue, 25 Jun 2019 19:33:52 +0100 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
On Mon, Jun 24, 2019 at 08:54:25PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 17 Jun 2019 22:13:32 +0100
> > From: Alan Third <address@hidden>
> > Cc: address@hidden
> >
> > > > In another part of this thread you pointed out that crop and image
> > > > slices are doing basically the same thing. I hadn’t realised that.
> > > > Given that that’s the case, I think we should just get rid of the crop
> > > > function.
> > >
> > > I agree, but please make sure the slices are indeed a 100% replacement
> > > (I cannot yet do that because I don't have a working :crop support to
> > > try it).
> >
> > As far as I can tell they are perhaps a 90% replacement, the only real
> > difference is that the interactive keybinds from image.el don’t work
> > (r for rotate, + for scale up, etc.). They can probably be made to
> > work, but to be honest I’m not sure it matters. If someone is cropping
> > an image I can’t think of any use cases where they’d want to then
> > provide the user the ability to play with that image interactively.
>
> I finished working on the Windows implementation, and have a working
> prototype. The tests you wrote all work, with the single exception of
> cropping (not surprisingly, since I didn't really figure out how is
> this supposed to work). I guess the above means I don't have to dig
> into this, as we are losing :crop in the native transforms, is that
> right?
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.
> So now I'm ready to discuss the restructuring of the transform
> matrices code.
>
> 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?
> 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.
> Finally, there's the issue of what to return from image-transforms-p.
Perhaps we return something like:
'((: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.
--
Alan Third
- Re: Image transformations, (continued)
- Re: Image transformations, Stefan Monnier, 2019/06/24
- 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 <=
- Re: Image transformations, Eli Zaretskii, 2019/06/25
- 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