I would like the blue container view to be the same height as the orange container view. I am using proportional sizing to do so (all of these are within a vertical stack)I selected all of the containers then added the equal heights constraint to them. I am confused because there does not seem to be a proportional height constraint for the blue container view. I was able to change the proportional heights of the others just fine.
The layout is exactly what you've specified for the Heights:
Orange: 0.5 * Blue (1/2 Blue Height)
Green: == Blue
Yellow: == Blue
Purple: == Blue
Grey: 0.5 * Blue (1/2 Blue Height)
If you want "the blue container view to be the same height as the orange container view", you need to set
Orange: == Blue
Green: == Blue
Yellow: == Blue
Purple: == Blue
Grey: 0.5 * Blue (1/2 Blue Height)
You do not set a "proportional height" constraint on the Blue Container itself, because you've already told the stack view to fit all the views based on those Height constraints.
Edit - in response to comment: "I would like the blue itself to be smaller like the orange appears"
If you write this out (or speak it), you can probably answer the question yourself...
I want :
orange.height equal to blue.height
grey.height equal to blue.height
green.height twice as tall as blue.height
yellow.height twice as tall as blue.height
purple.height twice as tall as blue.height
So...
Orange: == Blue
Grey: == Blue
Green: == Blue * 2.0
Yellow: == Blue * 2.0
Purple: == Blue * 2.0
Maybe this will help you understand...
We don't assign a Height to the Blue view, because we are using the Height of the stack view to arrange its subviews.
So, let's assume the stack view Height is 450-points, either by setting it or by setting Top and Bottom constraints - and it just happens to be 450 because it will give this example nice numbers.
If we have Two views - Blue and Orange - and we want them the same Height, it looks like this:
Very simplified, auto-layout says: "Blue has a Height of 1 unit, Orange is equal to Blue, so it also has a Height of 1 unit. 1 + 1 == 2, for a total of 2 Height units, so divide 450 by 2 and give each view a height of 225"
If we want Orange to be twice as tall as Blue, we constrain Orange.Height = Blue.Height with Multiplier: 2 and we get this:
Auto-layout says: "Blue has a Height of 1 unit, Orange is equal to Blue x 2, so it has a Height of 2 units. 1 + 2 == 3 total Height units... 450 / 3 == 150, so give Blue a Height of 1 x 150 == 150 and give Orange a Height of 150 x 2 == 300".
For your layout, it looks like this:
We now have a total of 9 Height units (1 + 1 + 2 + 2 + 2 + 1), and auto-layout says: "450 / 9 == 50 (per Height unit) ..." and you can see how it lays out the views.
Related
I am a beginner in programmation
I have a raster stack of 40 elements
The stack 'images' is created using 3 bands (RGB) of drone. So each image have multiple bands. The sequence of the rasters in the stack is:
Position [[1]]: red band image 1
Position [[2]]: green band image 1
Position [[3]]: blue band image 1
Position [[4]]: red band image 2
Position [[5]]: green band image 2
Position [[6]]: blue band image 2
Position [[7]]: red band image 3
...
I want to derive vegetation index for each image: (40 EXG = excess green) : EXG = (2* green band - red band - blue band) /255. I divided by 255 to normalized the index.
So far I have doing it manually. For example:
EXG1-> (2*images[[2]] - images[[1]]) - images[[3]])/255
EXG2-> (2*images[[5]] - images[[4]]) - images[[6]])/255
etc.
Since my raster stack as a pattern, I am looking for an automatic way to derive the indices. Something like a loop that calculates the index, save it with the appropriate name and then moves to the next 'position' to repeat the process.
Any help on that please?
thank you
Assuming there is 40 images in stack, each with 3 bands something like:
indices <- data.frame(image_nr = integer(), index = double())
for (i in 1:40) {
EXG -> (2*images[[i*3-1]] - images[[i*3-2]] - images[[i*3]]) /255
newrow <- data.frame(image_nr = i, index = EXG)
indices <- rbind(indices, newrow)
}
We are trying to produce ePub publications that adhere to the W3C accessibility standards. One of the remaining issues is insufficient color contrast between the text color and the background color. We use Ace by DAISY (great tool!) which provides information about this sort of issue in both textual form and JSON:
And here is the JSON (it's not very straightforward to extract the two color values from the dct:description, but with a regular expression we manage):
{
"#type": "earl:assertion",
"earl:result": {
"earl:outcome": "fail",
"dct:description": "Element has insufficient color contrast of 2.86 (foreground color: #fd5f07, background color: #fff5ea, font size: 28.1pt (37.52px), font weight: normal). Expected contrast ratio of 3:1",
"earl:pointer": {
"cfi": [
"/4/2/6/2",
"/4/2/6"
],
"css": [
".inbrief-title",
".inbrief"
]
},
"html": "<div xmlns=\"http://www.w3.org/1999/xhtml\" class=\"inbrief-title\">In Brief</div> <!--##--> <div xmlns=\"http://www.w3.org/1999/xhtml\" class=\"box-container inbrief\">"
},
"earl:assertedBy": "aXe",
"earl:mode": "automatic",
"earl:test": {
"earl:impact": "serious",
"dct:title": "color-contrast",
"dct:description": "Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds",
"help": {
"url": "http://kb.daisy.org/publishing/docs/css/color.html",
"dct:title": "Color",
"dct:description": "Elements must have sufficient color contrast"
},
"rulesetTags": [
"cat.color",
"wcag2aa",
"wcag143"
]
}
},
However, I'd like to adapt these colors programmatically to create sufficient contrast between background and text colors by changing the colors as little as possible. For example, if there is a light yellow with white text, change the yellow to a darker hue until it meets the contrast requirement. Or, conversely, make the text black.
Is there an algorithm that one could implement that can do this? I couldn't find anything that seemed useful. When describing the use case above I found myself noticing that it is probably quite a subjective decision and therefore hard to automate.
The first thing you'd have to do is decide which color to change, the foreground or background. What I'd probably do is decide which color is the furthest from white or black because its value could be changed the most.
But before that, you have to figure out which color is light and which is dark. Fortunately, that's pretty easy. Since white is #fff and black is #000, whichever color value is the smallest (ie, closer to #000) is the darker one.
Then just subtract the light color from #fff (hexadecimal subtraction or convert the colors to decimal) and compare that to the darker color.
If the subtracted value for the light color is smaller than the dark color, then the light color is closer to white than the darker color is to black so you'll want to start modifying the darker color.
If the subtracted value for the light color is larger than the dark color, then the light color is further from white than the darker color is from black so you'll want to start modifying the light color.
When changing the color, just add or subtract 1 from each RGB component. Add 1 if you're making the light color lighter or subtract 1 if you're making the dark color darker.
After you add or subtract 1 from each RGB, compute the luminance contrast to see if you're above 4.5 (if the font is small), or above 3 (if the font is large - where "large" is defined as 14pt bold or 18pt normal).
The contrast ratio formula is kind of messy but doable.
(L1 + 0.05) / (L2 + 0.05)
L1 is the relative luminance of the lighter of the colors, and
L2 is the relative luminance of the darker of the colors.
You already know which color is lighter and which is darker.
The relative luminance value (L) is the messy part, although it initially looks simple. It's just:
L = 0.2126 * R + 0.7152 * G + 0.0722 * B
Essentially, it's 21% red, 71% blue, 7% green. But it's not the straight values of R, G, and B from your color. First you have to take each R, G, B value and divide by 255. Then depending on that value, you do some magic on the values.
R = R / 255
if R <= 0.03928 then R = R/12.92
else R = ((R+0.055)/1.055) ^ 2.4
Do that for G and B too. Now that you have new values for R, G, and B, then you can apply the 21%/71%/7% relative luminance above and that gives you L1 or L2, and then you can add 0.05 to both values and divide L1 by L2.
I told you it was messy but doable. This will give you the contrast value which should be between 1 and 21. (1 is when the two colors are the same [white on white, red on red, orange on orange, etc] and 21 is when the two colors are black (#000) and white (#fff).
If you haven't reached 4.5 (or 3.0, depending on the font size), then add or subtract 1 from each R/G/B again and compute the ratio again.
For funsies, here's an example:
color1 = #5EBA7D (the green background color on stackoverflow that shows the upvote value)
color2 = #FDF7E2 (the yellow background color on stackoverflow for the sidebar)
(The upvote text color is white but that's boring for an example so I chose yellow instead).
It doesn't matter which color is foreground or background. You get the same ratio. So lets use C1 as foreground and C2 as background. If you use a tool, such as CCA, it shows a value of 2.2:1, which fails WCAG 1.4.3.
Let's plug those numbers into the formula.
C1
#5EBA7D
R = #5E (94)
G = #BA (186)
B = #7D (125)
Divide each one by 255
R = 94/255 = 0.368
G = 186/255 = 0.729
B = 125/255 = 0.490
None of those values are less than 0.03928 so we have to apply the messy part. Add 0.055 then divide by 1.055 then raise that to the power of 2.4.
R = ((0.368 + 0.055)/1.055) ^ 2.4 = 0.112
G = ((0.729 + 0.055)/1.055) ^ 2.4 = 0.491
B = ((0.490 + 0.055)/1.055) ^ 2.4 = 0.205
Now you apply the percentages (21%/71%/7%) to get the first color's luminance value.
L1 = 0.2126 * R + 0.7152 * G + 0.0722 * B
L1 = 0.2126 * (.112) + 0.7152 * (.491) + 0.0722 * (.205)
L1 = 0.024 + 0.351 + 0.015
L1 = 0.390
Then you do it for the other color to get L2 = 0.929
L2 was the yellow color so is actually the lighter color and should be L1 in the original formula. So we'll make the green, which is darker, L2.
(L1 + 0.05) / (L2 + 0.05)
= (0.929 + 0.05) / (0.390 + 0.05)
= 2.226
If you use a color contrast tool, you should get the same value, although most tools typically round to one decimal place so you'll get 2.2.
Now that you know the ratio, which color is further away from black or white so you know which color to adjust?
color1 = #5EBA7D (green)
color2 = #FDF7E2 (yellow)
The smaller number is darker (closer to #000 black) so that would be #5EBA7D (green).
How far is the lighter color (#FDF7E2, yellow) from white (#fff)?
#FFFFFF - #FDF7E2 = #02081D
Now, which is bigger? The dark color, #5EBA7D (green), or the distance from yellow to white, #02081D? In this case, the green is bigger so it's further away from black than the yellow is from white.
Doing a gut check, that makes sense. The green isn't very dark, kind of a light-ish green so it's not very close to black. But yellow is very light and is close to white.
Since green is further from black than the yellow is from white, you can start adjusting the green and making it darker. Do this by subtracting 1 from each R/G/B value then recomputing the luminance. It probably won't change much so you'll have to keep adjusting the green and making it darker until you reach 4.5 (or 3.0, depending on font size).
If you program out this case, the green should eventually get to #258144 (which ends up subtracting 57 from each RGB value), which has a color ratio of 4.6 to the yellow.
If any of the RGB values reach 0 before you get to a decent contrast ratio, then you have to start making the light color lighter by adding 1 to each RGB value and recomputing the contrast. By adding or subtracting 1 from each RGB, you keep the color hue. The green is still green but is darker, or the yellow is still yellow but is lighter.
Are you wishing you hadn't asked the question now?
Minor Update:
Adjusting the RGB values by 1 each time and recomputing the luminance might not be very efficient. In my example, that would have to be done 57 times. You might want to add or subtract 10 from each RGB component instead of 1 and see how close to 4.5 you get. If not there yet, adjust by 10 again. Once you get greater than 4.5, you can tweak it back a bit and adjust by 2 in the opposite direction until you get as close to 4.5 without going under.
An urn contains 10 balls, in which 3 are white, 4 blue and 3 black. Three balls are drawn at random from the urn. I assign this to a sample space using the following code:
require(prob)
L<-rep(c("White","Blue","Black"),times=c(3,4,3))
M<-urnsamples(L,size=3,replace=FALSE, ordered=FALSE)
N<-probspace(M)
While calculating the probability of drawing three blue balls, I get the right answer.
> Prob(N,isin(N,c("White","Black")))
[1] 0.45
But, while trying to calculate the probability for drawing two white balls and one black ball, or for one ball of each colour, i get a returned answer as 0:
> Prob(N,isrep(N,"White","Blue","Black",1,1,1))
[1] 0
> Prob(N,isrep(N,"White","Black",2,1))
[1] 0
Is there something wrong with the code? Because logically the answers are 0.3 and 0.75 respectively. And if it works with the first case, why not the second and third, since all three should have the same code
You want to be able to specify the number of times that a certain color will appear in your results.
Bear in mind that we are somewhat limited by the sample size that you set, which was 3. We can see the list of possible combinations of 3 colors and their probabilities in an easy-to-read format using noorder:
noorder(N)
X1 X2 X3 probs
1 Ash Gray Ash Gray Ash Gray 0.008333333
2 Ash Gray Ash Gray Blue 0.100000000
3 Ash Gray Blue Blue 0.150000000
4 Blue Blue Blue 0.033333333
5 Ash Gray Ash Gray Ghost White 0.075000000
6 Ash Gray Blue Ghost White 0.300000000
7 Blue Blue Ghost White 0.150000000
8 Ash Gray Ghost White Ghost White 0.075000000
9 Blue Ghost White Ghost White 0.100000000
10 Ghost White Ghost White Ghost White 0.008333333
So from that table you can see that the probability of having 3 "Ash Gray" balls for instance is 0.008333333.
If we want to find the probability of having 2 "Ghost White" balls in the sample:
Q <- noorder(N)
Prob(Q,isin(Q,c("Ghost White", "Ghost White")))
[1] 0.1833333
We can verify this answer using the table above:
> 0.100000000+0.008333333+0.075000000
[1] 0.1833333
Let's make the sample size bigger and experiment some more.
M<-urnsamples(L,size=7,replace=FALSE, ordered=FALSE)
N<-probspace(M)
Q <- noorder(N)
With a sample size of 7 the probability of 2 "Ash Gray" and 1 "Ghost White" is:
Prob(Q,isin(Q,c("Ash Gray", rep(c("Ghost White", "Ash Gray"),1))))
[1] 0.8083333
and the probability of 3 "Ash Gray" and 2 "Ghost White" is:
> Prob(Q,isin(Q,c("Ash Gray", rep(c("Ghost White", "Ash Gray"),2)))
[1] 0.1833333
I am plotting two undesireable statistics
Columns: AGG(%SEP11)
Row: AGG(%Outdated_Defs)
This is how my graph looks. Only the points that have 50% or more installations of SEP 11 are red, even if they have high % of outdated defs.
I wish to make is such that sites with high % of outdated defs are also red, i.e.
In other words, only bottom left side of scatterplot should have green dots, remaining should have shades of red where top right quadrant had the most deep red dots.
Please help!
One option is to create a calculated field called bad_color:
IF AGG(%SEP11) >= 0.5 OR AGG(%Outdated_Defs) >= 0.5 THEN 1 ELSE 0 END
Then drag bad_color to the color field. Doubleclick on the color field and select red for 1 and green for 0.
You need to select 1 box and from that draw 1 object at random. What is the probability that the object drawn is black ?
Approach 1 : Sample space = { (the box number, the ball) }
// Sample Space = {(X,W) (X,W) (X,B) (X,B) (X,B) .... similar for Y and Z }
Thus answer is (3+1+4)/(2+3+3+1+1+4) = 8/14
Approach 2: summation ( probability of chosing ith box* prob of chosing a black) = (1/3 * 3/5) + (1/3 * 1/4) + (1/3 * 4/5) = 11/20
Which approach is correct and why ?
The second approach is correct. Just consider the extreme case you had the following setup:
Box X: (0W, 1B) <- no white balls, just 1 black ball
Box Y: (99W, 0B) <- loads of white balls, no black ball
Your first approach would give you a probability of 1% to get a black ball, but obviously, since you pick a box at random first and Box X does not contain white balls and Box Y does not contain black balls, the probability must be 50%. So it's
(1/2 * 1) + (1/2 * 0) = 1/2
Second Approach is correct.
There are basically 2 events , selecting the box and selecting the ball.
In first approach you are assuming that only 1 event is present(selecting the ball).