How to determine whether colour is within a range of shades - autohotkey

I am not sure if this is possible as I have been looking for a few hours and cant find what I am looking for.
What i am doing is taking a color from a game panel which is semi translucent so the color which I am taking is always subtly changing. What is need is a way to check if it is +/- 10 or so shades of my desired color.
Something like
If color1 is +/-10 of 0x?
I have tried using the image search to do similar but that didn't work.
Any help would be greatly appreciated

In addition to Robert's answer, you can compare the colors mathematically.
First start by separating the Red, Green, and Blue values.
ToRGB(color) {
return { "r": (color >> 16) & 0xFF, "g": (color >> 8) & 0xFF, "b": color & 0xFF }
}
Then we need a function that compares the colors. Each of thee variables holds a number representing the difference in the two color values. For example if red is 255 in c1, and 200 in c2, rdiff will be 55. We use Abs so that we don't end up with -55 when c2 has a higher value. Then we make sure the difference for each of these is less than our vary.
Compare(c1, c2, vary=20) {
rdiff := Abs( c1.r - c2.r )
gdiff := Abs( c1.g - c2.g )
bdiff := Abs( c1.b - c2.b )
return rdiff <= vary && gdiff <= vary && bdiff <= vary
}
Here's how it can be used. We take some numbers, and then compare them to each other with the default vary of 20.
light_pink := ToRGB(0xFFAAFF)
darker_pink := ToRGB(0xFAACEF)
purple := ToRGB(0xAA00FF)
MsgBox % Compare(light_pink, dark_pink) ; True
MsgBox % Compare(light_pink, purple) ; False

I assume that your read about the limitations of PixelGetColor: Known limitations:
"A window that is partially transparent or that has one of its colors marked invisible (TransColor) typically yields colors for the window behind itself rather than its own.
PixelGetColor might not produce accurate results for certain applications. If this occurs, try specifying the word Alt or Slow in the last parameter."
When using ImageSearch, you can specify the Delta of the colours. Example:
ImageSearch, FoundX, FoundY, %SearchRangeLeft%, %SearchRangeTop%, %SearchRangeRight%, %SearchRangeBottom%, *20 %ImageFile%
Here the *20 indicates the variation in the range from 0 to 255 of my search colour. When searching for a pixel inside the image of 100,100,100 (RGB), it will match anything between 80,80,80 and 120,120,120. Hope this helps, but matching transparent colours is difficult and prone to errors. The smaller the image and search range the better (and faster)

Related

Is it possible to not use cardinality constraint to generate solution candidates in clingo?

I'm learning Answer Set Programming by solving the zebra puzzle.
I found some solution examples online.
But someone told me that I can solve the puzzle without using cardinality constraint macro to generate solution Candidates.
Like without using this
{ color(House, Color) : colors(Color) }= 1 :- houses(House).
{ color(House, Color) : houses(House) }= 1 :- colors(Color).
the goal is to generate different models with a unique combination of color(House, Color).
Is this possible without {atom: atom}=1:-atoms.?
You can do this with inequality constraints, and a weak constraint to generate the maximal number of combinations.
% Generate assignments of colors to houses.
{ color(House, Color) } :- houses(House), colors(Color).
% A house can only have one color.
:- color(House, Color_1), color(House, Color_2), houses(House),
colors(Color_1), colors(Color_2), Color_1 != Color_2.
% Each color can only be assigned to one house.
:- color(House_1, Color), color(House_2, Color), colors(Color),
houses(House_1), houses(House_2), House_1 != House_2.
% Generate a maximal number of combinations (i.e. all of them).
:~ color(House, Color), houses(House), colors(Color). [-1#0, House, Color]
Although, this needlessly more verbose than your current encoding.

my shader is ignoring my worldspace height

Im VERY new to shaders so bear with me. I have a mesh that I want to put a sand texture on below a worldspace position y of say 10 else it should be a grass texture. Apparantly it seems to be ignoring anything I put in and only selecting the grass texture. Something IS happening because my vert and tris count explodes with this function, compared to if I just return the same texture. I just dont see anything no matter what my sandStart value is
this is in my frag function:
if (input.positionWS.y < _SandStart) {
return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation;
} else {
return tex2D(_SandTex, input.uv) * mainLight.shadowAttenuation;
}
Is there also a way I can easily debug some of the values?
Please note that the OP figured out that their specific problem wasn't caused by the code in the question, but an error in their geometry function, this answer is only about the question "Is there a way to debug shader values" as this debugging method helped the OP find the problem
Debugging shader code can be quite a challenging task, depending on what it is you need to debug, and there are multiple approaches to it. Personally the approach I like best is using colours.
if we break it down there are three aspects in your code that could be faulty:
the value of input.positionWS.y
the if statement (input.positionWS.y < _SandStart)
Returning your texture return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation;
Lets walk down the list and test each individually.
checking if input.positionWS.y actually contains a value we expect it to contain. To do this we can set any of the RGB channels to its value, and just straight up returning that.
return float4(input.positionWS.y, 0, 0, 1);
Now if input.positionWS.y isn't a normalized value (a.k.a a value that ranges from 0 to 1) this is almost guaranteed to just return your texture as entirely red. To normalize it we divide the value by its max value, lets take max = 100 for the exmaple.
return float4(input.positionWS.y / 100, 0, 0, 1);
This should now make the texture full red at the top (where input.positionWS.y / 100 would be 1) and black at the bottom (where input.positionWS.y / 100 is zero), and a gradient from black to full red inbetween. (Note that since its a position in world space you may need to move the texture up/down to see the colour shift). If this doesn't happen, for example it always stays black or full red then your issue is most likely the input.positionWS.y.
The if statement. It could be that your statement (input.positionWS.y < _SandStart) always returns either true or false, meaning it'll never split. We can test this quite easily by commenting out the current return texture, and instead just return a flat colour like so:
if(input.positionWS.y < _SandStart)
{
return float4(1,0,0,1);
}
else
{
return float4(0,0,1,1);
}
if we tested the input.positionWS.y to be correct in step 1, and _SandStart is set correctly we should see the texture be divided in parts red (if true) and the other part blue (if false) (again since we're basing off world position we might need to change the material's height a bit to see it). If this division in colours doens't happen then the likely cause is that _SandStart isn't set properly, or to an incorrect value. (assuming this is a property you can inspect its value in the material editor)
if both of above steps yield the expected result then return tex2D(_MainTex, input.uv)* mainLight.shadowAttenuation; is possibly the culprit. To debug this we can return one of the textures without the if statement and shadowAttenuation, see if it applies the texture, and then return the other texture by changing which line is commented.
return tex2D(_MainTex, input.uv);
//return tex2D(_SandTex, input.uv);
If each of these textures gets applied properly seperately then it is unlikely that that was your cause, leaving either the shadowAttenutation (just add the multiplication to the above test) or something different altogether that isn't covered by the code in your question.
bonus round. If you got a shader property you want to debug you can actually do this from C# as well using the material.Get<type> function (the supported types can be found in the docs here, and include the array variants too, as well as both Get and Set). a small example:
Properties
{
_Foo ("Foo", Float) = 2
_Bar ("Bar", Color) = (1,1,1,1)
}
can be debugged from C# using
Material mat = getComponent<Material>();
Debug.LogFormat("_Foo value: {0}", mat.GetFloat("_Foo"); //prints 2
Debug.LogFormat("_Bar value: {0}", mat.GetFloat("_Bar"); //prints (1,1,1,1)

Clingo: Compare String Literals by Order (Index)?

I have defined a color palette called tableau10 in Clingo:
tableau10(blue;orange;red;teal;green;yellow;purple;pink;brown;gray).
Is there a way to compare the colors by the order they appear in my color definition? (e.g., blue = 0, orange = 1, red = 2, ...)
My goal is to be able to claim things like blue < orange, blue < gray...
The predicate tableau10 is unordered. To do such comparisons you'd have to encode order in one way or another. You could for example assign numbers to the colors value(blue, 1). value(orange, 2). ... and compare the associated numbers when necessary, or you could write lessthan(blue, orange). lessthan(orange, red). ... lessthan(brown,gray). and also add the transitivity rule lessthan(A, C) :- lessthan(A, B), lessthan(B, C).

Changing value in if statement

I'm trying to iterate through a column in numbers and change the background color of a cell, if the cell has a certain background color.
repeat with i from 11 to the count of cells by 6
if background color of cell i is {17990, 47031, 42919} then
set background color of cell i to {65535, 0, 0}
end if
end repeat
unfortunately, this does not do anything. The script just stops without Error. Help please!
There seems to be a bug in Numbers app where is not reporting the colors correctly. I set the background colors of columns A and B to your chosen value {17990, 47031, 42919}, but when I asked the script to return the colors, it returned the value {17990, 47030, 42919}. Because of this, I had the script check for both values and to act accordingly.
I added a dialog pop-up giving you the option to choose which column to change the cell colors.
tell application "Numbers"
set ifColor to {17990, 47031, 42919}
set ifColor2 to {17990, 47030, 42919}
set changeToColor to {65535, 0, 0}
tell its document 1
set theColumns to name of columns of table "Table 1" of active sheet
set chosenColumn to item 1 of (choose from list theColumns with title "Choose The Column" with prompt "Choose The Column")
set cellCount to count of cells of column chosenColumn of table "Table 1" of active sheet
repeat with i from 11 to cellCount by 6
set thisCell to cell ((chosenColumn & i) as string) of table "Table 1" of active sheet
if background color of thisCell is ifColor or background color of thisCell is ifColor2 then
set background color of thisCell to changeToColor
end if
end repeat
end tell
end tell
Here's the table I started with, having coloured the background of one cell magenta, i.e. {65535,0,65535}.
Then I ran this code:
use NumbersApp : application "Numbers"
property document : a reference to document 1 of NumbersApp
property sheet : a reference to active sheet of my document
property table : a reference to table 1 of my sheet
repeat with c in (a reference to every cell of my table)
if c's background color = missing value then ¬
set c's background color to {65535, 65535, 0}
if c's background color = {65535, 0, 65535} then ¬
set c's background color to {65535, 65535, 65535}
end repeat
I was expecting the majority of cells to turn yellow, and my magenta cell to turn white:
Hm...
My magenta cell is still looking far too magenta. So I decided to check just how magenta it really is:
return the background color of cell "C7" of my table
--> {64587, 609, 65480}
Well, that's not what I set it to, but it's pretty magenta, though I now see why it didn't turn white.
Next I decided to check the background colour of one of the yellow cells, that you have just seen me programmatically turn to a very specific kind of yellow:
return the background color of cell "D10" in my table
--> {65534, 65531, 2689}
Again, it is yellow, but not the yellow I told it to be.
Finally, I used the colour value just returned to try and target those cells and turn them black:
set the background color of every cell in my table ¬
whose background color is {65534, 65531, 2689} ¬
to {0, 0, 0}
Zilch. They are still very sunnily yellow.
Conclusion
Bug in AppleScript. I've submitted a bug report to Apple. I suggest you do the same.
#wch1zpink: {17990, 47031, 42919} --> {17990, 47030, 42919}
Looks like a rounding error introduced when converting integers to floating point numbers and back again. (AppleScript dates from the days of QuickDraw, which represented RGB values as UInt16, whereas Numbers is a Cocoa app, and Cocoa's NSColor uses CGFloat.) That's unavoidable, being a fundamental limitation of how CPUs do math (e.g. 0.7 * 0.7 = 0.49 --> false!).
The solution is to check the numbers are equal within an acceptable margin of error:
on areRealsEqual(n1, n2, toleranceMargin)
return n1 > n2 - toleranceMargin and n1 < n2 + toleranceMargin
end areRealsEqual
on areColorsEqual(c1, c2)
repeat with i from 1 to length of c1
if not areRealsEqual(item i of c1, item i of c2, 5) then return false
end repeat
return true
end areColorsEqual
set expectedColor to {17990, 47031, 42919}
set foundColor to {17990, 47030, 42919}
areColorsEqual(expectedColor, foundColor)
--> true

Unity is returning material color slightly wrong

I have this mini task in my game where you need to click trophies to change color of the wood on them. I have two arrays of colors, one is an array containing all possible colors and the other one contains four colors (the answer) as follows:
I've double checked that the colors are equal between the two arrays. For example the purple in Colors-array has exactly the same r, g, b & a values as the purple in the Right Order-array.
To check whether the trophies has correct color I just loop through them and grab their material color. Then I check that color against the Right Order-array but it's not quite working. For example when my first trophy is purple it should be correct, but it's not because for some reason Unity is returning slightly different material color than excepted:
Hope somebody knows why this is happening.
When you say, they are exactly same color, I assume you are referring rgb values from Color Inspector, which are not precise values.
Now I dont know what could be causing in different values of colors but
You can write an extension method to compare the values after rounding them to closest integer.
public static class Extensions
{
public static bool CompareRGB(this Color thisColor, Color otherColor)
{
return
Mathf.RoundToInt(thisColor.r * 255) == Mathf.RoundToInt(otherColor.r * 255) &&
Mathf.RoundToInt(thisColor.b * 255) == Mathf.RoundToInt(otherColor.b * 255) &&
Mathf.RoundToInt(thisColor.g * 255) == Mathf.RoundToInt(otherColor.g * 255);
}
}
usage:
Color red = Color.Red;
red.CompareRGB(Color.Red); // true;
red.CompareRGB(Color.Green); // false;
Hope this helps.
I would use a palette. This is simply an array of all the possible colors you use (sounds like you have this). Record, for each "trophy", the INDEX into this array, at the same time you assign the color to the renderer. Also, record the index for each "button", at the same time you assign the color to the renderer.
Then you can simply compare the palette index values (simple integers) to see if the color matches.