Of course looping through images, using one command per image is probably the easiest to implement.
One method of looping over a large number of images, as a 'image stream' without saving intermeditae images, was demonstrated in another similar discussion. However the images are streams using ASCII PPM file format.
viewtopic.php?f=2&t=18320&p=71150
and resulting in the script
http://www.imagemagick.org/Usage/script ... m_pipeline
But these methods require you to constantly start (fork) a separate process or command for each image. That is you would be starting a new process and initializing (setup) the core library once for each image, which can be in-efficent.
At this time you can only truely avoid forking a "convert" comamnd multiple times by using some other non-shell API, so that the library only is configured once. Then have it read, process, write and destory (remove from memory) each frame in turn.
In shell scripts you can minimise startup time by processing images using mogrify which reads and processes one of the given image file at a time. Mogrify works by cycling though the non-image command line options once for each image.
http://www.imagemagick.org/Usage/basics/#mogrify
That however is limited, it is hard to modify the arguments being used for each image (say for the credit string and its position). You also can not easily compose or merge two or more images onto each frame.
You can also read a small batch of images, say 10 to 50 frames (depending on memory) using convert, and a technique for using the input filename to set the output filename of each image. See "Using Convert Instead of Morgify"
http://www.imagemagick.org/Usage/basics ... fy_convert
Which may be useful for say a static credit on N frames, then a different credit for the next N frames and so on.
You can also generate a very long convert command that reads, processes, and writes (deleting from memory) one image at a time. This lets you use one command, but apply different operations for each image (say drawing scrolling credits, or adding a side animation that is common on modern movies).
For example
Code: Select all
convert \
... \
"frame_0053.png" -annotate +10+30 "Camera 1: John Doe" -write "new_0053.png" +delete \
"frame_0054.png" -annotate +10+27 "Camera 1: John Doe" -write "new_0054.png" +delete \
"frame_0055.png" -annotate +10+24 "Camera 1: John Doe" -write "new_0055.png" +delete \
... \
null:
At any one only one frame is in memory, but you only one one comment to process that batch of images. The technqiue also allows you to be free to do ANYTHING you like.
For example you can have a extra image in memory with each frame (in turn). Such as one very long static credit image that you can then overlay on your smaller video frame, at different offsets so as to generate a long sequence of scrolling text over the top of your video.
The limitation with this is at the length of the command line! Not all shells will having a command line longer than one to two thousand characters (bash seems to hand long command lines though).
But it is most versatile and efficient technique, as you don't have to fork, settup, or re-read secondary images over and over.
This brings me to -- The Future.
I have plans to re-write the CLI interface in IM version 7, so that IM can read image processing options from a file instead of just the command line. this will allow you to 'script' the image processing.
Further I plan to be very strict in how it works so you can even pipeline commands into the image processing command, which means you can run a 'image processor' in the background, and have the wrapping script (shell or otherwise) feed it operations to perform and even receive feedback on those operations, as they are done (or even do other things while they are being done). A technique known as 'co-processing' (google for it).
You can think of it as the shell running and controlling a image processing 'daemon' which holds the images and process them according to the shell.
In this method. you have no command line limits, and only imagemagick one command needs to be run. The shell can even modify its actions based on feed back from the image processor.
In otherwords... scripted image processing with feedback.
For example: it could study the frames and change its annotation of the the image based on the frame contents. Imagemagick supplies the image processing, the wrapping script supplies the 'intelligence'.
Exciting times -- stay tuned!