Re: Image transformations

[Alan Third]

On Sat, Jun 15, 2019 at 02:31:41PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 15 Jun 2019 11:42:42 +0100
> > From: Alan Third <address@hidden>
> > Cc: address@hidden
> > 
> > > The matrix is defined according to XRender, AFAIU.  NS and Cairo need
> > > to transpose/invert/etc. the matrix to use it, and so will the
> > > MS-Windows code, IIUC.  The matrix fuses the actual primitive
> > > transformations into a construct which we currently don't seem to
> > > understand well, whose only "documentation" is in a tutorial that is
> > > not part of XRender's official docs.
> > 
> > I was first taught affine transformation matrices in a Mathematics for
> > Engineers course at university.
> 
> We are mis-communicating.  I know what affine transformations are, and
> I have no problems with matrix multiplication and vector algebra in
> general.  I majored in physics, so even tensors of General Relativity
> aren't a problem for me.

I know nothing of your background other than what I’ve read on here,
so I apologise for being patronising. I’ve clearly misunderstood what
you were asking for repeatedly.

> The issue I'm worried about is the geometrical meaning of each element
> of the matrix, as applied to image transformations in Emacs: whether
> it needs to be transposed before multiplying vectors by it, whether
> vectors should be left-multiplied or right-multiplied, whether the Y
> axis is assumed to go up or down, whether the [1][2] member is the
> sine of the rotation angle or its negative, etc.
> 
> Even Richard and Alp were confused for a moment about this stuff.
> Which is a clear sign that these aspects are not as trivial as it
> might sound.  IMO, we need clear documentation of that, to allow
> people make changes in the code without making mistakes.  But maybe
> I'm the only one to be bothered by that.

I think as long as we’re consistent with our own representation then
we can treat the question of whether the toolkits have transposed the
matrix terms as implementation details. The code IS consistent,
unfortunately my first attempt at documenting it WASN’T, which is
entirely on me. That caused at least some of the confusion.

The attached patch has more, hopefully better, documentation.

> > BTW, are you really keen to get rid of the matrix multiplications?
> > Anything we replace them with for XRender will simply be matrix
> > multiplications written out in long form, keeping track of each
> > element separately.
> 
> This is again a misunderstanding: I was merely suggesting to make all
> of those multiplications in image_set_transform, that's all.

OK. Do you want me to go ahead and do that? I don’t want to start
making big changes if you’re working on the Windows side. I have a
suggestion that will simplify this job though.

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.

Getting rid of it will also get rid of that difficult to understand
resize ‐> crop ‐> rotate process where crop parameters have to take
the effects of the resize into account.

> Maybe I should stop talking about this and just go ahead and write the
> best code I can.  Because instead of improving things, this discussion
> seems to just proliferate misunderstandings and bad feelings.  Most
> probably, my fault, sorry.

No bad feelings on my part, just confusion, which was largely my own
fault anyway. I hope we can finish this off without any more
misunderstandings.
-- 
Alan Third

0001-Document-image-transforms.patch
Description: Text document