Re: Image transformations

[Eli Zaretskii]

> Date: Wed, 12 Jun 2019 23:07:46 +0100
> From: Alan Third <address@hidden>
> Cc: address@hidden
> 
> > > +Cropping is performed after scaling but before rotation.
> > 
> > This sounds strange to me; are you sure?  I'd expect cropping to be
> > done either before everything else or after everything else.  Is this
> > so because that's how XRender does it?  At the very least, it begs the
> > question whether the parameters of :crop are measured in units before
> > or after scaling.
> 
> I agree, but this is how our imagemagick code does it and I didn’t
> want to make my code behave differently, even though I think it makes
> no sense.

OK, but what about the question regarding the units of :crop
parameters -- should they be interpreted as before or after the
scaling?

> > Can you please add the equations used to perform this affine
> > transformation, i.e. how x' and y' are computed from x and y?  I think
> > it will go a long way towards clarifying the processing.
> 
> I’ll add some further explanations of how to use the affine
> transformation matrices, but I don’t know that I’ll be able to do a
> very good job of explaining exactly how they work. I would suggest
> that if someone is interested they look it up elsewhere, however I
> also don’t think it’s necessary to fully understand the maths to be
> able to use them.

I have shown my interpretation of the equations.  Trouble is, I cannot
find what XRender does anywhere.  Does someone know where to look for
that?

> I’ll provide an updated patch soon.

Thanks.

> >   (insert-image (create-image "splash.svg" 'svg nil :rotation 90))
> > 
> > I stepped through the code trying to figure out how to map these
> > features to the equivalent Windows APIs, and I saw some results that
> > confused me.  After you show me the values you get in this use case, I
> > might have a few follow-up questions about the code, to clarify my
> > understanding of what the code does and what we expect from the
> > backend when we hand it the matrix computed here.
> 
> Using this code at the top of image_set_transform:
> 
>   fprintf(stderr, "matrix:\n");
>   fprintf(stderr, "%f %f %f\n",matrix[0][0], matrix[1][0], matrix[2][0]);
>   fprintf(stderr, "%f %f %f\n",matrix[0][1], matrix[1][1], matrix[2][1]);
>   fprintf(stderr, "%f %f %f\n",matrix[0][2], matrix[1][2], matrix[2][2]);
> 
> I get this printed (on macOS, but it should be the same everywhere):
> 
> matrix:
> 0.000000 1.000000 0.000000
> -1.000000 0.000000 232.000000
> 0.000000 0.000000 1.000000

That's what I get, except that you've printed the matrix in
column-major order.  I described my conceptual problems with these
values in another message.

> Luckily we don’t have to worry about the last step as the graphics
> toolkit will do it for us.

Unfortunately, I do have to worry about all of the steps, because I
need to figure out how to map all this to the equivalent Windows APIs.
Thus my questions, for which I apologize.  I'd prefer that someone
more knowledgeable about graphics programming did the changes on
Windows, but no one stepped forward yet.

> (perhaps I should just put the above into the comment in image.c)

Yes, please.

Thanks.