Legacy ImageMagick Discussions Archive

I don't wish to come across as too pedantic here. After all, you don't have to make any of these hoped-for changes.

Does '-deskew threshold' take an optional %?

The text uses both 'gray-scale' and 'grayscale'.

Under '-distort method arguments', the text says '-define distort:scale={scale_factor}'. Is it correct to assume the {} can be dropped from that line?

The text for '-displace horizontal-scalexvertical-scale' mentions % and !, but neither of the 2 summary lines does.

For '-dissolve src_percent[xdst_percent]', the text reads as though % is not accepted as part of the input. Is that correct?

For '-modulate brightness[,saturation,hue]', the same comment applies as for -dissolve.

Under '-normalize', 'came amount' should read 'same amount'.

For '-sepia-tone threshold', is the % optional?

For '-sigmoidal-contrast contrastxmid-point', also, is the % optional?

Likewise for '-solarize threshold'?

For each of the following, it'd be nice to see another summary line using the '+' prefix, since '+' is discussed in the text (although there may be too many here to bother with):

-adjoin
-antialias
-append
-channel type
-clip
-clip-mask
-clip-path id
-clone index(s)
-compress type
-contrast
etc, etc. Just scan for + to see the rest.

Fixed most of your suggestions, update available sometime tomorrow. Thanks. Note, you can issue a GIT pull request on the documentation and make the fixes yourself.

The use of gray-scale should only be there for descriptions. I expect there may be places that use grayscale and gray-scale for descriptions. The function -grayscale should not have and hyphen separating the two words. If you see any, let us know.

The only function that I know that requires a % symbol is the -deskew value. It does not seem to work without it. I believe that -sigmoidal-contrast typically uses the percent. If it is left off, then it uses raw graylevel values in Q range of the compile. Likewise -solarize and -sepia-tone. It is explained for -sepia-tone in the description.

% are optional for only those functions that refer to grayscale value, which can be either raw values (in the Q range of the compile) or percent values. If the latter, the % is needed to so indicate that. These are functions such as -level, -contrast-stretch, -normalize, -sigmoidal-contrast, -solarize, -sepia-tone, etc). Note that -colorize will use a value between 0 and 100 with or without the %.

-dissolve and -modulate do not expect % symbols and may fail if they are included. -dissolve and -blend are old syntax used with composite. The newer syntax uses convert ... -compose dissolve/blend without the minus. In either case, they are percent concepts for mixing images and thus do not need %. They may still work with them, but I have not tested that.

Many of the +formats simply turn off the -formats (antialias, clip, etc. I am unaware of what +contrast might do. Most of the + formats are discussed in the - format section and so do not need repeating. I would hope that any + forms have some description. If not, let us know. But I doubt this will be changed to include a separate description for the +forms.

If Magick tells me to work on the options page for the spelling and bracket/braces inconsistency, I will try to clarify as many of the above as I can.

EDIT: I see he just posted a note that he fixed most of these. So I will hold off and see what changes are made and what is missing.

Let us know if you find any other inconsistencies or typos or errors.

Thanx for the quick response.

Many years (decades?) ago I was allowed to log on to IM and made some doc changes, but they were obliterated a couple of versions later, so I've been deeply reluctant to make any since but I do appreciate the availability of it on github, since I use github myself (https://github.com/ronsavage?tab=repositories).

Re the table for '-ordered-dither threshold_map{,level...}', do I read it correctly that columns 1 and 3 only are valid inputs?

ronsavage wrote:Re the table for '-ordered-dither threshold_map{,level...}', do I read it correctly that columns 1 and 3 only are valid inputs?

As far as I know only column 1 is used. The other columns are descriptions as far as I understand. I do not know about the optional argument, level. I am not an expert on dithering and the only explanation I know is at http://www.imagemagick.org/Usage/quanti ... red-dither.

glennrp would probably be the one who can explain this best.

OK. Thanx.

I'll add: IM doesn't seem to have a function that can parse and execute what we might call a "single-image operation", such as: There is a function that will take all the "convert" arguments and execute them, but that needs input and output files.

snibgo: Does't IM 7 scripting do what you suggest. See viewtopic.php?f=1&t=28884

And a reminder, IMv7 will have a general availability release on April 30th of this year. Its currently in Beta.

I don't know if V7 has a function that we can call from software that does as I suggest. V6 doesn't seem to have such a function.

IM 7 has -script. See example at viewtopic.php?f=1&t=28884

Not sure it is exactly what you are asking about.

That's for the command-line interface. Perhaps V7 also provides a function that can takes strings like "-blur 0x0.5 -background White -extent 500x500" and apply them to an image.

If not the command line, what are you interested in?

I've written a Windows GUI (called "Swim") for IM. It's a standalone program, but also a process module so it can be run from inside a "convert" command, and operates like any other IM process on all the images in the list.

It operates on images in memory, and doesn't run other programs or do any file I/O so it is very fast with smooth updates to images when sliders are moved.

Currently, all Swim operations are hard-coded, calling IM at the ImageCore level. This works fine, but it could be more general-purpose if a function that I describe was available. It could be like ConvertImageCommand() but without the need to name input or output images.

This would simplify my life, and anyone who is writing high-level interface to IM.

Of course, I could write it myself, but it would be a maintenance nightmare keeping up with changes to IM.

EDIT: I should add: it might help the OP ronsavage who is "writing a Perl module which parses IM command lines" for users who prototype using "convert".