>Thanks again Fred and Anthony, > >> You were never clear what you were trying to achieve. that is what >> image to draw over. > >I think my understanding of the command sequence was >reasonably correct except for what I still think is an >`anomaly' or `inconsistency'. I could make it `work' >but I am more interested in the `why' on this one. > >When an operator such as -draw is placed inside parentheses, >it only affects the image(s) inside the parentheses. >However, I have discovered further, that if the operator is >outside the parentheses, (but following the parentheses), >it affects the image inside the parentheses in exactly the >same way as if it were inside the parentheses. So the >parentheses only protects what is outside from what is inside >the parentheses but not the inside from what is outside the >parentheses. Maybe there are some command sequences for which >this is very useful but it also lends itself to potential >ambiguity and mistakes.
Not that I am aware if you are doing the composite or flatten properly and the draw afterwards. If you do the flatten last, then yes the -draw will operate on every image or image parenthensis sequence prior to that as you have not converted all the images to one combined image, which at that time deletes the others from the processing sequence. In other words, any IM process will act on ever current image in the command line sequence prior to it. The only way to avoid that is 1) use () to restrict the operation or 2) use -delete to delete images from the command line sequence or 3) use flatten/composite, etc to convert prior images into one image, which automatically deletes the components from the command line sequence. > >I thought the paradigm of layers in order of application >was conceptually useful and is similar to layered drawing systems. > >However with drawing systems one can add any drawing object >(images, text, lines ..) to any layer and know that anything on >an upper layer will cover anything on a lower layer with all >coordinates being ultimately referenced to the edges of the canvas. >The final `merge' brings it all together - but still allowing >like IM, for intermediate merges if needed. With a drawing system, >an intermediate merge may be applied to simplify the process >by reducing the number of layers that need to be considered. > >Setting the four images produced by the commands below >side-by-side, to me, the third just looks out of place, and if >that was what you wanted, you would use two -draw operators, >one for the canvas and one for the overlay: > >a) To be confident of the result > >b) In a `real' situation, it is most unlikely that the >coordinates of an object within the canvas would exactly >match the `independent' coordinates of an object within >the overlay parentheses. > >Having to use an extra -flatten in the fourth command >below to achieve the result I really want feels `redundant', >`spurious', `anomalous' etc. > >convert -size 200x200 xc:white \ > -stroke black -strokewidth 5 \ > -draw 'line 0,100 200,100' \ > \( -size 150x150 xc:lightblue -repage 0x0+25+25 \) \ > -flatten A.gif should affect your white image > >convert -size 200x200 xc:white \ > -stroke black -strokewidth 5 \ > \( -size 150x150 xc:lightblue -repage 0x0+25+25 \ > -draw 'line 0,100 200,100' \) \ > -flatten B.gif should affect only the lightblue image > >convert -size 200x200 xc:white \ > -stroke black -strokewidth 5 \ > \( -size 150x150 xc:lightblue -repage 0x0+25+25 \) \ > -draw 'line 0,100 200,100' \ > -flatten C.gif Will affect all prior images: your white image and the result of the processing in the (...) > >convert -size 200x200 xc:white \ > -stroke black -strokewidth 5 \ > \( -size 150x150 xc:lightblue -repage 0x0+25+25 \) \ > -flatten \ > -draw 'line 0,100 200,100' \ > -flatten D.gif should only affect the result of the flatten as the first two images are then deleted from the command line. Fred _______________________________________________ Magick-users mailing list [email protected] http://studio.imagemagick.org/mailman/listinfo/magick-users
