No output using caption

[fmw42]

why do you have -rotate 0 in the command line. It is not needed and in fact, I believe doing any rotate before creating the text image may or may not be a problem. If you want to rotate the image, do it after you create the text image. If you are trying to slant the text, then use -annotate.
see http://www.imagemagick.org/Usage/text/ and in particular http://www.imagemagick.org/Usage/text/#annotate

Furthermore you have another rotate 0 later in your command and it does not have the minus sign before it (-rotate 0 not rotate 0).

Please explain why you have the -rotate in your command and what you are trying to do? Do you expect the text to be rotated before you create the image. If so, I don't believe that caption: is sensitive to any pre-rotation.

Also sizes cannot be fractional pixels (-size 39.9x should be -size 40x).

Also I don't think you can preprocess the image to do a -resample before creating the text, though IM may be forgiving about that also.

Also hex values properly should be enclosed in quotes. see http://www.imagemagick.org/script/color.php

Also your -pointsize is way too big for your -size 40x. That is likely causing your problem and IM does not know how to handle the contradiction gracefully. Or the otherway around, your -size 40x is too small for your pointsize. This works if you make your size at least 50. Note the order of the parameters, though the order of the font characteristics before the caption: is not critical. But for proper IM 6 syntax, I believe that the -density, -resample and -rotate should follow caption:. IM is pretty forgiving about most parameter ordering, but that may change under IM 7. (see http://www.imagemagick.org/Usage/basics/#cmdline)

This works:

convert -size 50x -background none -font Arial -pointsize 72 -fill "#000000" -gravity west caption:"A" -density 300 -resample 150 text.png

However, the pointsize is going to be reduced so as to fit the 50 width. It is just to narrow to support your character at 72 points.

If you want to rotate the image after creating the text image, then

convert -size 50x -background none -font Arial -pointsize 72 -fill "#000000" -gravity west caption:"A" -rotate X -density 300 -resample 150 text.png

Furthermore, if you have only one character (or it will fit in one line), you are better off using label: and no pointsize. Then the image will find the correct pointsize to maximize the space.

try this

convert -size 50x -background none -font Arial -fill "#000000" -gravity west label:"A" -density 300 -resample 150 text2.png

IM might be a bit more graceful about the situation, though you are asking it to do two different things that it cannot handle together. You can have one or the other.

I will leave your "hang" problem to the IM developers to sort out with you.

[fmw42]

I posted a bug report. see viewtopic.php?f=3&t=19502

[fmw42]

Please explain the -rotate 0 and if you expect a non-zero value, what result are you trying to achieve. I would still reorder the arguments as I have above, since later (IM 7) that may make a big difference. So using good syntax will give you a heads up later.

[fmw42]

If you are scripting in some form, then one way to avoid excess compute time if not quality changes is to avoid doing seemingly null operations in your command line as they are going to be processed anyway and not skipped. IM is not that smart as far as I know to automatically do nothing if it sees -rotate 0. For example:

if [ "$rotateparam" = 0 ]; then
rotation=""
else
rotation="-rotate $rotateparam"
fi
convert -size 50x -background none -font Arial -pointsize 72 -fill "#000000" -gravity west caption:"A" $rotation -density 300 -resample 150 text.png

This way if the rotation parameter is zero the command line will not include -rotation 0.

[anthony]

Note that rotation 0 should actually no-op quite well though I can't be certain without actually looking at the rotate code. The reason is that rotates of 90 degree units are handled in a very different way to rotates of other angles.

On the other hand distort SRT 0 would not as the image is slightly modified according to filter settings.

I can however say that -resize is definitely a no-op when no action is needed.


You are however right in that generally you are better off not including an operation, if the operation is not needed.

[fmw42]

Note that rotation 0 should actually no-op quite well though I can't be certain without actually looking at the rotate code. The reason is that rotates of 90 degree units are handled in a very different way to rotates of other angles.

On the other hand distort SRT 0 would not as the image is slightly modified according to filter settings.

I can however say that -resize is definitely a no-op when no action is needed.


You are however right in that generally you are better off not including an operation, if the operation is not needed.

Anthony,

Does not IM need to process the image even if no changes are made -- in the sense of reading the data and doing nothing, even if all is in memory? So some time is spent even if no "processing" is done. For a very large image, where data is passed back and forth to disk, this would be more substantial.

[anthony]

If a command truely no-ops (such as resize), then the image data should remain 'untainted' in which case IM may at the end just copy the image file (if a format change is not needed). however if rotate 0 does what I suspect, then it would make a clone of the image, then as per notmal CLI image process handling, delete the original image. that means a copy of the image meta-data will be made for the clone, but the untouched pixel data would just be transferred without any copy (as it was not modified). As such rotate 0 should be VERY fast even on very very large images.

Hmmm.. testing theory...
Baseline - create large image

Code: Select all

time convert -size 1000x2000 xc: null:
real    0m0.040s

using -rotate 90. internally this is don using flips and flops and not a triple shear but would require a new image created

Code: Select all

time convert -size 10000x10000 xc: -rotate 90 null:
real    0m0.120s

yeap looks like at least two image data passes were performed.
This could be a place to add a minor speed optimization, but it is still very fast.

using -rotate 180

Code: Select all

time convert -size 1000x2000 xc: -rotate 180 null:
real    0m0.075s

This also does internal flip/flop, but only the time for needed for one data pass

now the acid test -rotate 0

Code: Select all

time convert -size 1000x2000 xc: -rotate 0 null:
real    0m0.040s

yeap no time spend in moving pixel data around -- equivalent to a no-op (clone)

Is data tainted?

Code: Select all

convert rose: -verbose info: | grep Taint
  Tainted: False
convert rose: -rotate 0 -verbose info: | grep Taint
  Tainted: False

nope the image data is still marked as untainted! It is a true no-op (just a image clone).

NOTE -distort SRT 0 will always perform a data processing pass, and image filter. if EWA is enabled (default) then there will be a small amount of color mixing, but the default EWA filter "robidoux" was picked for the most minimal data mixing in the 'no-op distort'. Of course turning of EWA filter (using a "point" filter) so IM using interpolation will get perfect results.

[fmw42]

there are other seemingly no-op commands, but to be safe I have been using the no-op case trap to avoid any possibilities of changes.

-skew 0
-modulate 100,100,100
-sharpen 0
-blur 0x65000
-brightness-contrast 0,0
-level 0,100%

etc

But I have no idea which will really be no-op and so usually put in the trap to be safe. Perhaps overkill.

[anthony]

the -blur with 0x65535 is not a no-op it should be an error condition (it would technically generate an infinite kernel size)
on the other hand -blur {radius}x0 is a no-op (in early IMv6 that was an error as the math doesn't make sense).

Actually any -blur or -gaussian with a radius 1 is also a no-op, but in lower level morphology/convolve a un-normalised kernel of radius one (with a value of 1.0 or otherwise) can be useful, so you need to be careful where the no-op test is performed and in exactly what situation.

The others I don't know about but you are probably right. Check using a timing test and submit a bug report if it fails.
they are good additions for bot IM v6 and v7