Legacy ImageMagick Discussions Archive

I was contacted by a user who reported that my script, defisheye, was not working. I have verified that it was working in IM 6.7.2-10 but not in IM 6.7.3-10 or later. It turns out that several other scripts, all involving complicated fx expressions are also failing (but not others). There is no error message, just a bad resulting image. I have openmp disabled to be sure that was not the issue.

I spent most of the day trying to find something all the failing scripts have in common or to try to narrow down the problem without success, so I spent more time trying to narrow down the releases between which the problem has started.

I assume it has something to do with -fx. But the only change I see in the changelog occurred at 6.7.1.1, so I suspect that is not the issue.

2011-08-01 6.7.1-1 Cristy <quetzlzacatenango@image...>
...
Support -fx acosh(), asinh(), and atanh().


Input image:



Here is a proper result from running my script under IM 6.7.2-10:

defisheye -o 120 -i 180 -t linear -f circular bigben2.jpg bigben2_tmp_6.7.2-10_noopenmp_nopango.png





Here is a failing result from running my script under IM 6.7.3-10 and 6.7.5.10:

defisheye -o 120 -i 180 -t linear -f circular bigben2.jpg bigben2_tmp_6.7.3-10_vpblack_noopenmp_nopango.png



If I disable -virtual-pixel or set it to edge by editing the script, then I get:



This tells me only the center pixel is being computed correctly in the latter releases, which is probably due to the ternary condition used in the fx expression that traps a zero divide and sets the result to 0. My guess is that it might have to do with some change to the computation of atan or atan2. But this is just a guess at this point.

I do not have any releases between these two. If the IM developers have in between versions, let me know where and I can try to pin it down further.

If not, is there any debug statement that I can include to get any information that might help?

My script can be downloaded for testing with the above images and commands from my web site link below.

We'll track down the problem and apply a patch within a day or two. Stand by...

I will try to pare down the script tomorrow to a few command lines for the example above and provide that for testing.

Here are the simplified commands from the script that processes the example image above.


infile="bigben2.jpg"
inname=`convert $infile -format "%t" info:`
outfile="${inname}_test.png"
width=150
height=150
ifov=180
ofov=120
vp="edge"
dim=150
xcd=74.5
xcs=74.5
ycd=74.5
ycs=74.5
ofoc=`convert xc: -format "%[fx:$dim/(2*tan($ofov*pi/360))]" info:`
ofocinv=`convert xc: -format "%[fx:1/$ofoc]" info:`
ifoc=`convert xc: -format "%[fx:($dim*180)/($ifov*pi)]" info:`
echo "ofoc=$ofoc; ofocinv=$ofocinv; ifoc=$ifoc;"
xd="xd=i-$xcd;"
yd="yd=j-$ycd;"
rd="rd=hypot(xd,yd);"
phi="phi=atan($ofocinv*rd);"
rr="rr=$ifoc*phi;"
xs="xs=(rd?rr/rd:0)*xd+$xcs;"
ys="ys=(rd?rr/rd:0)*yd+$ycs;"
convert $infile -virtual-pixel $vp -monitor -fx \
"$xd $yd $rd $phi $rr $xs $ys u.p{xs,ys}" \
$outfile

Phi is a reserved constant. See http://www.imagemagick.org/script/fx.php#anatomy. Change phi in your script to feye, for example, and your script will work on all versions of ImageMagick that support FX expressions.

We could check to see if a constant is overridden by an fx expression, its only a single line of code. However, that can be problematic too. For example,

• $max=3;$xx=max(3,3);

Max is defined as a variable, so the max() function would fail since its been redefined. Or we could check for assignments to constants (e.g. $phi=3). We could do these deeper checks but recall the parser is simple-n-stupid for performance reasons so we want to avoid more sophisticated parsing.

What's your preference?

magick wrote:Phi is a reserved constant. See http://www.imagemagick.org/script/fx.php#anatomy. Change phi in your script to feye, for example, and your script will work on all versions of ImageMagick that support FX expressions.

We could check to see if a constant is overridden by an fx expression, its only a single line of code. However, that can be problematic too. For example,

• $max=3;$xx=max(3,3);

Max is defined as a variable, so the max() function would fail since its been redefined. Or we could check for assignments to constants (e.g. $phi=3). We could do these deeper checks but recall the parser is simple-n-stupid for performance reasons so we want to avoid more sophisticated parsing.

What's your preference?

I will fix my scripts. But please explain why it works on older versions and not newer ones, was this a new addition to fx?

Thanks for finding that. I was totally puzzled.

Fred

The Phi constant was introduced last October.

magick wrote:The Phi constant was introduced last October.

Thanks. I tested the code above with a change of name for phi and it works fine. So I will just edit my scripts to replace the name in the affected scripts that use phi in fx.

Thanks. I have updated and tested the affected scripts and all seem to work fine.

I appreciate the fast response in finding the issue.

Just on a related FX matter with IMv7

Eventually I will be looking at allowing (almost) all operational arguments to make use of percent escapes substitutions. Not just strings, but also geometry arguments and I plan to even include FX expressions.

For example tint a image by the background color... The %[background] will be replaced by the current background color value of the image in the expession
before being executed across the whole image.

However for FX this may mean that the modulus operator '%' may either always need doubling (%%), OR replacing that operator with a mod() function. Alternately only allow %[...] syntax in FX expressions.


NOTE: I will also have the problem of percent escapes in percent escapes. For example So I need to make sure that percent escapes become savvy enough to allow embedded percent escapes.
I have other reasons for wanting to allow that!

However for FX this may mean that the modulus operator '%' may either always need doubling (%%), OR replacing that operator with a mod() function. Alternately only allow %[...] syntax in FX expressions.

Barring other objections, I would opt for mod().

I have one pet peeve now with IM 6. If I create variable for -geometry +${xoff}+${yoff} and those variable are negative, IM cannot handle it. Furthermore if I do -geometry ${xoff}${yoff}, then if xoff or yoff is positive, but without a sign, IM goes into some kind of loop on my system and fills my disk.

Is this something that can be solved in IM 7

Right now I have to add a few commands to test for sign and then add + if positive for the latter case. It would be nice if IM would recognize +-10 as -10.

Fred

Yes I have had to add specific code for that myself..

But if you can use printf or awk printf you can ask it to always add the sign for you...
I am thinking of adding a printf percent escape for formating numbers and strings

But I'll add that to my list to make geometry not barf on a +- syntax.