compare -subimage-search issues in bash loop

[hasso]

version 6.7.5-7 on Linux Mint 10

I am trying to extract a series of similar (but not 100% similar) subimages from an image. I know the approximate position of each of these sub-images (they are pretty regularly spaced within the image), so I've written a bash script with a "for" loop which in turn extracts each approximate area, saves it as an interim.tif image and then does a 'compare subimage-search' on the interim.tif to find the exact location of the subimage. Then the script extracts the subimage and saves it as a jpg. While in every case it gives me the location of the first sub-image while doing the loop, every subsequent 'compare -subimage-search' of newly created interim.tif files in the loop comes back with an "geometry does not contain image" error... even when I can plainly see the sub-image in the created interim.tif. This happens everytime.

The script is below. Maybe I'm just doing something silly, but what could be causing this?

The error occurs when this line is executed the second (and subsequent times in the loop):

• val=$(compare -metric rmse -subimage-search -dissimilarity-threshold 1.0 interim.tif sprocket.tif results 2>&1)

Code: Select all

 #!/bin/bash

strip="Capture/001a.tif"
W=`identify -ping -format %w "$strip"`
H=`identify -ping -format %h "$strip"`
height=936
width=718
z=0
Z=0

iheight=$(($H / 2))
iheight=$(printf %.0f $iheight)

w=`identify -ping -format %w "sprocket.tif"`
h=`identify -ping -format %h "sprocket.tif"`

xwidth=$(($width + 20))
xheight=$(($height + $h + 10))

start=0
for i in $(eval echo {$start..$W..$width})
  do
    z=$((z+1))
    convert -extract ${width}x${iheight}+${i}+0 $strip interim.tif
    val=$(compare -metric rmse -subimage-search -dissimilarity-threshold 1.0 interim.tif sprocket.tif results 2>&1)
    value=`echo "$val" | cut -f 4 -d' '`
    x=`echo $value | cut -d',' -f 1`
    y=`echo $value | cut -d',' -f 2`
    end=$(($i + $x + $xwidth))
    if [ $end -le $W ]; then
    x=$((x + $i))
    convert -extract ${xwidth}x${xheight}+${x}+${y} $strip extracted/${z}.jpg     
    fi
  done

[fmw42]

Two potential issues.

1) the larger image must be first in the command line, then the smaller image. You may have this correct, but I am not sure from your script which is which.

2) the "results" image needs a file type extension, such as png (then you get two images) or tif or gif (then you get two frames)

[hasso]

thanks for the fast reply...
1. yes... interim.tif (first) is always larger than sprocket.tif (second), and visual comparison of the interim.tif's produced always contain the sprocket.tif subimage.
2. I have tried adding the extension (such as results.tif) and no difference
First time round the loop, I get the location of the sub-image, subsequent loops always give me ""geometry does not contain image".

[fmw42]

Put some echoes in to get the arguments being fed to:

convert -extract ${width}x${iheight}+${i}+0 $strip interim.tif

to be sure that the extracted size is not larger or off the $strip dimensions

Be sure you are feeding the correct width and height and offset arguments.

Check your looping sytnax with simple echoes in place of everthing else to see what your are getting from

for i in $(eval echo {$start..$W..$width})



or try using this subsection syntax or crop syntax

convert $strip[${width}x${iheight}+${i}+0] interim.tif

or

convert $strip -crop [${width}x${iheight}+${i}+0] +repage interim.tif

[hasso]

I have tried putting in echos and the resulting values all seem to make sense. This seems to be supported by the fact that on every loop a valid interim.tif is being produced (same dimensions), each containing the full sprocket.tif sub-image (i.e. I can see it, and it isn't 'cutoff' or anything). I'll try your suggestion of using different syntax to accomplish the same thing, but just can't figure this one out. Looked so simple...

these are the types of errors I'm getting:

first time thru loop:
865.918 (0.0132131) @ 91,404

second time thru loop:
8076.06 (0.123233) @ 0,0 compare: geometry does not contain image `interim.tif' @ warning/transform.c/CropImage/572.

[fmw42]

If you are not using results for anything, try replacing it with null: ( the colon is important). This just says not write any output image.

try replacing

-dissimilarity-threshold 1.0

with

-dissimilarity-threshold 100%

I will try to generate something of my own to loop over an image with subsections and see if I can reproduce your kind of error, when I get some time. Looking at your script, I do not see anything obvious, but I have not studied it in depth.

Perhaps one of the IM developers will see something more obvious or not so obvious that will get to the issue.

[fmw42]

I can confirm your problem with the following simple test in IM 6.7.5.7 Q16 Mac OSX Snow Leopard. It looks to me like a bug or I do not understand why the loop is failing.

Large image:


Small image:


#Cut out each quadrant and search that quadrant image for the question image.

sub0="100x100+0+0"
sub1="100x100+100+0"
sub2="100x100+0+100"
sub3="100x100+100+100"
for ((i=0; i<4; i++)); do
eval sub=\$sub$i
echo "i=$i; sub=$sub"
convert cyclops_question4.png[$sub] tmp.miff
display tmp.miff
compare -metric rmse -subimage-search -dissimilarity-threshold 100% tmp.miff question.gif null:
rm tmp.miff
done

i=0; sub=100x100+0+0
0 (0) @ 26,44
i=1; sub=100x100+100+0
7006.26 (0.106909) @ 0,0
compare: geometry does not contain image `tmp.miff' @ warning/transform.c/CropImage/572.
i=2; sub=100x100+0+100
7006.26 (0.106909) @ 0,0
compare: geometry does not contain image `tmp.miff' @ warning/transform.c/CropImage/572.
i=3; sub=100x100+100+100
7006.26 (0.106909) @ 0,0
compare: geometry does not contain image `tmp.miff' @ warning/transform.c/CropImage/572.


tmp.tiff gets displayed fine for each iteration, but compare seems not to do the right thing.

[hasso]

Thanks for doing the analysis and the confirmation of the issue. Much appreciated. Are there any other steps necessary to register this as a bug, or is it simply enough to leave in this forum "as is"?

In the meantime, I'll need to try to figure out a "workaround".

[fmw42]

In the meantime, I'll need to try to figure out a "workaround".

In the meantime, you can try to use my normcrosscorr script if you have FFTW in your delegates and want to recompile IM in HDRI mode. See the link to my web site for the script. Also see http://www.fmwconcepts.com/imagemagick/ ... mcrosscorr

Are there any other steps necessary to register this as a bug, or is it simply enough to leave in this forum "as is"?

We both think it is a bug. The IM developers monitor this forum closely, so they should see this and can use my tests above to verify.

So just leave it here with this comment.

[fmw42]

NO BUG. Compare does not like the virtual canvas left behind by the crop. So add +repage as per the following:


sub0="100x100+0+0"
sub1="100x100+100+0"
sub2="100x100+0+100"
sub3="100x100+100+100"
for ((i=0; i<4; i++)); do
eval sub=\$sub$i
echo "i=$i; sub=$sub"
convert cyclops_question4.png[$sub] +repage tmp.miff
compare -metric rmse -subimage-search -dissimilarity-threshold 100% tmp.miff question.gif null:
rm tmp.miff
done

i=0; sub=100x100+0+0
0 (0) @ 26,44
i=1; sub=100x100+100+0
0 (0) @ 26,44
i=2; sub=100x100+0+100
0 (0) @ 26,44
i=3; sub=100x100+100+100
0 (0) @ 26,44

+repage is needed for tif, png, gif, miff --- any format that supports virtual canvas information.

[anthony]

So the bug is really to making compare: understand, or ignore, the virtual canvas!

[hasso]

Well, that was easy . Working like a charm now. The script is churning through the images as I type. Thanks for your help.