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.
Using ImageMagick 6.9.9-33 HDRI on Windows 10, I've come across an odd output to a particular command. I've reduced the command to just what it takes to create the issue. From the command line I try this...
convert.exe: divide by zero `w/(n-1.0*1)' @ error/fx.c/FxEvaluateSubexpression/2178.
Obviously that part of the error "w/(n-1.0*1)" is quite different from the actual FX expression in the command. To add to the mystery, if I "-write tmp.png" that intermediate file as another format like "tmp.gif", "tmp.jpg", or "tmp.tif", the command doesn't generate an error. It only seems to occur when I write that file as a PNG.
I do not think you can do that in IM 6. It works fine in IM 7 and fails for me in IM 6. I do not think -set page knows about %n in IM 6. If you substitute 4 in for n, then it works in IM 6. That confirms it to me.
fmw42 wrote: ↑2018-01-22T11:42:02-07:00I do not think you can do that in IM 6. It works fine in IM 7 and fails for me in IM 6. I do not think -set page knows about %n in IM 6. If you substitute 4 in for n, then it works in IM 6. That confirms it to me.
The command produces the expected result other than the error message. It doesn't squawk if I use any of these FX expressions...
I don't understand the mystery. Within the parentheses, the number of images is one. So n=1, and n-1=0, so there is a divide by zero. This is evaluated only if needed, such as when the output is a PNG.
The error message is a bit weird, I assume because IM has tokenised the expression, and is de-tokenising it for the message. But that evaluates to the same, n-1*1, so it is still zero.
snibgo wrote: ↑2018-01-22T13:14:22-07:00I don't understand the mystery. Within the parentheses, the number of images is one. So n=1, and n-1=0, so there is a divide by zero. This is evaluated only if needed, such as when the output is a PNG.
The error message is a bit weird, I assume because IM has tokenised the expression, and is de-tokenising it for the message. But that evaluates to the same, n-1*1, so it is still zero.
I would think resetting the paging information inside the parentheses with "+repage", "+set page", or "-set page +0+0" might prevent that, but apparently the calculation sticks with that clone all the way up to, but not including, the output.
f:\web\im>%IM%convert rose: -duplicate 3 ( +clone -format "N=%n\n" -write info:
+delete ) info:
N=1 <== this is the output from within the parenthesis.
N=4
N=4
N=4
N=4
GeeMack wrote:I would think resetting the paging information inside the parentheses with "+repage", "+set page", or "-set page +0+0" might prevent that, but apparently the calculation sticks with that clone all the way up to, but not including, the output.
The string expression isn't expanded until it is needed. This is more clearly seen with "-format", and I assume "-set page" works in the same way, so it substitutes values as appropriate to each image. For example:
snibgo wrote: ↑2018-01-22T16:58:00-07:00Except that the computation isn't done then. The page is merely set to a string, and the string isn't expanded until it is needed.
It seems the need for the calculation might be eliminated by resetting the paging for that one image inside the parentheses using one of these methods, but they all generate the same error message.
I don't know why setting the page inside the parentheses doesn't cure the problem. I guess the previous page setting isn't removed, and gets expanded, even though it isn't used.
Moving the "-set page" to after the parentheses does cure the problem: