Testing native image scaling

Testing native image scaling

[Eli Zaretskii]

Alan, could you please tell how you tested native image scaling with
the XRENDER extension, and perhaps show some Lisp or existing commands
you used for that?  E.g., did the features in thumbs.el work for you
in a build without Imagemagick?

I tried to implement this for MS-Windows, but I guess my understanding
of the internal workings of this is incomplete/incorrect, or my code
is buggy (or both), because I don't seem to be able to cause Emacs to
exercise the code when the original image's size and the size
requested by scaling differ.  For example, I thought that when scaling
is requested, x_set_image_size should be called and compute image
dimensions different from the original img->height and img->width, but
I seem to be unable to see this.  What am I missing?  Could you
perhaps describe the flow of calls when, e.g., the user types '+' on
an image in image-mode, and Emacs scales the image at point?

Thanks.

P.S. Incidentally, image-scaling-p is called in image.el also in
context where we want to know whether an image can be rotated by 90
degrees, and native scaling doesn't support that, does it?

Re: Testing native image scaling

[Alan Third]

On Sat, Jan 19, 2019 at 11:31:34AM +0200, Eli Zaretskii wrote:
> Alan, could you please tell how you tested native image scaling with
> the XRENDER extension, and perhaps show some Lisp or existing commands
> you used for that?  E.g., did the features in thumbs.el work for you
> in a build without Imagemagick?

I just used a fairly simple series of commands like this:

(setq i (create-image "~/image.png" nil nil :scale 0.5))
(insert-image i)
(setq ii (create-image "~/image.png" nil nil :scale 0.5))
(insert "\n")
(insert-image ii)
(insert "\n")
(insert "x")
(insert-image i)
(insert "x")
(insert "\n")

(setq i (create-image "~/image.png" nil nil :scale 0.25
		      :margin 10 :relief 10))
(insert-image i)

(insert "x")
(insert "\n")

(setq i (create-image "~/image.png" nil nil :width 25))
(insert-image i)

I was testing with animated gifs at one stage, which is why I was
using setq. I also found various files using C-x C-f.

It look like thumbs.el uses ImageMagick’s convert program directly, so
it won’t be affected by native scaling.

> I tried to implement this for MS-Windows, but I guess my understanding
> of the internal workings of this is incomplete/incorrect, or my code
> is buggy (or both), because I don't seem to be able to cause Emacs to
> exercise the code when the original image's size and the size
> requested by scaling differ.  For example, I thought that when scaling
> is requested, x_set_image_size should be called and compute image
> dimensions different from the original img->height and img->width, but
> I seem to be unable to see this.  What am I missing?  Could you
> perhaps describe the flow of calls when, e.g., the user types '+' on
> an image in image-mode, and Emacs scales the image at point?

I think you understand this right.

x_set_image_size calculates the new sizes, does the conversion, and
writes those new sizes back into struct image, over‐writing the
original sizes.

For NS it also asks the NSImage back‐end to scale the image using
ns_image_set_size, which in effect does the actual scaling.

For XRender it sets up an affine transformation matrix, and applies it
to img->picture, which also in effect does the actual scaling.

The compositing functions in nsterm.m and xterm.c don’t need to know
the original image size, just the new size, and NSImage/XRender
handles the rest.

There are only two potential problems I can see:

1. If you’re building with ImageMagick, then when you hit + in
image-mode it automatically reverts to ImageMagick as a back end. In
that case x_set_image_size won’t do anything since ImageMagick will
have already resized the image. If you insert images directly into a
buffer like I did in the script above then ImageMagick will never be
used unless you explicitly request it.

2. If you missed the fact that img->width/height are set within
#ifdef/#endif blocks. That is due to the requirement of checking
img->picture for XRender, although there are plenty of other ways to
handle it.

> P.S. Incidentally, image-scaling-p is called in image.el also in
> context where we want to know whether an image can be rotated by 90
> degrees, and native scaling doesn't support that, does it?

That’s correct. I should have created new separate functions for
testing rotation and scaling.

We could use XRender to rotate images if we really wanted to, and the
NS port already supports it.

-- 
Alan Third

Re: Testing native image scaling

[Eli Zaretskii]

> Date: Sat, 19 Jan 2019 21:45:43 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: emacs-devel@gnu.org
> 
> On Sat, Jan 19, 2019 at 11:31:34AM +0200, Eli Zaretskii wrote:
> > Alan, could you please tell how you tested native image scaling with
> > the XRENDER extension, and perhaps show some Lisp or existing commands
> > you used for that?  E.g., did the features in thumbs.el work for you
> > in a build without Imagemagick?
> 
> I just used a fairly simple series of commands like this:
> 
> (setq i (create-image "~/image.png" nil nil :scale 0.5))
> (insert-image i)
> (setq ii (create-image "~/image.png" nil nil :scale 0.5))
> (insert "\n")
> (insert-image ii)

Thanks, this was very helpful.  (Actually, just create-image with one
argument is enough: after inserting it, '+' or '-' on the image will
interactively resize it.)

> It look like thumbs.el uses ImageMagick’s convert program directly, so
> it won’t be affected by native scaling.

Ah, okay, I missed that.  image-dired seems to do the same.  I guess
we should at some point update those (and others) to use the native
resizing.

> > I tried to implement this for MS-Windows, but I guess my understanding
> > of the internal workings of this is incomplete/incorrect, or my code
> > is buggy (or both), because I don't seem to be able to cause Emacs to
> > exercise the code when the original image's size and the size
> > requested by scaling differ.  For example, I thought that when scaling
> > is requested, x_set_image_size should be called and compute image
> > dimensions different from the original img->height and img->width, but
> > I seem to be unable to see this.  What am I missing?  Could you
> > perhaps describe the flow of calls when, e.g., the user types '+' on
> > an image in image-mode, and Emacs scales the image at point?
> 
> I think you understand this right.
> 
> x_set_image_size calculates the new sizes, does the conversion, and
> writes those new sizes back into struct image, over‐writing the
> original sizes.
> 
> For NS it also asks the NSImage back‐end to scale the image using
> ns_image_set_size, which in effect does the actual scaling.
> 
> For XRender it sets up an affine transformation matrix, and applies it
> to img->picture, which also in effect does the actual scaling.
> 
> The compositing functions in nsterm.m and xterm.c don’t need to know
> the original image size, just the new size, and NSImage/XRender
> handles the rest.

Well, on w32, the implementation actually resizes when it draws.
Maybe that's sub-optimal, but I know next to nothing about w32 image
display, so what I got looks definitely fine for my ignorance.

So we now have native resizing on all major platforms.

> We could use XRender to rotate images if we really wanted to, and the
> NS port already supports it.

Where's the NS support for that?  AFAICT, :rotate is only handled in
ImageMagick specific portions of the code, what did I miss?

Thanks.

Re: Testing native image scaling

[Alan Third]

On Sun, Jan 20, 2019 at 06:05:18PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Jan 2019 21:45:43 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> > 
> > x_set_image_size calculates the new sizes, does the conversion, and
> > writes those new sizes back into struct image, over‐writing the
> > original sizes.
> > 
> > For NS it also asks the NSImage back‐end to scale the image using
> > ns_image_set_size, which in effect does the actual scaling.
> > 
> > For XRender it sets up an affine transformation matrix, and applies it
> > to img->picture, which also in effect does the actual scaling.
> > 
> > The compositing functions in nsterm.m and xterm.c don’t need to know
> > the original image size, just the new size, and NSImage/XRender
> > handles the rest.
> 
> Well, on w32, the implementation actually resizes when it draws.
> Maybe that's sub-optimal, but I know next to nothing about w32 image
> display, so what I got looks definitely fine for my ignorance.

I believe that with XRender, and possibly with NS, the actual resizing
is done at draw time, it’s just that the drawing functions don’t need
to know about it because it’s already built into the image types.

> So we now have native resizing on all major platforms.

Excellent! Thanks!

> > We could use XRender to rotate images if we really wanted to, and the
> > NS port already supports it.
> 
> Where's the NS support for that?  AFAICT, :rotate is only handled in
> ImageMagick specific portions of the code, what did I miss?

It’s buried in nsimage.m, ns_load_image gets both :rotation and
:index, then processes the image as appropriate.

If we were to add XRender rotation support, I’d be tempted to do both
rotation and scaling using affine transformation matrices in both
XRender and NS, as they would then both use the same code to calculate
the transforms. I believe Windows supports transformation matrices
through D2D, but I assume Emacs doesn’t use D2D currently, so it may
not be straight forward to add.

If we were to go that far, it may be worth actually exposing the
matrices to lisp and handle the calculations there, but that would
potentially be a big change to the API.
-- 
Alan Third

Re: Testing native image scaling

[Eli Zaretskii]

> Date: Sun, 20 Jan 2019 19:26:31 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: emacs-devel@gnu.org
> 
> > Where's the NS support for that?  AFAICT, :rotate is only handled in
> > ImageMagick specific portions of the code, what did I miss?
> 
> It’s buried in nsimage.m, ns_load_image gets both :rotation and
> :index, then processes the image as appropriate.

Thanks, I will take a look.

> If we were to add XRender rotation support, I’d be tempted to do both
> rotation and scaling using affine transformation matrices in both
> XRender and NS, as they would then both use the same code to calculate
> the transforms. I believe Windows supports transformation matrices
> through D2D, but I assume Emacs doesn’t use D2D currently, so it may
> not be straight forward to add.

Windows can calculate and use transformation matrices without D2D as
well, it's really quite simple.  You calculate the matrix elements,
and then call a function to install it for the next BitBlt.

> If we were to go that far, it may be worth actually exposing the
> matrices to lisp and handle the calculations there

What advantages would that give us?  Wouldn't it be better to support
higher-level abstractions for the transformations, like scaling,
rotation, and shear?

Re: Testing native image scaling

[Alan Third]

On Sun, Jan 20, 2019 at 09:41:02PM +0200, Eli Zaretskii wrote:
> 
> > If we were to add XRender rotation support, I’d be tempted to do both
> > rotation and scaling using affine transformation matrices in both
> > XRender and NS, as they would then both use the same code to calculate
> > the transforms. I believe Windows supports transformation matrices
> > through D2D, but I assume Emacs doesn’t use D2D currently, so it may
> > not be straight forward to add.
> 
> Windows can calculate and use transformation matrices without D2D as
> well, it's really quite simple.  You calculate the matrix elements,
> and then call a function to install it for the next BitBlt.

Sounds very similar to how XRender works. It might be worth giving
this a go, then.

> > If we were to go that far, it may be worth actually exposing the
> > matrices to lisp and handle the calculations there
> 
> What advantages would that give us?  Wouldn't it be better to support
> higher-level abstractions for the transformations, like scaling,
> rotation, and shear?

It would simplify the C code, and move those higher level abstractions
into lisp. I’m not sure if that’s a good thing, but hasn’t it been the
stated intention of the Emacs project for a while?

It would make it harder to understand for a human what any given image
spec would be expected to do, but then I don’t know if humans look at
image specs much.
-- 
Alan Third

Re: Testing native image scaling

[YAMAMOTO Mitsuharu]

On Mon, 21 Jan 2019 01:05:18 +0900,
Eli Zaretskii wrote:
> 
> > Date: Sat, 19 Jan 2019 21:45:43 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> > 
> > On Sat, Jan 19, 2019 at 11:31:34AM +0200, Eli Zaretskii wrote:
> > > Alan, could you please tell how you tested native image scaling with
> > > the XRENDER extension, and perhaps show some Lisp or existing commands
> > > you used for that?  E.g., did the features in thumbs.el work for you
> > > in a build without Imagemagick?
> > 
> > I just used a fairly simple series of commands like this:
> > 
> > (setq i (create-image "~/image.png" nil nil :scale 0.5))
> > (insert-image i)
> > (setq ii (create-image "~/image.png" nil nil :scale 0.5))
> > (insert "\n")
> > (insert-image ii)
> 
> Thanks, this was very helpful.  (Actually, just create-image with one
> argument is enough: after inserting it, '+' or '-' on the image will
> interactively resize it.)

I think we should test sliced images as well.

  (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5)

Actually, I suspect this does not work on W32 because the comparison
with the original image size is made for s->slice.width (or height)
rather than s->img->width (or height) as I just did for cairo code.
Could you check it on W32?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Testing native image scaling

[Eli Zaretskii]

> Date: Wed, 27 Mar 2019 11:35:26 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Alan Third <alan@idiocy.org>,
> 	emacs-devel@gnu.org
> 
>   (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5)
> 
> Actually, I suspect this does not work on W32 because the comparison
> with the original image size is made for s->slice.width (or height)
> rather than s->img->width (or height) as I just did for cairo code.
> Could you check it on W32?

It seems to work, but maybe I don't know what and how to check.  Can
you show what I should expect to see with and without the :scale
attribute, in "emacs -Q"?

Thanks.

Re: Testing native image scaling

[Andy Moreton]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Wed 27 Mar 2019, Eli Zaretskii wrote:

>> Date: Wed, 27 Mar 2019 11:35:26 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Cc: Alan Third <alan@idiocy.org>,
>> 	emacs-devel@gnu.org
>> 
>>   (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5)
>> 
>> Actually, I suspect this does not work on W32 because the comparison
>> with the original image size is made for s->slice.width (or height)
>> rather than s->img->width (or height) as I just did for cairo code.
>> Could you check it on W32?
>
> It seems to work, but maybe I don't know what and how to check.  Can
> you show what I should expect to see with and without the :scale
> attribute, in "emacs -Q"?
>
> Thanks.

I would expect a sliced image to be composed of a grid of tiled images
instead of a single image, but to have the same visual appearance as the
original image. The w32 code does not get this right.


[-- Attachment #2: w32-sliced-image.png --]
[-- Type: image/png, Size: 18415 bytes --]

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]


Adding the ":scale 0.5" argument scales down the tiled array of images
correctly, but they still contain the same display artifacts as the
sliced image without scaling.

    AndyM

Re: Testing native image scaling

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 27 Mar 2019 18:35:09 +0000
> 
> > It seems to work, but maybe I don't know what and how to check.  Can
> > you show what I should expect to see with and without the :scale
> > attribute, in "emacs -Q"?
>
> I would expect a sliced image to be composed of a grid of tiled images
> instead of a single image, but to have the same visual appearance as the
> original image. The w32 code does not get this right.

Did insert-sliced-image ever work on Windows, even before scaling was
added?

> Adding the ":scale 0.5" argument scales down the tiled array of images
> correctly, but they still contain the same display artifacts as the
> sliced image without scaling.

Thanks, but I asked for the _correct_ image I need to expect, because
I want something to compare to if/when I decide to try to fix this.

Re: Testing native image scaling

[Andy Moreton]

On Wed 27 Mar 2019, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Wed, 27 Mar 2019 18:35:09 +0000
>> 
>> > It seems to work, but maybe I don't know what and how to check.  Can
>> > you show what I should expect to see with and without the :scale
>> > attribute, in "emacs -Q"?
>>
>> I would expect a sliced image to be composed of a grid of tiled images
>> instead of a single image, but to have the same visual appearance as the
>> original image. The w32 code does not get this right.
>
> Did insert-sliced-image ever work on Windows, even before scaling was
> added?
>
>> Adding the ":scale 0.5" argument scales down the tiled array of images
>> correctly, but they still contain the same display artifacts as the
>> sliced image without scaling.
>
> Thanks, but I asked for the _correct_ image I need to expect, because
> I want something to compare to if/when I decide to try to fix this.

Sorry - I thought that was clear. The following forms should all produce
the same visual appearance in the buffer:

(insert-image (create-image "splash.png" nil nil :scale 0.5))

(insert-sliced-image (create-image "splash.png" nil nil :scale 0.5)
 nil nil 1 1)

(insert-sliced-image (create-image "splash.png" nil nil :scale 0.5)
 nil nil 3 5)

The sliced images are displayed as an array of tiled smaller images, but
should otherwise have the same appearance as the original (non-sliced)
image.

    AndyM

Re: Testing native image scaling

[Andy Moreton]

On Wed 27 Mar 2019, Andy Moreton wrote:

> On Wed 27 Mar 2019, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <andrewjmoreton@gmail.com>
>>> Date: Wed, 27 Mar 2019 18:35:09 +0000
>>> 
>>> > It seems to work, but maybe I don't know what and how to check.  Can
>>> > you show what I should expect to see with and without the :scale
>>> > attribute, in "emacs -Q"?
>>>
>>> I would expect a sliced image to be composed of a grid of tiled images
>>> instead of a single image, but to have the same visual appearance as the
>>> original image. The w32 code does not get this right.
>>
>> Did insert-sliced-image ever work on Windows, even before scaling was
>> added?

This works correctly (without native scaling) on the emacs-26 branch.
The following forms result in the same visual appearance in the buffer.

(insert-image (create-image "splash.png" nil nil))
(insert-sliced-image (create-image "splash.png" nil nil) nil nil 1 1)
(insert-sliced-image (create-image "splash.png" nil nil) nil nil 3 5)

    AndyM

Re: Testing native image scaling

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Thu, 28 Mar 2019 03:35:09 +0900,
Andy Moreton wrote:
> 
> [1  <text/plain (7bit)>]
> On Wed 27 Mar 2019, Eli Zaretskii wrote:
> 
> >> Date: Wed, 27 Mar 2019 11:35:26 +0900
> >> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >> Cc: Alan Third <alan@idiocy.org>,
> >> 	emacs-devel@gnu.org
> >> 
> >>   (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5)
> >> 
> >> Actually, I suspect this does not work on W32 because the comparison
> >> with the original image size is made for s->slice.width (or height)
> >> rather than s->img->width (or height) as I just did for cairo code.
> >> Could you check it on W32?
> >
> > It seems to work, but maybe I don't know what and how to check.  Can
> > you show what I should expect to see with and without the :scale
> > attribute, in "emacs -Q"?
> >
> > Thanks.
> 
> I would expect a sliced image to be composed of a grid of tiled images
> instead of a single image, but to have the same visual appearance as the
> original image. The w32 code does not get this right.

Thanks for the screenshot.  That's what I suspected from the code in
w32term.c and the documentation of StretchBlt.  Below is the
screenshot on Xrender, and it should be the expected result.  The
cursor is at the last row and the last column of the sliced image.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp


[-- Attachment #2: sliced-scaled.png --]
[-- Type: image/png, Size: 36671 bytes --]

Re: Testing native image scaling

[Eli Zaretskii]

> Date: Thu, 28 Mar 2019 11:26:46 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > > It seems to work, but maybe I don't know what and how to check.  Can
> > > you show what I should expect to see with and without the :scale
> > > attribute, in "emacs -Q"?
> > >
> > > Thanks.
> > 
> > I would expect a sliced image to be composed of a grid of tiled images
> > instead of a single image, but to have the same visual appearance as the
> > original image. The w32 code does not get this right.
> 
> Thanks for the screenshot.  That's what I suspected from the code in
> w32term.c and the documentation of StretchBlt.  Below is the
> screenshot on Xrender, and it should be the expected result.  The
> cursor is at the last row and the last column of the sliced image.

Thanks, I think I fixed this now.

Re: Testing native image scaling

[Andy Moreton]

On Thu 28 Mar 2019, Eli Zaretskii wrote:

>> Date: Thu, 28 Mar 2019 11:26:46 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> 
>> > > It seems to work, but maybe I don't know what and how to check.  Can
>> > > you show what I should expect to see with and without the :scale
>> > > attribute, in "emacs -Q"?
>> > >
>> > > Thanks.
>> > 
>> > I would expect a sliced image to be composed of a grid of tiled images
>> > instead of a single image, but to have the same visual appearance as the
>> > original image. The w32 code does not get this right.
>> 
>> Thanks for the screenshot.  That's what I suspected from the code in
>> w32term.c and the documentation of StretchBlt.  Below is the
>> screenshot on Xrender, and it should be the expected result.  The
>> cursor is at the last row and the last column of the sliced image.
>
> Thanks, I think I fixed this now.

Confirmed.

Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size'
and `image-increase-size' be adjusted to handle sliced images ?

Also, in w32 builds of emacs-26 'M-X image-rotate' on a (non-sliced)
image logs a message: "image--get-imagemagick-and-warn: Cannot rescale
images without ImageMagick support", whereas on master it does nothing.
Is image rotation expected to work on Windows ?

    AndyM

Re: Testing native image scaling

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 28 Mar 2019 18:06:17 +0000
> 
> Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size'
> and `image-increase-size' be adjusted to handle sliced images ?

It would be nice, yes.

> Is image rotation expected to work on Windows ?

Not without ImageMagick, no.  (And not only on Windows, AFAIK.)

Re: Testing native image scaling

[Andy Moreton]

On Thu 28 Mar 2019, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Thu, 28 Mar 2019 18:06:17 +0000
>> 
>> Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size'
>> and `image-increase-size' be adjusted to handle sliced images ?
>
> It would be nice, yes.

A little experimentation shows that changing `image--get-image' as below
seems to be sufficient to work for normal and sliced images:

(defun image--get-image ()
  "Return the image at point."
  (let ((image (get-char-property (point) 'display))
        result)
    (when (consp image)
      (if (eq (car image) 'image)
          (setq result image)
        (dolist (x image)
          (if (eq (car-safe x) 'image)
              (setq result x)))))
    (when (null result)
      (error "No image under point"))
    result))

>> Is image rotation expected to work on Windows ?
>
> Not without ImageMagick, no.  (And not only on Windows, AFAIK.)

ok, but if ImageMagick is not available it used to complain and now does
not. It should still report the same error message rather than failing
silently.

    AndyM

Re: Testing native image scaling

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 28 Mar 2019 19:29:45 +0000
> 
> >> Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size'
> >> and `image-increase-size' be adjusted to handle sliced images ?
> >
> > It would be nice, yes.
> 
> A little experimentation shows that changing `image--get-image' as below
> seems to be sufficient to work for normal and sliced images:
> 
> (defun image--get-image ()
>   "Return the image at point."
>   (let ((image (get-char-property (point) 'display))
>         result)
>     (when (consp image)
>       (if (eq (car image) 'image)
>           (setq result image)
>         (dolist (x image)
>           (if (eq (car-safe x) 'image)
>               (setq result x)))))
>     (when (null result)
>       (error "No image under point"))
>     result))

LGTM, thanks.

> >> Is image rotation expected to work on Windows ?
> >
> > Not without ImageMagick, no.  (And not only on Windows, AFAIK.)
> 
> ok, but if ImageMagick is not available it used to complain and now does
> not. It should still report the same error message rather than failing
> silently.

The error message is bogus anyway, as it talks about rescaling,
instead of talking about rotating.  IOW, it's a bug in the message
that should be fixed.