The eye dropper feature of the touching color block picks up the color of the top sprite without the ghost effect. And yet it reports "false" when the called. (Not very consistent.)
Is there any way to detect if a sprite is touching the unghosted color of the pixel of the top sprite?
I think this is a trap 
Now seriously. There are so many things to consider here. I write down some, although we would need a bit more time and clarity to tackle this subject in depth.
First, pipette is not always picking up the color of the top sprite without the ghost effect. Test it multiple times and see (and then another issue 
) But this is not the main problem here.
TouchingColor block does not consider color.a and then, transparency does not matter here. And it is not a bug. Because "touching color" is watching the (only one) color there, not the "different colors of the different layers". So the "color" touched has not transparency (I can't see through the browser layer!)
About "paste on" block. I would think this would be the good solution (pasting on, watching pixels ("if (pixels of costume) contains (rgba list)"), and returning to current costume) but I see it's not the solution. Because "paste on" don't apply effects. Maybe (@jens ?) we can change this behavior (I like "pasting on" uses current costume with their effects).
(... and here, many thoughts about first class colors and others....)
But a practical "solution" would be playing with "(rgba) at (sprite)" block. A problem is that it uses (reports) only the color at the sprite center (as a point). But in the other hand, it reports the color of the object below. It also depends on layer order, but you will get its (from the object below) transparency.
If a "point detection" is a problem, you can play like a "robot with different color sensors", with different small sprites nested to the main, and watching if (and where) the color is touched.
Joan
Thanks. I'll explore some of these ideas.
Regarding the bug, the bug is that the eye dropper tool associated with the touching color block picks up the unghosted color. So it isn't consistent with how the block itself works. You gave good arguments for how the block behaves so shouldn't the eye dropper work that way too?
I'm playing with this segmentation model that can change a costume like this:
I'd like a make a simple game where a sprite behaves differently depending upon whether it touches someone's head instead of their hands. I can get it to work without ghosting so the person becomes a collage of solid colors but would like to use ghosting.
you know, you can also get the color at any arbitrary point like this:
Thanks! Looks like that should work.
BUT the documentation for that block says it shows the "visible color at that location". In the following that would not be pure red as it shows. It seems it does what I want - the unghosted color of the top sprite at that location.
Also what does the "a" in r-g-b-a mean in this context? A costume or a pen can be semi-transparent but a pixel?
Transparency
He knows that. He's asking, what does it mean for the entire collection of layers at that pixel to be transparent? There's nothing beneath it to show through.
And I think the answer is that you'll always see 255 (opaque) in that slot from rgba-at.
Hi Ken @toontalk,
Sorry, I had to answer you... but too many things on my table 
Yes, about my answer, there was a mistake (or almost an unclear aspect) about "(r-g-b-a) at (myself)" block.
Joan
Interesting. Currently my project relies upon the current behaviour - I need to know the color of the top sprite at a location ignoring what colors are underneath even if the top sprite is ghosted. Might this change in the future?
I guess a related question is whether the color of the top sprite's alpha value should depend upon its ghosting. If this changed from the current behaviour I could easily just compare the r-g-b and ignore the alpha.
Hi Ken, the current behavior is not about to be changed, we designed it specifically so such activities will keep working (we're having a bunch or these, some of my own favorites, actually). And it's the technically right thing to report the actual color of the current image of a sprite, disregarding global alpha (i.e. the value of its current ghost effect setting). Also, it's the way sprites work: Because collision detection depends of fully transparent pixels being ignored regardless of whichever other values might be in their r-g-b channels. So, whenever you sense a pixel that means that it's alpha channel must be > 0.
Very good to hear. I think the 'help' for this block is misleading (despite the mention of "frontmost"):
Also it doesn't mention r-g-b-a
ReportTouchingColor works with all sprite images stamped on stage, with effective colors calculated by canvas itself. Pipette gets RGB only color from Sprite or Stage beneath the mouse pointer.
For ghost=100 there are no pixels drawn on stage so no touching at all.
Maybe
warp{
ghost=0;
wait(0);
check color;
ghost=100
}
do the trick...
hey, I found out that the paste on block pastes on the sprite even when it's hidden