Damien Dunlop on  wrote...
| 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.
|
No inconsistancy...
Again read
   IM examples, Basics, parenthesis.
     http://www.imagemagick.org/Usage/basics/#parenthesis

Parenthesis basically start a new image sequence, seperate to the
one outside parenthesis.   reading images or using -clone will
add images to this 'new' image sequence.

Any operators (other than -clone) inside the parenthesis will only see
the images in that image sequence, as as such only be applied to that
image sequence.

NOTE that settings will not be restricted to just the parenthesis unless
the special "-respect-parenthesis" option has been previously given.

When the 'close' parenthesis is given, any images present in the
in-parenthesis image sequence will then be appended to the end of the
external image sequence.

As such your original command....

    convert -size 1500x1500 xc:white \
            \( -size 1000x500 xc:lightblue -repage 0x0+0+950 \) \
            -stroke black -linewidth 5 \
            -draw 'line 1499,50 50,50' \
            -draw 'line 50,50 50,950' \
            -flatten A.gif

reads one image,  start new sequence, read one image into that new sequence
modify its virtual canvas offset, append onto the previous sequence.

As such when the \) was done, and the -draw operators applied.
IM has two images  in one image sequence.

BOTH images will be draw to, then the two images overlayed together!

There is no confusion in what IM is to do.


If you only want to draw to the second image, move the close parenthesis
to after the draw.

If you want to overlay the two images, THEN draw on them, move the
-flatten to before the -draw operators.


| I thought the paradigm of layers in order of application
| was conceptually useful and is similar to layered drawing systems.
|
It is.  But due to the historical nature, and the way people want unlayered
images to work, -draw and every other operator (except "-geometry" sic!)
is always applied to ALL images that are in the current image sequence.

The layers paradigm in IM only started to work usfully when parenthesis
was added so that each parenthesis can hold ALL the operators that is
ment to be applied to just ONE layer image.

Also with -clone -delete -swap and -insert operators, you can think of the
outside image sequence as the 'working' sequence, from which you can
pull out (-clone) images for later work.

You can see this type of handling in  Animation Image Modifications.

Animations in IM are basically the same as Layered Images, just with
time delays and optimisations for the overlaying.

You can see an example of extracting a layer (frame) and modifing each
individually in
  http://www.imagemagick.org/Usage/anim_mods/#frame_mod

PS: the "gif_anim_montage" script is also useful for displaying a
set of layered images too....

| 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 real problem then is that -draw only applys positions to the real
image, and not a virtual canvas positions.  This is a historical thing,
and probably somthing that will need to be fixed for IM v7.

See http://www.imagemagick.org/Usage/anim_mods/#draw
for an example of this problem, with animated images.

PS:  annotate  positions text relative to virtual 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:
|
Yes that is because settings, are just that settings.

I myself prefer to either make them global (at the start of the convert)
or set them just before the operator that is using them.

| 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 \
|      \( -size 150x150 xc:lightblue -repage 0x0+25+25 \) \
|         -flatten \
|         -draw 'line 0,100 200,100' \
|         -flatten D.gif
|
The extra -flatten did nothing!  Only one image was present and it had
no transparency to make the 'background' canvas show through.  Note that
the color of that canvas was not undefined (using -background), so was
set to 'white' from the image setting, defined by original generation
"xc:" )

As such it doesn't just feel redundant, it is redundant!


  Anthony Thyssen ( System Programmer )    <[EMAIL PROTECTED]>
 -----------------------------------------------------------------------------
     Do not meddle in the affairs of wizards;
                   they are subtle and quick to anger.
                                 -- Margret Wies & Tracy Hickman - "Elven Star"
 -----------------------------------------------------------------------------
     Anthony's Home is his Castle     http://www.cit.gu.edu.au/~anthony/
_______________________________________________
Magick-users mailing list
[email protected]
http://studio.imagemagick.org/mailman/listinfo/magick-users

Reply via email to