I looked at this as part of reading images MagickReadImage() , which also added images to the wand in the same way.

Use MagickSetFirstIterator(), to insert new images before all the current images in the wand, MagickSetLastIterator() to append add to the end, MagickSetImageIndex() to place images just after the given index.

This is actually much like using ( ... ) in the Shell API, except you can only append images to the end of the list.

thanks for your investigation.
the first MagickSetLastIterator($resource); has no effekt to the result
infront of the second MagickAddImage(); it works. i can set the position with MagickSetLastIterator($resource);

so i can get only "$resource - $tmpres1 - $tmpres2" or "$resource - $tmpres2 - $tmpres1" but not "$tmpres1 - $resource - $tmpres2"

Possibly. Their was some weirdness I noted when I looked though the code for the first time, December last year. Yes it was not too long ago. I was doing so as part of preparation for IM v7 Shell API additions, which is why I knew the answer.

ASIDE: I wanted to more closely link shell option handling with Magick wand handling. I hope to improve some parts of MagickWand API in the process of adding 'scripting' and 'pipelining' interface. EG: Allow co-processing programming techniques, which should work well with PHP as well as Shell script. Work on that is still in progress, and I'm sort of got it working.

i setup a new server for testing and used the latest ImageMagick-6.7.5-6 (i see there is a new ImageMagick-6.7.5-7 out right now) and MagickWandForPHP-1.0.8

i can work around with a new Wand and put the Images with MagickAddImage($resource2,$tmpres1); MagickAddImage($resource2,$resource); MagickAddImage($resource2,$tmpres2); in correct order but i think this will take a more memory normaly needed!? Especially if $resource is a "big" image.

shell option work fine but is to slow becouse there are some more imageprocessing with the resulting image as far as i tested until now.

That is what IMv7 co-processing is about. You run the image command in background, and while it holds the files, you send it processing commands and queries to work out what you want to do. basically a way to avoid temporary files or multiple commands. But this is in development: scripting done, error handling and scripting options still to be done.

However this does not help with you current problem with Imv6.

Okay you are using the latest IMv6,
But add image with 'lastinteration' set while only one image is present prepends rather than appends. Is that right?

thanks for your testing antony!
in you example you working with a new wand there you past alle parts. in this way i also got it working.

i was afraid about memory consuming becouse my application need to handle parallel big images.
so you have a copy of the original wand in memory and i hoped to work without the copy and past the clone direct into the original wand.

Note that wands do not actually pass or copy images to each other, only image meta-data. The actual image data is cached and shared until such time as the data is modified.. That is what a 'image clone' is. So if you don't keep a clone of the original you will not duplicate the data.

Some operators will create a new image, rather than directly modify the old image. Typically this happens if the image is resized, or has 'area effects' such that it needs to preserve the original information, but the wand calls should delete the original image immediately, unless the call actually creates a new wand. Basicaly so as to let the user decide if the original is still wanted (rare). For example MagickImageAppend() creates a new wand, but see Cavat in the MagickWand Example above.

WARNING: about memory use: resize creates two new images (making three images at one point during its processing That is because it first does resize on one direction, then in the other direction. The first intermediary image is deleted internally in MagickCore resize function, the original image is deleted (replaced in wand) by MagickWand. The same goes for some multi-kernel morphology operations. These are typically the worse case with regards for image memory usage.

ASIDE: Distort resize is slower but does not need an internal intermediary image as it is a 1-pass 2-dimentional process.

I have been looking again at the MagickAddImage() (which also is what MagickReadImage() used to add images to the given wand).

I was right about the need to add MagickSetLastIterator() before each call to either of the above to get MagickWand to add images to a wand in the right place (at the end). Though from experience I think most people avoided the issue by just storing each image read in thier own separate wand.

This should not be the case and I have figured out the reason it stuffs up. I have fixed this coding in both IMv6 and IMv7 versions of MagickWand, along with updated function documentation, for the various functions involved.

Still if you are not certain of the state of a wand, adding a MagickSetLastIterator() before calling MagickAddImage() or MagickReadImage(), will always be a good idea.

As for C being faster than the PHP MagickWand. I am not supprised, as PHP probably adds another layer of error checking. But I would not have thought it would be that noticable for actual image processing, so the difference is probably in PHP initialisation (PHP is a very large interpreted language, C is compiled).