DAG successfully finished - difference between dark green vs light green circles - directed-acyclic-graphs

What's the difference between dark green (surrounded by the black line) & light green circle on DAG successful run (see attached snapshot where last three circles are light green while rest are dark green.)
DAG Successful

The DAGs/tasks with a black border are scheduled runs, whereas the non-bordered DAGs/tasks are manually triggered, i.e. by airflow trigger_dag.
It is documented here:
https://airflow.readthedocs.io/en/stable/concepts.html#task-lifecycle

Related

Detect change in color of pixel

I'm new to making programs and I have no idea where to really begin.
However I have this simple idea that I want to turn into reality.
I need to find a red pixel in a blue area on screen. The area is a rectangle from
(x = 86)(y = 457) to (x = 770)(y = 641) -- that's just can example.
Then get a list of all the pixels within that region and check if they are a certain color like (Red=186, Blue=10, Green=10)
Then 0.2 seconds later check if those pixels that were red are still red.
Then check again 3 times, every 0.2 seconds.
After that tell the program to wait until those pixels turn blue.
When they do open C:User/User1/documentss/pull.mcs --random file.
I would like to create this thing, but I have no idea how to get all the pixels within a certain region (since there is thousands and doing it manually won't work) then check their color and finally tell the program to open another program.
The picture attached is what I am working on, this red thing moves and I need to first find where it is and then make sure that the pixel stays red. Eventually the thing will sink and I need a program to start.
Thanks for reading and please give me some suggestions.
https://i.stack.imgur.com/EvC6t.png
In case someone else is looking for a solution to a problem like this. This can e accomplished with autohotkey very easily.
"find a red pixel in a blue area on screen. The area is a rectangle from
(x = 86)(y = 457) to (x = 770)(y = 641)"
in this example the red area is irrelevant, we're just looking for the blue pixel
PixelSearch, x, y, 457, 770, 770, 641, 0x0000FF, Fast RGB
if (ErrorLevel = 0){
MsgBox, Found the pixel at %x%,%y%
}
else MsgBox, We did not find the pixel.
Return

Drawing line with thickness become white, OpenCv iOS issue

I'm developing an iOS app using the OpenCV framework,
the problem occurs when I try to draw something in my outputframe.
In the image below I'm trying to draw a line and a circle
cv::circle(outputFrame, startingPoint, 50, cv::Scalar(250,0,250), -1);
cv::line(outputFrame, startingPoint, endpoint, cv::Scalar(0,250,0),4);
The problem occurs when I increase the thickness of the line the line itself became white with a contour of green " color green = cv::Scalar(0,250,0)"
Any help is appreciated
Check here
The reason you are getting a white contour with green color is - it just behave as single contour with both circle and line. It doesn't get segmented.

How to find color of the objects(cloth color of human being)?

I had come across several stack overflow questions and solutions, in all the questions the solution is based on a particular color(red or green or blue). I need to identify the color of objects which are of multiple type. I need to detect color which ranged between 0 to 255. So can anybody help me with a solution based on opencv.
Thanks in advance.
If you already know about what could be the possible color then it very simple. I will talk about one example and you can follow the same procedure for rest.
Lets say that you have several possible combinations, for example a t-shirt could have red and cyan color and you already have an image of such a sample. Then you should do the following:
Step-1: Load the template/sample image. Calculate its Hue-histogram (or Hue-Saturation histogram).
Step-2: Load the image for which you want to know the color. Calculte the histogram for this image also.
Step-3: Perform histogram matching() between all the sample/template/example/possbile image's histogram (i.e. step-1) and the image for which you want to know the color (i.e. step-2).
Step-4: For which so ever combination, you get the maximum value...your image has that color. For example, lets say your sample images have an image of red & cyan t-shirt, another image of bule & purple t-shirt and so on. And you get the maximum histogram matching() value for blue& purple , it means that your image for which you want to know have blue and purple color.

Determine most visible foreground color [duplicate]

I'm drawing a color selection button and I'm looking for a nice and simple formula to get a good text color (foreground) for a given background color in RGB.
A simple try would be to just take the complement color but this will produce an odd looking button for colors like pure blue or pure red.
Is there something well known that does this?
If it matters at all, I'm using QT.
For maximum legibility, you want maximum brightness contrast without getting into hues which don't work together. The most consistent way to do this is to stick with black or white for the text color. You might be able to come up with more aesthetically pleasing schemes, but none of them will be more legible.
To pick between black or white, you need to know the brightness of the background. This gets a little more complicated, due to two factors:
The perceived brightness of the individual primaries red, green, and blue are not identical. The quickest advice I can give is to use the traditional formula to convert RGB to gray - R*0.299 + G*0.587 + B*0.114. There are lots of other formulas.
The gamma curve applied to displays makes the middle gray value higher than you'd expect. This is easily solved by using 186 as the middle value rather than 128. Anything less than 186 should use white text, anything greater than 186 should use black text.
I'm no expert on programming things related to RGB, but from a designer's perspective, often the most readable color will be just a much lighter (if the background color is dark) or darker (if the background color is light) version of the same shade.
Basically you'd take your RGB values and if they're closer to 0 (dark) you'd push them each up by an equal amount for your foreground color, or vice versa if it's a light BG.
Complement colors can actually be really painful on the eyes for readability.
Leverage an outline for legibility
If by "good text color (foreground)" you intend it for legibility purposes when the user chooses any background colour, you can always produce white text having a black outline. It will be legible on any solid, patterned or gradient background, from black through white and anything in between.
Even if this doesn't hit the mark of your intention, I think it worthwhile posted here because I came looking for similar solutions.
Building on top of Mark's response, here's some Ruby code that'll do the work
rgbval = "8A23C0".hex
r = rgbval >> 16
g = (rgbval & 65280) >> 8
b = rgbval & 255
brightness = r*0.299 + g*0.587 + b*0.114
return (brightness > 160) ? "#000" : "#fff"
You are better off with a high difference in luminosity. In general, colored backgrounds with colored text suck for readability, hurting the eyes over time. Lightly tinted colors (e.g. in HSB, S~10%, B>90%) with black text work fine, or lightly tinted text over a black background. I'd stay away from coloring both. Dark text (b~30%, s>50%) with a subtle coloration over a white background can also be fine. Yellow (amber) text on a deep blue background has excellent readability, as does amber or green on black. This is why old dumbterms (vt100, vt52, etc.) went for these colors.
If you really need to do color-on-color for the 'look', you could reverse both H and B, while pinning saturation at a moderate to low level.
And one last note: if you have a 50% gray background, rethink your interface. You're robbing yourself of half your dynamic range! You're alienating low-visibility users, including anyone over 35...
Color combinations often look terrible when not carefully chosen. Why not use either white or black for the text, depending on the Brightness of the color. (Will need to convert to HSB first.)
Or let the user choose either black or white text.
Or use pre-defined combinations. This is what Google does in their calendar product.
I've been looking for a simailr answer and came across this post and some others that I thought I'd share. According to http://juicystudio.com/services/luminositycontrastratio.php#specify the "Success Criterion 1.4.3 of WCAG 2.0 requires the visual presentation of text and images of text has a contrast ratio of at least 4.5:1" with some exceptions. That site lets you put in foreground and background colors to compute their contrast, although it would be helpful if it would suggest alternatives or ranges.
One of the best sites I've found for visualizing color contrast is http://colorizer.org/ It lets you adjust almost all manner of color scales (RGB, CMYK, etc.) at the same time and then shows you the result on the screen, such as white text on a yellow background.
I usually look at color complements, they also have color complement wheels to help
http://www.makart.com/resources/artclass/cwheel.html
If your color is HSL, flip the Hue by 180 degrees for a decent calculation
I wanted to put #MarkRansom's answer into use and managed to create this snippet:
I got the values From seeing how sRGB converts to CIE XYZ and built upon that.
The script simply tracks the position of the foreground item and it's position regarding the colored background items.
Then based on background luminosity it gradually changes the foreground text color to either black or white.
Open the codepen for full example
https://codepen.io/AndrewKnife/pen/XWBggQq
const calculateLight = (colorItem: number) => {
let c = colorItem / 255.0;
if (c <= 0.03928) {
c /= 12.92;
} else {
c = Math.pow((c + 0.055) / 1.055, 2.4);
}
return c;
};
const calculateLuminosity = (color: RGBColor) => {
return (
0.2126 * calculateLight(color.r) +
0.7152 * calculateLight(color.g) +
0.0722 * calculateLight(color.b)
);
};
const getContrastColor = (color: RGBColor) => {
if (calculateLuminosity(color) > LUMINOSITY_LIMIT) {
return FONT_COLOR_DARK;
}
return FONT_COLOR_LIGHT;
};
I thing that converting to HSV might be the way, but IMO changing hue would look weird. I'd try keeping the hue and fiddling with value and maybe saturation (light red buttons with dark red text ... hm sounds scary :-) ).

Trigonometry across multiple planes

Please bear with me - I'm finding this very difficult to explain.
This is more of a trigonometry question but for what it matters, this is in JavaScript/KineticJS.
I have a series of 'group's which contain 'line's and 'handle's. The way this has to work, it works best for every group to have its own coordinate plane. The problem I'm asking for help on is the only instance where this solution is not ideal.
As these groups rotate, their coordinate plane also rotates. This allows the group object to be reused and its children can measure from the group's origin without any concern about the parent group's orientation. Up is always up... it doesn't matter which way my group is facing.
I'm a new poster, so I cant add an image. However, I think seeing it is vital. Please see http://i.imgur.com/WUVXE.png
The goal is to attach the unattached point of the red arc ('handle') to the black dot on the blue line ('line'). I've set it to always draw 90 degrees just for demonstration purposes.
Despite convention, the API I'm using rotates clockwise, giving the red line an angle of 0, the yellow line an angle of 116, green 180, and blue 296 - all relative to the same origin in the top left of the screen. These angles change, so I'm looking for the formula to calculate the new end point of the red handle.
The X-axis always travels straight down the middle of each line. The line is 20px wide, so there are 10px above or below it the line that are "dead space". The two correct points on the red handle are thus (10,10) and (30,10). Handles have a radius of 20px.
It is not possible to say red.arcEndX = blue.blackDotX, red.arcEndY = blue.blackDotY since the planes for the red and blue group are different. For instance, red's (0,0) is always equal to blue's (200,0). Think of each line as a chain that cannot be detached.
So, how do I calculate the red arc's remaining point? It should attach seamlessly to the edge of the blue line, exactly where the center point of the black dot on the blue line is except translated in to red's coordinate plane.
All of the measurements I may need are available, or can be calculated.
Handle.prototype.update = function() {
/* if we are the red group, this.parent is our group and
'prev' is the blue group. */
var prev = this.parent.getPrev();
// somehow get the new (x,y) for point2 below:
/* KineticJS SVG string. this.origin and this.point1 never
change. This (M)oves to 10,10, draws a (L)ine from
this.origin.x, this.origin.y to this.point1.x, this.point1.y
and (C)urves to this.point2.x, this.point2.y. this.centerXY
is the control point of that curve. */
this.data = "M" + this.origin + "L" + this.point1 + "C" + this.point1 + "," + this.centerXY + "," + this.point2 + "L" + this.origin + "z";
this.shape.setData(this.data);
}
In case anybody stumbles upon this - what I have is correct except I failed to accomodate the origin translation. If you move everything to (0,0) for each plane, do your sin/cos then you'll be OK