Rounded Corners for images?
dsc at swcp.com
Tue Oct 10 16:09:23 EDT 2006
On Oct 10, 2006, at 12:32 PM, David Bovill wrote:
> Actually this is very useful. I won"t pretend I understand it all
> but at
> least I've got a start.
Yeah, me too!
> On 10/10/06, Dar Scott <dsc at swcp.com> wrote:
>> This will depend on the layers. And remember to set the ink of the
>> group to something other than srcCopy.
> A question here (have read below) is whether non-ink virgin
> controls so to
> speak as part of an "ink group" effect the behaviour in any way -
> that is
> say there are invisible or "out-of-the way". I would like to kow
> this so I
> can rule this cause out when trying to figure out why my group does
> behave as the simpler group did.
Naw, they all interact. They build up back to front. You might be
doing something with a and b but if c, d and e are in the group, they
will play. The group composition would be (a*b*c*d*e*group), where
group is the image of the background of the group if it is opaque.
So a will ink onto (b*c*d*e*group) is its blend & ink. Also the
entire thing will ink onto what's behind the group based on the
groups blend and ink.
To make it clear it doesn't just work on the object behind it, it
works on all the objects behind it in that group. That is, by the
time the ink for a is applied, (b*c*d*e*group) has already been
>> acts as though adding
>> parentheses in image math.
> OK. So imagine an "ink group" as if it were all by itself and
> ungrouped on a
> card - then sort of burn it down into an image to figure out how it
> interacts with other "ink groups". However when you"ve done the
> "maths" what
> "ink would this "ink group" have?
It has the ink of the group itself.
That is a good point. Each time we think of x that is some control
even a group, there is an x* that operates on something. So even
though the P-D operators are binary functions when combined with the
left parameter they can become unary operators.
> In other words: what sort of beast is (a*b)?
This will act as though it is an image, it is layered in with other
objects using the ink and blend for the group.
We can say (a*b) as a shortcut, but it is really (a*b*group) where
group depends on properties such as opaque, border and so on. It
might be completely transparent. In (a*b*group) the first * is the
ink/blend of 'a' and the second * is the ink/blend of 'b'. The 3rd *
in (a*b*group)*rest is the ink/blend of the group.
This is cool because one can work with the blend and ink of the group
without knowing what is in it. (Except the alpha channel must be
maintained, so srcCopy as an ink might be off limits.)
If the ink for 'b' is blendSrcOver and the group contribution is
transparent, then (a*b*group) = (a*b). This is because of this
x <blendSrcOver> transparent = x.
That is, in math jargon, transparent is the right identity for
> If I start with a group with no inks - lets call this (a-b) - where
> in my
> case a is an image, b is a black graphic and they form a group.
You always have an ink. The default ink is usually srcCopy.
> Or am I o
> the wrong path here?
> 1. Now if b has the ink blendSrcOver how do I represent the ink
Ah, the earlier answer should help. Expanding (a*b*group) to show
what ink is what:
(a * b <blendSrcOver> group)
If group=transparent, then this is (a * b). From the right-identity
characteristic noted above.
All of this ink algebra applies only when an ancestor has an alpha
channel. So this does not apply if you leave the group without one
and the card or other ancestor does not have one. I have noticed
that new groups tend to have the ink of a recently created (deleted?)
group, so watch that groups have the ink you expect. So, at this
stage if the group still has an ink of srcCopy, then this might not
> 2. Then I add blendSrcOver to the group
(a * b <blendSrcOver> group) <blendSrcOver> rest
> 3. The I add blendSrcOver to the image a
(a <blendSrcOver> b <blendSrcOver> group) <blendSrcOver> rest
If group=transparent then it is this:
(a <blendSrcOver> b) <blendSrcOver> rest
I think <blendSrcOver> is associative and the parentheses can be
removed. If so, then this is the same as this:
a <blendSrcOver> b <blendSrcOver> rest
That is, as if there was no group.
However, that does not apply if the ink for a is blendSrcAtop. In
that case you need to keep the parentheses:
(a <blendSrcAtop> b) <blendSrcOver> rest
>> It is like gluing pictures and
>> cards onto a collage. You work from back to front using the right
>> kind of glue for each layer. The group means that you glue some
>> things together, put them in a clear envelope and then using the
>> right kind of glue for the group glue that to your collage.
> Nice way of thiking about it. If you don"t mind I'll try and
> synthesize you
> comments here and put them on the wiki.
Go for it. In some cases, the glue burns holes in your pictures, but
that might be stretching beyond the limits of this analogy.
Note that I have mentioned algebraic properties several times here.
Those properties are not quite the same with the clip-to-self (bug)
versions of the operators. Those might have other interesting
(Even though I don't like the clip-to-self variation as might be
inferred from the scattered bug parenthetical comments, I'm sure I
can adapt if the powers deem that they stay.)
Dar Scott Consulting and Dar's Lab
8637 Horacio Place NE
Albuquerque, NM 87111
Lab, office, home: +1 505 299 9497
Fax: call above first
dsc at swcp.com
More information about the Use-livecode