Page 1 of 2
possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T15:05:53-07:00
by fmw42
ImageMagick 6.6.6-5 2010-12-13 Q16 HDRI Mac OSX Tiger
convert -size 10x10 xc:red xc:none +append testfx.png
x=5
y=5
convert testfx.png -format "%[fx:u.p{$x,$y}]" info:
convert: unable to parse expression `' @ error/fx.c/FxGetSymbol/1524.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T17:06:53-07:00
by magick
A $ symbol is not a valid symbol in the FX language as defined here:
http://www.imagemagick.org/script/fx.php. If you expect $x to be 5, it's not because the quotes prevent the FX expression from being evaluated by your shell.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T17:29:30-07:00
by fmw42
magick wrote:A $ symbol is not a valid symbol in the FX language as defined here:
http://www.imagemagick.org/script/fx.php. If you expect $x to be 5, it's not because the quotes prevent the FX expression from being evaluated by your shell.
This is very strange as it worked when I wrote my multicrop script (Jan 2010) and when Anthony modified it (Aug 2010). But it fails now with that error message. This is the actual code line in the multicrop script. I just simplified it for a simpler example of its failure.
testcolor=`convert $tmp/MASK.mpc -channel rgba -alpha on -format "%[fx:u.p{$x,$y}=="none"?0:1]" info:`
Is it possible something was changed since Aug that might have made the error trapping in the fx expressions now sensitive to the $ where it might have fortuitously parsed it before?
(I will have Anthony check his version of the script, also with the current release).
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T17:40:41-07:00
by fmw42
See my previous comment above.
I believe that this line was probably incorrect in the script:
testcolor=`convert $tmp/MASK.mpc -channel rgba -alpha on -format "%[fx:u.p{$x,$y}=="none"?0:1]" info:`
and probably should have been
testcolor=`convert $tmp/MASK.mpc -channel rgba -alpha on -format "%[pixel:u.p{$x,$y}=="none"?0:1]" info:`
but even that does not work now for me.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T18:24:36-07:00
by anthony
magick wrote:A $ symbol is not a valid symbol in the FX language as defined here:
http://www.imagemagick.org/script/fx.php. If you expect $x to be 5, it's not because the quotes prevent the FX expression from being evaluated by your shell.
Nothing to do with the '$' that is just a shell substitution. IM does not see them...
Here I removed them...
Code: Select all
convert testfx.png -format "%[fx:u.p{5,5}]" info:
convert: unable to parse expression `' @ error/fx.c/FxGetSymbol/1524.
However 'pixel' is working (for me anyway)
Code: Select all
convert testfx.png -format "%[pixel:u.p{5,5}]" info:
red
convert testfx.png -format "%[pixel:u.p{15,5}]" info:
none
-----------------
ASIDE to Fred. The expression should be %[fx:...] it is comparing value numbers!!!!
pixel does not compare strings can can't be used.
However that specific test
Code: Select all
testcolor=`convert $tmp/MASK.mpc -channel rgba -alpha on -format \
"%[pixel:u.p{$x,$y}=="none"?0:1]" info:`
if [ $testcolor -eq 1 ]; then
is probably not really a good one.
The test does ONE fx test on the one image, red channel only (-channels not used)
As such it is only testing if the pixel is red (1) or not (0) and doing so badly!
As such the simplified equivalent is simply...
Code: Select all
testcolor=`convert $tmp/MASK.mpc -format `"%[fx:u.p{$x,$y}]" info:`
if [ $testcolor -eq 1 ]; then
When the FX gets fixed.
But if you want it working now change it to..
Code: Select all
testcolor=`convert $tmp/MASK.mpc -format `"%[pixel:u.p{$x,$y}]" info:`
if [ $testcolor = 'red' ]; then
After all the mask image only contains the colors red or none.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T18:33:09-07:00
by magick
Ok, We'll get a patch into Subversion to fix this problem by sometime tomorrow.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T18:43:11-07:00
by fmw42
magick wrote:Ok, We'll get a patch into Subversion to fix this problem by sometime tomorrow.
Thanks
I just tested:
testcolor=`convert testfx.png -format "%[fx:u.p{5,5}]" info:`
convert: unable to parse expression `' @ error/fx.c/FxGetSymbol/1524.
And now see that Anthony also had the same idea and test and got the same results above.
P.S.
Also see
viewtopic.php?f=1&t=17577. He is trying to modify my multicrop script and it works for him. I asked him to identify the version of IM he is using in case that would make it easier to compare versions to see what has changed.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T18:51:24-07:00
by anthony
Fred a fixed version of multi_crop is on my TEST server (limited access)
http://wraith.rcs.griffith.edu.au/~anth ... multi_crop
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T19:00:03-07:00
by fmw42
I tried changing it from fx: to pixel: in my old syntax but that does not work right as it cannot (I now realize) do the == test.
testcolor=`convert testfx.png -format "%[pixel:u.p{5,5}==none?0:1]" info:`
echo "$testcolor"
red
So I see that you split the test into two parts. Clever! I should have thought of that. Thanks.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T19:05:22-07:00
by magick
The bug you reported is fixed in in ImageMagick 6.6.6-6 beta available now. Thanks.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-14T19:51:39-07:00
by fmw42
magick wrote:The bug you reported is fixed in in ImageMagick 6.6.6-6 beta available now. Thanks.
Thanks.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-16T18:19:18-07:00
by anthony
Something still seems strange...
convert testfx.png -format "%[fx:p{5,5}]" info:
0.299001
That should be,
by definition, the red channel value, which should be 1.0, not 0.299
Has the definition changed, and you now get a greyscale value?
Definition from
The Fx Special Effects Image Operator...
For use with -format, the value-escape %[fx: ] is evaluated just once for each image in the current image sequence. As each image in the sequence is being evaluated, s and t successively refer to the current image and its index, while i and j are set to zero, and the current channel set to red (-channel is ignored).
That last part specifies that red is the current channel setting when the single calculation for each image is performed. Debugging...
convert testfx.png -format "%[fx:debug(p{5,5});p{5,5}]" info:
[0,0].unknown: p{5,5}=0.299001
0.299001
What is 'channel unknown'!!!!
Of course actually specifically specifying the result of the red channel does produce
convert testfx.png -format "%[fx:p{5,5}.r]" info:
1
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-16T18:45:00-07:00
by magick
We previously specified the red channel but there was a bug report which required we go from the red channel to the default channels. ChangeLog says:
- 2010-11-08 6.6.5-8 Cristy <quetzlzacatenango@image...>
* %[fx:mean] is the mean of the default channels (all but opacity) (reference
viewtopic.php?f=1&t=17432).
Now -format "%[fx:p{5,5}]" returns the grayscale value of the pixel.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-16T21:20:00-07:00
by anthony
I would have expected that %[fx:mean] be quite a different setting to %[fx:p{5,5}] with no relation to each other.
Re: possible bug fx escape IM 6.6.6.5
Posted: 2010-12-17T05:52:12-07:00
by magick
FX escape was an after-thought when the -fx option was designed. In addition, image info metadata is not available when its called from the properties realm so we had to implement it in a restrictive manner.