[SOLVED] Testing mouseColor function

[capellan]

Bingo!
Changing the color profile to sRGB IEC61966-2.1
on Mac OSX is the solution in my own setup.

[[-hh]]

An Alpha channel has no color, it merely determines the degree to which a color may be influenced by colors beneath it.

Not everything in this world is top down. That depends on the blend mode.

In LC's color model ARGB is the first byte of a 32 bit colored-pixel the "alpha" component.
And LC often creates a separate alpha channel from images of resizequality "best".

I dare say: There is no bug with the mouseColor on Mac.

From the dict entry to resizeQuality:

"best" : uses a bicubic filter-i.e.interpolation is done using cubic approximation from near pixels.

So, what should the mouseColor report?

Mac (the real hardware, not the virtual) has a display method different from Linux and Windows. The OS does not necessarily display what LC wants.
There is no "exact color value" that the mousecolor could report, it has always to estimate. Because you don't really wish to fill a large rect with the (interpolated and) antialising gray of one of the black pixels beside it.

Changing the color profile to sRGB IEC61966-2.1 on Mac OSX is the solution in my own setup.

Did you test this also with pixels that are not fully opaque?

[FourthWorld]

So, what should the mouseColor report?

IMO the RGB value of the pixel from the composite display value. It's what I'm looking at. It seems less useful to try to account for all possible things in the various other buffers that were combined to ultimately produce the thing I'm looking at. I see a pixel on screen; it has a value; give me that value.

[[-hh]]

I see a pixel on screen; it has a value; give me that value.

That is the color of a fully opaque snapshot of size 1x1. You can have it by two lines of code.
I would like to have the color of the video buffer before the interpolation is applied, converted to a 32 bit ARGB color.

[FourthWorld]

I see a pixel on screen; it has a value; give me that value.

That is the color of a fully opaque snapshot of size 1x1. You can have it by two lines of code.

I'll take it. Hopefully the team will fix whatever is needed in the mouseColor function.

I would like to have the color of the video buffer before the interpolation is applied, converted to a 32 bit ARGB color.

Perhaps a new HowTheMouseColorIsDerived function is needed?

How can that be determined for objects outside of LC?

[capellan]

Changing the color profile to sRGB IEC61966-2.1 on Mac OSX is the solution in my own setup.

Did you test this also with pixels that are not fully opaque?

Yes, I imported a screenshot of a group of two vector graphics
(Bouba-Kiki.svg) and the transparent alpha channel changes
the color value of the image pixels in the borders, not in
the solid and flat areas of the transparent bitmap.

By the way, Why LC put a transparent border around the screenshots?

Al

screenshot_transparent_border.png

[[-hh]]

And how do you get the 4 byte pixel color (incl. the alpha value) from the 3 byte mouseColor?

[capellan]

The mousecolor does not provides the alpha channel value.
Just the pixel color under the cursor (or at least the
pixel color value that the OS report to the function).

[[-hh]]

Yes. I know.
But the alpha value A can change without changing the RGB.
But that is then a different color (4 byte pixel color).

[FourthWorld]

And how do you get the 4 byte pixel color (incl. the alpha value) from the 3 byte mouseColor?

I don't, since for anything outside of LC the alpha value would be a guess, and even within LC may not tell the whole story depending on other properties and antialiasing.

If I set the backColor of a graphic to gray50, the mouseColor reports 128,128,128.

If I then set the blendLevel of that graphic to 50 against a white card, the mouseColor then reports 191,191,191

So if a pixel is visibly 191,191,191, how do we know whether it was 128,128,128 with a 50% blend, or is actually a completely opaque pixel at 191,191,191? The observer cannot know what prior process may have been used to generate the color, only the resulting color.

Interactions between the assigned color, blendLevel, inks, graphic effects, or any other properties that affect rendering of that color no longer matter after the rendering process. What matters to the mouseColor fits what I'm looking for, the answer to the question: What is the RGB value of the pixel I'm looking at?

That's what I would expect. I would not expect it to add a fourth element which determines how the first three are transformed, only the result of the transformation.

[capellan]

This stack demonstrate that mousecolor function
calculates the color of visible pixel, not
the color of the top object.

In this stack with a yellow background,
a flat orange rectangle is made gradually
transparent using an alpha channel.

Screen Shot 2019-01-16 at 3.14.57 PM.png

Al

Flat_color_plus_Alpha_channel.livecode.zip

[[-hh]]

The computed transformation of four bytes to fully opaque three bytes is NOT reversible except you have full information about the pixels underneath the computed one.

[FourthWorld]

The computed transformation of four bytes to fully opaque three bytes is NOT reversible except you have full information about the pixels underneath the computed one.

True, the recipe for a cake is not a cake.

[[-hh]]

True, the recipe for a cake is not a cake.

Fine allegory. Also related to mouse (sadly cheese is not allowed...)

[FourthWorld]

It occurs to me that the mouseControl function could be used to obtain the "recipe, so to speak, for a pixel, at least within a LiveCode window.

Rather than return an RGB value, it could return an array with the relevant properties needed to discern how the object is rendered.

Or if the RGB is all that's needed, it could return the fill color of the object with its blendlevel, perhaps converted to hex and appended as the Alpha value.