Odd output from an FX calculation

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
User avatar
GeeMack
Posts: 718
Joined: 2015-12-01T22:09:46-07:00
Authentication code: 1151
Location: Central Illinois, USA

Odd output from an FX calculation

Post by GeeMack »

Using IM 7.0.4-9 HDRI on Windows 10 64 command shell.

I stumbled across what may be a buggy FX calculation, or may just be a misunderstanding on my part. When I run the following command, I get the two output images below...

Code: Select all

magick -size 80x40 xc:red -duplicate 1 -extent %[fx:u[0].w*2]x%[h] out1-%d.png
Image
out1-0.png

Image
out1-1.png

I would expect the images to be the same dimensions, but obviously they're not. I'd think the FX expression "%[fx:u[0].w*2]" should simply double the width of the first image in the stack "u[0].w", and "-extent" should use that value for the width of the viewport on both images. Oddly, the second output image has actually doubled again. It went from the 160 pixels I'd expect to 320 pixels wide.

This effect doesn't occur when I use the second image in the stack "u[1].w" to calculate the width. The following command correctly outputs two images of the same size, 160 pixels wide like the first image above...

Code: Select all

magick -size 80x40 xc:red -duplicate 1 -extent %[fx:u[1].w*2]x%[h] out2-%d.png
Any ideas?
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Odd output from an FX calculation

Post by fmw42 »

since both images are the same size, why reference either u[0] or u[1]? Why not just

Code: Select all

magick -size 80x40 xc:red +duplicate -extent %[fx:w*2]x%[h] out1-%d.png
which works fine.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Odd output from an FX calculation

Post by fmw42 »

Seems like IM is extending the first image, then getting the width of that extended image to use for the duplicate, so that the duplicate is doubled again
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Odd output from an FX calculation

Post by fmw42 »

Perhaps what you really want is to use the image sequence index t as u[t]. That should double the width of any image in the sequence.

Code: Select all

im7 magick -size 80x40 xc:red -duplicate 1 -extent %[fx:u[t].w*2]x%[h] out1-%d.png
User avatar
GeeMack
Posts: 718
Joined: 2015-12-01T22:09:46-07:00
Authentication code: 1151
Location: Central Illinois, USA

Re: Odd output from an FX calculation

Post by GeeMack »

fmw42 wrote: 2017-02-16T14:39:23-07:00 Perhaps what you really want is to use the image sequence index t as u[t]. That should double the width of any image in the sequence.
My examples above are simplified just to show the effect. In the situation I'm working with the images won't all be the same size, but I'll be using the width of one of them to "-extent" them all.
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Odd output from an FX calculation

Post by snibgo »

As I understand it, the %[fx:] is recalculated for each image. And that explains the result.

The first time is calculated (for the first image), the width of image 0 is 80. But when the fx is calculated for the second image, the width of image 0 is 160.

To get the same size for both, save the width (or calculation from the width) into a "-define" before doing an "-extent".
snibgo's IM pages: im.snibgo.com
User avatar
GeeMack
Posts: 718
Joined: 2015-12-01T22:09:46-07:00
Authentication code: 1151
Location: Central Illinois, USA

Re: Odd output from an FX calculation

Post by GeeMack »

snibgo wrote: 2017-02-16T16:14:51-07:00The first time is calculated (for the first image), the width of image 0 is 80. But when the fx is calculated for the second image, the width of image 0 is 160.
I've considered that, too. If I run the command duplicating the image more times like this...

Code: Select all

magick -size 80x40 xc:red -duplicate 4 -extent %[fx:u[0].w*2]x%[h] out3-%d.png
... the first output image is 160x40 as expected, then the second image and onward are all 320 pixels wide. So that doesn't seem to explain the whole phenomenon.
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Odd output from an FX calculation

Post by snibgo »

GeeMack wrote:...the first output image is 160x40 as expected, then the second image and onward are all 320 pixels wide. So that doesn't seem to explain the whole phenomenon.
Doesn't it?

The first time fx is calculated (for the first image), the width of image 0 is 80. This doubles the size of image 0, making it 160.

The second time fx is calculated (for the second image), the width of image 0 is 160. So image 1 is set to 320 pixels wide. But image 0 remains at 160 wide.

The third time fx is calculated (for the third image), the width of image 0 is still 160. It hasn't changed. So image 2 is set to 320 pixels wide.
snibgo's IM pages: im.snibgo.com
User avatar
GeeMack
Posts: 718
Joined: 2015-12-01T22:09:46-07:00
Authentication code: 1151
Location: Central Illinois, USA

Re: Odd output from an FX calculation

Post by GeeMack »

snibgo wrote: 2017-02-16T17:29:53-07:00[...] The third time fx is calculated (for the third image), the width of image 0 is still 160. It hasn't changed. So image 2 is set to 320 pixels wide.
Thanks for the breakdown. I was overlooking a step (or inserting an unneeded step) in the math in my head. I can use a "-define" as you suggested. Another way to get what I need with an unknown number of images in the stack, is to move the image I'm using as a gauge to the last position with something like "-swap ..." or "-reverse", and run the operation using "u[-1].w". Then it won't change that reference measurement until it's done with all the others.
Post Reply