Rounded Corners for images?

Dar Scott 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  
> not
> 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  
created (conceptually).

>> 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  
characteristic:

     x <blendSrcOver> transparent = x.

That is, in math jargon, transparent is the right identity for  
<blendSrcOver>.

>
> 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  
apply.

>   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  
properties.

(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

--
**************************************
Dar Scott
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
Skype:              ask

http://www.swcp.com/dsc
dsc at swcp.com

Computer programming
**************************************





More information about the Use-livecode mailing list