Re: Image transformations

[Alan Third]

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