Legacy ImageMagick Discussions Archive

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...

out1-0.png


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...
Any ideas?

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

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

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.

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.

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 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...
... 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.

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 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.