New pixelColor

Here is where the magnanimous folks that create externals post them (.zip archives only please).

New pixelColor

Postby codegreen » Thu Jul 21, 2016 3:05 pm

Here's an update to the pixelColor XFcn that works in current OS versions where the old hack for accessing the screen buffer used in previous releases fails.

Unlike the earlier releases this one expects the desired point or rectangle to be in global coordinates, and (as of now anyway) works only on the main display.

It requires OS X 10.6 or higher...

HTH,
-Mark

pixelColor.bundle.zip
(15.6 KiB) Downloaded 88 times
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby HairyHighlandCow » Sat Jul 23, 2016 12:51 am

Thanks Mark, that's really handy.
Externals, projects and software made with SC:
www.hairyhighlandcow.net/software/SC-projects.html
User avatar
HairyHighlandCow
 
Posts: 242
Joined: Sun Jul 06, 2008 1:45 pm
Location: London, UK

Re: New pixelColor

Postby codegreen » Sat Jul 23, 2016 2:57 pm

Here's an update with a bit more error checking, plus the ability to access secondary displays. That part was a bit hairy to implement (I had to puzzle out how to convert from global to display coordinates, since AFAICT there's no built-in API for this), so please let me know if you find any problems.

The one remaining significant constraint is that if you use the rectangle form, the specified rect may not span displays. I suppose this should be doable, but thinking about it made my head hurt...

-Mark

pixelColor.bundle 2.zip
(16.66 KiB) Downloaded 76 times
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby HairyHighlandCow » Sun Jul 24, 2016 2:36 pm

Thanks Mark, I will try this new version out on Monday.
Externals, projects and software made with SC:
www.hairyhighlandcow.net/software/SC-projects.html
User avatar
HairyHighlandCow
 
Posts: 242
Joined: Sun Jul 06, 2008 1:45 pm
Location: London, UK

Re: New pixelColor

Postby HairyHighlandCow » Tue Jul 26, 2016 7:08 am

Hi Mark, one quick question about the new external: the maximum value I can get for a red, green or blue channel is 65280. I was expecting it to be 65,536 for 16 bit colour– but there might be a reason I'm not aware of.
Thanks, Alec
Externals, projects and software made with SC:
www.hairyhighlandcow.net/software/SC-projects.html
User avatar
HairyHighlandCow
 
Posts: 242
Joined: Sun Jul 06, 2008 1:45 pm
Location: London, UK

Re: New pixelColor

Postby codegreen » Tue Jul 26, 2016 8:32 am

LOL! Uh yeah, here's the thing...

An RGBColor struct looks like this:

Code: Select all
struct RGBColor {
   unsigned short red;
   unsigned short green;
   unsigned short blue;
};

That is, each component color is stored as a 16 bit unsigned value.

However in the actual screen buffer, pixel colors are normally stored in some variant of ARGB, where each component is stored as a single byte (i.e., an 8 bit unsigned value).

That means the entries in cluts (which are tables of RGBColors) have twice as many bits of precision as the actual pixels. There's no universally 'correct' way to convert these 8-bit values to the 'equivalent' 16-bit version, 'cuz no matter what scheme you use you'll just end up stealing from Peter in one place to pay Paul somewhere else (try it...).

This is the reason that matching against clut entries is problematic -- unless the RGB values in the clut entry you started with are evenly divisible by 256, you'll never get an exact match. And often the 'nearest' match isn't the clut entry you applied to the target pixel either, because what you're really matching against is the clut color rounded down to the nearest integer multiple of 256.

I STRONGLY considered just returning the RGB version as numbers from 0 to 255 (which is what they actually are internally), but no matter HOW I give them to the caller there's always going to be some fudge factor involved in clut lookups, and at least this way scripters didn't need to puzzle out how to convert clut entries to 8 bit values (or vice-versa) only to discover that this didn't really help.

So yes, the values you get back this way are typically imprecise. You can obtain the actual 8 bit value either by passing 'hex' in param 2 (which returns colors in the familiar 'web color' format) or just by dividing by 256 if that helps. Otherwise we just have to accept that there's a squirm factor involved, and learn to account for it in whatever way is most useful for the purpose you're using this for.

I'm totally open to any suggestions people have for a less confusing way to handle this, because the choice of the current model was basically just a coin toss...

-Mark
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby HairyHighlandCow » Wed Jul 27, 2016 3:57 am

Hi Mark,
Thanks for the explanation. It doesn't really matter to me what the maximum number is, as long as I know what it is then I can convert the value down to 'value out of 100' or 'value out of 255'.
When it comes to mixing colours in a colour picker I have never seen a picker that has a field value more than 255, decimal places can always be employed if the user really needs a very precise set of values.
I'm not too keen on the approach taken by NSColor where values range between 0.0 and 1.0; personally I find it easier to read values out of 100, like 82 or 82.3, rather than 0.82 or 0.823.
All the best
Alec
Externals, projects and software made with SC:
www.hairyhighlandcow.net/software/SC-projects.html
User avatar
HairyHighlandCow
 
Posts: 242
Joined: Sun Jul 06, 2008 1:45 pm
Location: London, UK

Re: New pixelColor

Postby codegreen » Wed Jul 27, 2016 8:32 am

When it comes to mixing colours in a colour picker I have never seen a picker that has a field value more than 255, decimal places can always be employed if the user really needs a very precise set of values.

Yes, thankfully Apple long ago realized the folly of allowing users to directly enter full 16-bit resolution RGB values in the Toolbox color picker (which IIRC used to allow this back in the classic Mac OS).

However you can still get them into a clut in SuperCard via other means (such as importing cluts or images, or via the 'blend' option in SE's clut editor) and there are plenty of them in the original 'system' clut.

-Mark
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby gonetriadrr » Wed Jul 27, 2016 2:28 pm

HairyHighlandCow wrote:Hi Mark, one quick question about the new external: the maximum value I can get for a red, green or blue channel is 65280. I was expecting it to be 65,536 for 16 bit colour– but there might be a reason I'm not aware of.
Thanks, Alec


Hi Alec,
Since each 8 bit channel = 256 levels from 0 to 255
255 * 256 = 65280

That being said, in previous versions of pixelColor(), round-tripping sampled values div 256 proved to provide less than desirable color fidelity.
That is what i never understood.

DCS
gonetriadrr
 
Posts: 170
Joined: Fri Jan 08, 2010 6:50 pm

Re: New pixelColor

Postby codegreen » Wed Jul 27, 2016 3:52 pm

Right, as long as you start with colors whose RGB components are evenly divisible by 256, you should get back an exact match...

Otherwise (depending on which option you choose) you'll either get back the nearest mathematical match to the clut entry with its components rounded down to an even multiple of 256, or the nearest color optically (based on a formula that weights the component deltas according to the human eye's (significantly) different sensitivities to red, green, and blue).

Long story short, most of what humans see is in effect made up of shades of green, because our 'red' cones actually respond to a wider spectrum that includes portions of orange, yellow and green, and the 'blue' cones respond to both green and blue, while the 'green' cones respond only to a narrow slice of green.

As a result given equal intensities of pure red, green, and blue, the green appears to be roughly 60% brighter than the red, and almost five times brighter than the blue...

-Mark
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby gonetriadrr » Thu Jul 28, 2016 10:10 am

Mark,
Is the clut you speak of one tied to card or background, or a much larger one tied to the display device itself?
A device lookup table would explain the need for the additional precision.

I realize the toolbox calls give what they give, but, I question the value of return values which do not match the color spec of the source or don't reference a usable clut index.

DCS
gonetriadrr
 
Posts: 170
Joined: Fri Jan 08, 2010 6:50 pm

Re: New pixelColor

Postby codegreen » Thu Jul 28, 2016 12:39 pm

Is the clut you speak of one tied to card or background

Yes.

-Mark
codegreen
 
Posts: 1513
Joined: Mon Jul 14, 2008 11:03 pm

Re: New pixelColor

Postby gonetriadrr » Fri Jul 29, 2016 7:40 am

Thanks. Curiosity satisfied.

DCS
gonetriadrr
 
Posts: 170
Joined: Fri Jan 08, 2010 6:50 pm


Return to XCmds, XFcns, and XRtns

Who is online

Users browsing this forum: No registered users and 1 guest