From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Image transformations Date: Thu, 13 Jun 2019 08:48:48 +0300 Message-ID: <834l4u11dr.fsf@gnu.org> References: <9A21DE14-BB5F-426E-BBB2-19C87930E733@gnu.org> <20190611200233.GA80199@breton.holly.idiocy.org> <83imta95z0.fsf@gnu.org> <20190612220746.GA89208@breton.holly.idiocy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218830"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 13 07:49:55 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 1hbIcU-000uoW-Js for ged-emacs-devel@m.gmane.org; Thu, 13 Jun 2019 07:49:54 +0200 Original-Received: from localhost ([::1]:37082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbIcT-00039f-MF for ged-emacs-devel@m.gmane.org; Thu, 13 Jun 2019 01:49:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56666) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbIbS-000371-Jx for emacs-devel@gnu.org; Thu, 13 Jun 2019 01:48:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hbIbS-0003SG-0z; Thu, 13 Jun 2019 01:48:50 -0400 Original-Received: from [176.228.60.248] (port=4376 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hbIbQ-0006ve-Mt; Thu, 13 Jun 2019 01:48:49 -0400 In-reply-to: <20190612220746.GA89208@breton.holly.idiocy.org> (message from Alan Third on Wed, 12 Jun 2019 23:07:46 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:237485 Archived-At: > Date: Wed, 12 Jun 2019 23:07:46 +0100 > From: Alan Third > Cc: emacs-devel@gnu.org > > > > +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.