Legacy ImageMagick Discussions Archive

FINAL EDIT:
Here is a complete list of all supported MSL commands (for conjure version 6.8.5-0 2013-04-23 Q8 on a windows system)
http://www.imagemagick.org/script/conjure.php#msl

______________________________________________________________________________________________________

Hi folx!

I am searching for a good docu for the Magick Scripting Language.
Is there any more info available exept of http://www.imagemagick.org/script/conjure.php?

Since now I guessed the commands by trial and error - sometimes successful.

But the biggest problem is to know if a command doesn't exist or if I do not use the correct command/parameters.

Thanks for reading.

(PS: Please excuse for repost this question in this forum but I did not get any responses in the Magick Scripting Language subforum.)

There is little documentation on MSL. The original intent was to support elements that matched methods in PerlMagick @ http://www.imagemagick.org/script/perl-magick.php. MSL was quite powerful when it was first released but since then with the various language wappers to ImageMagick (see http://www.imagemagick.org/script/api.php) that do a much better job, MSL has been a low priority such that we will fix bugs or add support for an element if there is a request for it.

Thanks for this info.
I like MSL pretty much! For me it's better to understand than convert commands.

So I read between the lines that there is only a subset of commands available with MSL?

Another thought:
How do I know if I a command is missing so that I can request for that element?

Check the PerlMagick documentation. If there is a method you want to use and it returns an exception in MSL and you need it-- let us know and we will add support in the next point release of ImageMagick (typically within a week or two).

I will do so!

Thanks or your infos!

magick wrote:There is little documentation on MSL. The original intent was to support elements that matched methods in PerlMagick @ http://www.imagemagick.org/script/perl-magick.php. MSL was quite powerful when it was first released but since then with the various language wappers to ImageMagick (see http://www.imagemagick.org/script/api.php) that do a much better job, MSL has been a low priority such that we will fix bugs or add support for an element if there is a request for it.

IMv7 is allowing you to place command line options in script files (will have argments too but not yet)
This will likely replace MSL as a IM scripting language.

The design is purely 'do it as you see it' which means scripting options can be set to the IM "magick" command and acted on immediatally. That means scripts can run a background (co-process) "magick" command and order it to do things and get 'answers' to queries to decide the next step.

Co-processing is a powerful technique that is often used in PHP, C, Perl, and to some extent Shell Scripts.

This aspect is all in development, though progress (slow) is being made.

Thanks for your answer!

If I understand it right then the script file will have the same - sometimes hard to read - commands like the command line.

I think the BIG advantage of MSL is it's easyness to understand (like HTML).

For single param commands it's almost easy to read:
e.g.

Code: Select all

-crop 100x100+10+10
vs.
<crop geometry="100x100+10+10" />

But with more than one param MSL is much easier to read because a command is bundled in a whole tag.
And you don't have to care about the order.
e.g.

Code: Select all

image -compose blend -define compose:args=60,40 -composite
vs.
<composite image="..." compose="blend" blend="60x40" />

So I would prefer to keep MSL.

I think if MSL would support more commands and there would be a good docu, that would be a good choice for people who are familiar with HTML.
In the MSL-Forum some people have asked for a docu.

Generally is a command is missing, request it and typically it is added quickly.

But of course that means it is only as up-to-date as people using it.

Similar things happen for "montage", whcih also often 'misses' a command that 'convert' has.

The problem with MSL, and many other fixed API languages, is that often there are lots of settings that can effect a specific operation.

Rant mode enabled -- sorry I got carried away...

Take composite for example, it is effected by (just of the top of my head, but I believe it is complete)...

compose - what type of composition
geometry - offset of overlay image to destination image
gravity - changes from where on the destination image the geometry offset is calculated
Future: add justification or alignment - to say what part of the overlay image the offset applies to. This is currently linked to gravity at the moment, and without it limits image placement.
compose:outside-overlay - a per-image artifact 'define' to determine how areas outside the compose area is effected (this equivalent to the SVG compose "clip-to-self" attribute, but inverted in sense)
channel - what channels in an image are updated in mathematical compostion (if not the default)
alpha blending switch - enable/disable SVG alpha blending, or individual channel math (built into channel, but likely to be different in IMv7)
write mask - three image blended composition - actually a seperate 'image properity
in IMv7 we also have a read mask though for normal composition it is equivalent to write mask, but for blur mapping, it can have a major effect.
compose:args - a define giving the extra arguments needed for blend, dissolve, watermark, and mathematics compose methods.
fuzz factor - used by "change_mask" composition (for GIF animation frame optimization)
Future: I would like to add virtual pixel to allow overlay tiling. That is tile the overlay image (according to the VP setting) so it always covers the whole destination image. The enable-disable would be part of the "compose:outside-overlay" to define how compose handles areas outside the overlay area.

Now would you expect ALL these settings to be included as part of the <composite...> MSL action?

It isn't just that operator either. All these settings (plus some color settings) is also used by operators that use composition as part of there defination... For example: -flatten, -mosaic, -layers merged, -layers composite, -border, -frame, and -extent.

And believe it or not Text to Image handling can be even worse with reages to the number of settings that effect its operation, and is also growing with time. Not just for the text aspect itself, but also for the 'drawing' aspects of the text rendering.

There is also a similar though relativity separate set associated with image drawing too, though it has its own 'language' (MVG) to handle that aspect.

Basically it is impossible to put EVERY setting into every operator. It is better to be ably to set most things globally (or on a per-image bases) to keep the general operation call simpler.

MSL is one way, Command line is another. Command line is actively being updated and used, MSL is not.

Because of this, even the PHP 'imagick' interface is no longer updating, and as such PHP programmers are typically doing command line calls for most image processing need.

That is why I want to get 'pipelined operations' and co-processing options added. It expands the activally updating CLI interface to allow eben better usage of the Magick Core Library, without needing to learn a API interface that seems to always be well behind the 'bleeding edge'.

Thanks for your explanation.

Now would you expect ALL these settings to be included as part of the <composite...> MSL action?

Well that's a good point. If you follow the xml rules then this has to be typically part of the composite action.

Code: Select all

<composite geometry="..." gravity="..." justification="..." outsideoverlay="..." etc.>

With all paramters it looks more and more complicated, I agree.
On the other side: also in HTML exists many tags with a full set of optional parameters.

But nevertheless: I can understand that not all APIs can be updatet just in time (that would be a fulltime job for many people).

Personally I will tend to use the command line for the complex operations.
MSL was a good introduction to ImageMagick as well.

Legacy ImageMagick Discussions Archive

[SOLVED] Is there a good MSL docu available?

[SOLVED] Is there a good MSL docu available?

Re: Is there a good MSL docu available?

Re: Is there a good MSL docu available?

Re: Is there a good MSL docu available?

Re: [SOLVED] Is there a good MSL docu available?

Re: Is there a good MSL docu available?

Re: [SOLVED] Is there a good MSL docu available?

Re: [SOLVED] Is there a good MSL docu available?

Re: [SOLVED] Is there a good MSL docu available?