From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alp Aker Newsgroups: gmane.emacs.devel Subject: Re: Image transformations Date: Thu, 13 Jun 2019 05:19:52 -0400 Message-ID: References: <9A21DE14-BB5F-426E-BBB2-19C87930E733@gnu.org> <20190611200233.GA80199@breton.holly.idiocy.org> <83imta95z0.fsf@gnu.org> <20190612220746.GA89208@breton.holly.idiocy.org> <835zpa11qp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000003e68d058b3109d5" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="131818"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Alan Third , Emacs devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 13 11:20:24 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hbLu9-000Y9b-VF for ged-emacs-devel@m.gmane.org; Thu, 13 Jun 2019 11:20:22 +0200 Original-Received: from localhost ([::1]:37954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbLu9-0004cL-09 for ged-emacs-devel@m.gmane.org; Thu, 13 Jun 2019 05:20:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47438) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbLtx-0004cF-G7 for emacs-devel@gnu.org; Thu, 13 Jun 2019 05:20:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbLtv-0003Cg-Js for emacs-devel@gnu.org; Thu, 13 Jun 2019 05:20:09 -0400 Original-Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]:38939) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hbLtt-0003BA-Bw; Thu, 13 Jun 2019 05:20:05 -0400 Original-Received: by mail-vs1-xe33.google.com with SMTP id n2so12178370vso.6; Thu, 13 Jun 2019 02:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l42sjK38tTZV8zvzyxNC0MxOS6h+G2vqMsgfqHkZe7U=; b=MBKs94v+hzfwYOj5oFgQqvOm7LpGedOmD54iS1+H5GKIsAzJeVShhPyuNXMLyJIe4+ LTAD5EnixzDOv6eQIJnX6ypnaFvDgjJ0xhbum6iDdbjQuXXvqRcDpfR8l4dAATPWm+lD N8pC/qNqfU6x8+KWy1GFuc0lXQ1YtHNs91FvYBRHN4Uiq3fInORnv3ZCmWwzSsgfsyCw yeYCflvCzjK09T6dyLW/MOKJmG71zf6V8f4Mpn7xJXd6cyp6jG6AAKL+8RchHhEZ73+Q 2h61D+vfsfIBfGzxKsj+pElh2oVZwFaE1zZ2Qs3P9lMXcxX6zjiOTuHMGfDD1xmuavev Yd6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l42sjK38tTZV8zvzyxNC0MxOS6h+G2vqMsgfqHkZe7U=; b=BCtBLetCJh4L0Vfi2GYP8I+1SYQYgMaYAgZO1uBjHS/oS4XHh14uQjb7V9pOQvxZpD DEL5b480EuYYHmBWPJz7qlFrBPQ8wJlnOh0BQKSVxT2iU7BflSrxfoFKSEZY5khFNC54 +XMCbVzDWG8LiSXLvwkY+qZFfc0lG4+BGoeKvwdpS9QFjtyR2VCNyna17JFngdcr0z6L xXpC0IqsUsT9SiWAb2H4b6ozdKjOSYkCNBwT0bHdY9UYSBol6n8tTJ63ZISBYpOIXuyo KFsh9ZrkCRbOtJrlGnHL210wErJJfkCHQ/Ie7WXcNmJTDn85U5TXFq2pyfS6n35M74Ar oD/Q== X-Gm-Message-State: APjAAAXXHUYa9r+MiH8cYjp8anv56IwtwsrkR8upN/jcxuN9bqNSPsew lEoNYoOhm2FnEwPeGf/Wz1Cw+5gXybzzUdIRnzxITyMd X-Google-Smtp-Source: APXvYqyJAed3hB9e2Ftia7wyYU1O3H1haRPUYnh3p+Ff+Gnum+Nl/mosMWZ2Ludi5PFl32zSNi8wp55DhdAI1owdX4M= X-Received: by 2002:a67:320c:: with SMTP id y12mr3261543vsy.30.1560417604460; Thu, 13 Jun 2019 02:20:04 -0700 (PDT) In-Reply-To: <835zpa11qp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::e33 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237491 --00000000000003e68d058b3109d5 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 13, 2019 at 1:41 AM Eli Zaretskii wrote: > > This already goes contrary to my geometric intuition, please bear with > me. The rotation is around the (0,0) origin, i.e. around the top-left > corner of the original image, right? If so, the rotation should have > been followed by a translation along the X axis, not Y The last sentence is problematic. When a transformation matrix describes a rotation followed by a translation, the translation is specified relative to the fixed coordinate axes. The rotation doesn't affect the direction of the translation. It's perhaps unintuitive, but that's the way the formalism is defined. We could interpret "rotate 90 then translate" in the way you describe, but then the translation into algebra would be different. > rotating a 333-pixel wide, 233-pixel high image 90 deg clockwise > produces a 233-pixel wide, 333-pixel high image that is entirely to > the LEFT of the Y axis. Here's ASCII-art representation of that: > > +------------------+> X +----------+-------------------> X > | | | | > | | | | > | | | | > | | ===> | | > +------------------+ | | > | | | > | | | > | | | > | +----------+ > | | > V V > Y Y > > The above is just after the rotation around (0,0). Is that correct, > or am I missing something? That's correct. > I also tried to approach this from the matrix notation aspect. Is the > following the correct equations of computing (x',y'), the new > coordinates of any pixel of the image, from its original coordinates > (x,y)? > > x' = m11 * x + m12 * y + tx > y' = m21 * x + m22 * y + ty > > where the factors are related to the matrix as follows: > > m[0][0] = m11 | m[0][1] = m12 | m[0][2] = 0 > --------------+---------------+------------- > m[1][0] = m21 | m[1][1] = m22 | m[1][2] = 0 > --------------+---------------+------------- > m[2][0] = tx | m[2][1] = ty | m[2][2] = 1 I confess I'm not sure how to interpret that matrix. I just looked through image_set_rotation and found it somewhat confusing, as it seems to use column-major representation where I'd expect row-major. E.g., the above matrix looks odd to me, because tx and ty would normally be in m[0][2] and m[1][2] (and I'd expect m[2][0] == m[2][1] == 0). Similarly, the rotation matrix used in image_set_rotation: [0][0] = cos_r, [0][1] = -sin_r [1][0] = sin_r, [1][1] = cos_r would normally describe a counter-clockwise rotation by r, not a clockwise rotation. That said, if I correctly understand the layout of the data, the equations should be: x' = m11 * x + m21 * y + tx y' = m12 * x + m22 * y + ty > If the above is correct, then the transformation of the top-left > corner of the original image, whose original coordinates are (0,0), > [...] > the correct coordinates should be (233,0), not (0,232). > What am I missing here? The transformation described by the matrix is: rotate 90 degrees around the origin, then translate by 232 along the y axis. The first operation leaves (0, 0) unmoved, then the second operation moves it to (0, 232). > Sorry, now I'm even more confused: aren't we dealing with affine > transformations? Then how are homogeneous coordinates related to > this? And does that mean the formulae for calculating (x',y') I show > above are incorrect? I was being unnecessarily general, which caused confusion; my apologies. Probably best for present purposes to ignore what I said there. (What I meant: Transformation matrices can be used for both affine and non-affine transformations. I first described the general case, then described how the calculations work when we restrict to affine transformations. It's homogeneous coordinates in both cases, though. I also wrote this last part before noticing the transposition issue I mentioned above, which probably adds to the confusion.) --00000000000003e68d058b3109d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2019 at 1:41 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Th= is already goes contrary to my geometric intuition, please bear with
>= ; me.=C2=A0 The rotation is around the (0,0) origin, i.e. around the top-le= ft
> corner of the original image, right?=C2=A0 If so, the rotation s= hould have
> been followed by a translation along the X axis, not Y
The last sentence is problematic.=C2=A0 When a transformation matrix = describes a
rotation followed by a translation, the translation is speci= fied relative to the
fixed coordinate axes.=C2=A0 The rotation doesn'= ;t affect the direction of the
translation.=C2=A0 It's perhaps unint= uitive, but that's the way the formalism is
defined.=C2=A0 We could = interpret "rotate 90 then translate" in the way you describe,
= but then the translation into algebra would be different.

> rotat= ing a 333-pixel wide, 233-pixel high image 90 deg clockwise
> produce= s a 233-pixel wide, 333-pixel high image that is entirely to
> the LE= FT of the Y axis.=C2=A0 Here's ASCII-art representation of that:
>= ;
> =C2=A0 =C2=A0 +------------------+> X =C2=A0 =C2=A0 =C2=A0 =C2= =A0+----------+-------------------> X
> =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br>> =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =3D=3D=3D> =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
> =C2=A0 =C2=A0 +------------------+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 = | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>= ; =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
> =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+----------+
> =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 V =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
> =C2=A0 = =C2=A0 Y =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=
>
> The above is just after the rotation around (0,0).=C2=A0 I= s that correct,
> or am I missing something?

That's correc= t.

> I also tried to approach this from the matrix notation aspec= t.=C2=A0 Is the
> following the correct equations of computing (x'= ;,y'), the new
> coordinates of any pixel of the image, from its = original coordinates
> (x,y)?
>
> =C2=A0 x' =3D m11 *= x + m12 * y + tx
> =C2=A0 y' =3D m21 * x + m22 * y + ty
><= br>> where the factors are related to the matrix as follows:
>
= > =C2=A0 =C2=A0m[0][0] =3D m11 | m[0][1] =3D m12 | m[0][2] =3D 0
>= =C2=A0 =C2=A0--------------+---------------+-------------
> =C2=A0 = =C2=A0m[1][0] =3D m21 | m[1][1] =3D m22 | m[1][2] =3D 0
> =C2=A0 =C2= =A0--------------+---------------+-------------
> =C2=A0 =C2=A0m[2][0= ] =3D tx =C2=A0| m[2][1] =3D ty =C2=A0| m[2][2] =3D 1

I confess I= 9;m not sure how to interpret that matrix.=C2=A0 I just looked through
i= mage_set_rotation and found it somewhat confusing, as it seems to use
co= lumn-major representation where I'd expect row-major.=C2=A0 E.g., the a= bove matrix
looks odd to me, because tx and ty would normally be in m[0]= [2] and m[1][2] (and
I'd expect m[2][0] =3D=3D m[2][1] =3D=3D 0).=C2= =A0 Similarly, the rotation matrix used in
image_set_rotation:

= =C2=A0 [0][0] =3D cos_r, [0][1] =3D -sin_r
=C2=A0 [1][0] =3D sin_r, [1][= 1] =3D cos_r

would normally describe a counter-clockwise rotation by= r, not a clockwise
rotation.

That said, if I correctly understan= d the layout of the data, the equations
should be:

=C2=A0 =C2=A0x= ' =3D m11 * x + m21 * y + tx
=C2=A0 =C2=A0y' =3D m12 * x + m22 *= y + ty

> If the above is correct, then the transformation of the= top-left
> corner of the original image, whose original coordinates = are (0,0),
> [...]
> the correct coordinates should be (233,0),= not (0,232).
> What am I missing here?

The transformation des= cribed by the matrix is: rotate 90 degrees around the
origin, then trans= late by 232 along the y axis.=C2=A0 The first operation leaves (0,
0) un= moved, then the second operation moves it to (0, 232).

> Sorry, n= ow I'm even more confused: aren't we dealing with affine
> tr= ansformations?=C2=A0 Then how are homogeneous coordinates related to
>= ; this?=C2=A0 And does that mean the formulae for calculating (x',y'= ;) I show
> above are incorrect?

I was being unnecessarily gen= eral, which caused confusion; my
apologies.=C2=A0 Probably best for pres= ent purposes to ignore what I said
there. =C2=A0(What I meant: Transform= ation matrices can be used for both affine and
non-affine transformation= s.=C2=A0 I first described the general case, then described
how the calc= ulations work when we restrict to affine transformations.=C2=A0 It'shomogeneous coordinates in both cases, though.=C2=A0 I also wrote this las= t part
before noticing the transposition issue I mentioned above, which = probably adds
to the confusion.)

--00000000000003e68d058b3109d5--