Page 1 of 1

### composite, parenthesis, -gravity problems

Posted: 2017-06-29T09:03:21-07:00
The script below places pre-prepared rectangles containing numbers 27-0
along a line (scale50.png) of given length at approximately(1.) equal
intervals. It works OK.

###################### script ####################################

imgconvert -size 727x20 xc:'white' scale50.png

while [ i -le 27 ]
do

j=\$(echo "(\$i*26.8 + 1.5)/1" | bc) # (...)/1 for nearest integer
n='27-i'
imgconvert scale50.png rect"\$n".png -geometry +"\$j"+3 -composite scale50.png
i=i+1
done
################################################################

However, to avoid making separate rectangles I tried replacing
rect"\$n".png above with:

\( -size 20x14 xc:'none' \
-fill 'black' -font Arial-Bold -pointsize 13 \
-gravity center -annotate 0 "\$n" -trim \) \

It almost worked, except the first number was positioned in
the centre of the target line (scale50.png), the other numbers
followed on at equal distances from that centre.

It seems the gravity option centered the first number relative
to the line and the geometry was ignored, but only for the first
cycle.

Note 1. Many attempts have been made to position the numbers close
to being equidistant.

Relying on '-gravity center' is not consistent, numbers can be
1 or 2, sometimes more pixels off-center which accumulates over
a longish list (eg if appending boxes containing successive `centered' numbers).

An attempt, not yet achieved, would be to trim the numbers, find
their widths and position them using calculations based on their (hopefully),
well defined widths.

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-29T11:05:36-07:00
"-gravity" is used by "-annotate" but also by "-composite". In your first example gravity is the default. When you use "-gravity center -annotate", you can insert "+gravity" before "-composite" to restore the default.

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-29T13:54:59-07:00
djd wrote: 2017-06-29T09:03:21-07:00Note 1. Many attempts have been made to position the numbers close to being equidistant.

Relying on '-gravity center' is not consistent, numbers can be 1 or 2, sometimes more pixels off-center which accumulates over a longish list (eg if appending boxes containing successive `centered' numbers).

An attempt, not yet achieved, would be to trim the numbers, find their widths and position them using calculations based on their (hopefully), well defined widths.
I'm not quite sure of the exact result you're trying to achieve, but it looks like there are several ways to aproach your task. If you want the 27 numbers to be equally spaced, center to center, you can make the 27 boxes, annotate each with a number, and "+append" them into a horizontal row with something like this...

Code: Select all

``````convert scale50.png -fill black -font arial-bold -pointsize 13 -gravity center \
\( -size 20x14 xc:none -duplicate 26 -annotate 0 "%[fx:t+1]" +append \) -composite output.png
``````

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-30T06:39:12-07:00
# Draw a scale with tick marks given the length and number of divisions

Thanks Snibgo for mentioning the +gravity. I have always found gravity somewhat
mysterious and +gravity is not mentioned in the IM command options web pages,
but I guess I should have thought of it as a possible cure.

Yes GeeMack I am trying to set the centers of a list of numbers equidistant, as on a ruler.

Thanks for the fx looping construct, gets rid of more `foreign' shell processing.

I had tried the -append approach, but inspecting some result I thought the
locations were a little `off' due to `-gravity center' not actually centering
some of the digits - at least not centering them `visually'. I think the
figure `1' is an example, but there are others.

With the -append approach, the length of the current box holding the digits
needs to be adjusted a little as the append progresses, so that the total
current length of the append in an integer number of pixels is within half a
pixel of the `true' fractional pixel length at that stage.

With the example below, the nominal length of each box is 26.93 pixels, almost
an integer, so there is infrequent switches from a 27 pixel box to a 26 pixel
box. However with a ruler length L=716 and 27 divisions, the nominal length of
a box is 26.52, so the length of almost every second box is adjusted.

Having another look at the result from the example below, it is Ok.

However, although I can see how to perform the calculations using fx, I
cannot discover if/how they can be applied to the the current length "\$j" of
the box "\$j". That would be good to know.

####################### Script with graduation marks ###################

typeset -i i=0 j k=0 n L=727 d=27 id=50

s=\$(echo "\$L/\$d" | bc -l) # bc -l for decimal result

imgconvert -size 0x28 xc:white scale"\$id".png # Initialise image

while [ i -le d ]
do

n='d-i'
j=\$(echo "((\$i+1)*\$s - \$k + 0.5)/1" | bc) # (...)/1 for nearest integer
k='j+k' # Total length of append

imgconvert scale"\$id".png \
\( -size "\$j"x14 xc:'white' \
-font Arial-Black -pointsize 18 -fill 'black' \
-gravity center -annotate 0 "|" \
\( -size "\$j"x14 xc:'white' \
-annotate 0 "\$n" \) \
-append \) \
+append scale"\$id".png
i=i+1
done

imgconvert scale"\$id".png -trim scale"\$id".png # Remove superfluous ends

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-30T07:29:28-07:00
djd wrote:... +gravity is not mentioned in the IM command options web pages ...
So it isn't. I've posted a documentation bug report. Thanks.

Most, if not all, settings have "+" option to set the default value. When two commands work fine, but not when they are combined into a single command, the problem is often a setting in the first half being "accidentally" used in the second half.

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-30T10:43:54-07:00
djd wrote: 2017-06-30T06:39:12-07:00# Draw a scale with tick marks given the length and number of divisions

[...]

However, although I can see how to perform the calculations using fx, I cannot discover if/how they can be applied to the the current length "\$j" of the box "\$j". That would be good to know.
Unless I'm missing something, it still seems to me almost the entire process can be done as an ImageMagick command.

Code: Select all

``````convert -set option:distort:viewport 727x30 -size 30x30 xc:none -duplicate 26 \
-gravity center -pointsize 20 -annotate +0+0 "%[fx:t+1]" -trim +repage -virtual-pixel none \
-distort affine "0,0 %[fx:(t*727/n)+(((727/n)-(s.w))/2)],8" -background white -flatten output.png
``````
This starts by setting the viewport size of your desired output image.

Then it creates 27 boxes, sized 30x30, annotates them with numbers in sequence 1 through 27, and trims and repages them all.

The real work is done with "-distort affine ..." where it puts each number into a viewport sized box of 727x30, starting at the left side and moving each number N/27 to the right by fractions. The FX calculation there even adjusts each number to be horizontally centered in its 727/27 space.

Finish with "-flatten" on a white background.

### Re: composite, parenthesis, -gravity problems

Posted: 2017-06-30T19:28:16-07:00
Thanks GeeMack - that is brilliant!
There is no doubt IM is a powerfull and intriguing bunch of software, but that implies a casual user such as myself will never completely master it.

Thanks again.