I am trying to write a program which returns all pixels which match a color.
Currently, I am using the default Pixel Search, but this only returns the first found pixel, searching from the top left to the bottom right.
Is there a way to code this?
I thought that I might be able to do a search from the top left, once a pixel is found, keep searching but with x + 1. However, it would need to search in the y direction first. I am not sure how to implement this though.
Thoughts are appreciated.
Related
I have 4 coordinates assigned to variables, so I would just like to colour in the rectangle that is created from these variables. I tried the fill function, but I cant gather much information from the example.
When I try to use:
fill(bottom left point, top right point,'g')
the figure it makes only shows a line between those points, and doesn't colour in the entire area.
I'm using MATLAB R2019b, if that helps.
Also, if its possible to fill the rectangle with a pattern instead, please let me know aswell.
Thanks in advance
I have an image (represented as green) overlaying a box (represented as blue), and the image is going to be transform: scale()ing in size. When this happens I need all edges of the image to complete their transformation at the same time.
To do this I need to calculate the transform-origin based on where the image is located overtop of the bounding box, using JavaScript. Assume I know all the coordinates that getBoundingClientRect() provides, for both elements.
In the six examples below I’ve placed a red dot where the transform-origin percentages should intersect.
I just can’t figure out the math to get there. The closest I've come to finding an answer is with this question, but it's a little vague and I'm not sure I fully understand the answer itself. I would greatly appreciate help with this, and will happily provide more details if I'm missing something.
After fiddling around, I figured out the formula is:
(
(box.left - image.left) /
(image.width - box.width)
) * 100
I am having trouble to change the bar color, I want it to be white in the middle, and red at the edge. Looking at matlab's description
if I do:
bar(y,'FaceColor','w','EdgeColor','r','LineWidth',1)
It should give me the above. However, when I actually run it, it only give me white graph.
Update: my y is:
y=zeros(1,5000); y(3000)=1; y(4000)=1;
Using the above, I got....
With so many bars, Matlab probably has trouble differentiating edge ('EdgeColor') and fill ('FaceColor') of each. After all, each complete bar is less than a screen pixel.
I suggest you use white edge and colored fill. That works for me. It's as if 'FaceColor' had precedence over 'EdgeColor'.
bar(y,'FaceColor','r','EdgeColor','w','LineWidth',1)
Or better yet: replace each bar by a line, that is, use stem:
stem(y,'r','marker','none')
I want to display overlapping boxplots using Sigmaplot 12. When I choose the scale for the x-axis as linear then the boxes do indeed overlap but are much too thin. See figure below. Of course they should be much wider.
When I choose the scale of the x-axis to be "category", then the boxes have the right width, but are arranged along each single x-value.
I want the position as in figure 1 and the width as in figure 2. I tried to resize the box in figure 1 but when I choose 100% in "bar width" than it still looks like Figure 1.
many thanks!
okay, I found the answer myself. In Sigmaplot, there is often the need to prepare "style"-columns, for example if you want to color your barcharts, you need a column that holds the specific color names.
For my boxplot example I needed a column that has the values for "width". These had to be quite large (2000) in order to have an effect. Why ? I have no idea. First I thought it would be because of the latitude values and that the program interprets the point as "1.000"s, but when I changed to values without decimals, it didn´t get better.
Well, here is the result in color.
Have fun !
I am creating a Microsoft Word document using the OpenXml library. Most of what I need is already working correctly. However, I can't for the life of me find the following bit of information.
I'm displaying an image in an anchor, which causes text to wrap around the image. I used WrapSquare but this seems to affect the last line of the previous paragraph as shown in the image below. The image is anchored to the second paragraph but causes the last line of the first paragraph to also indent around the image.
Word Screenshot http://www.softcircuits.com/Client/Word.jpg
Experimenting within Word, I can make the text wrap how I want by changing the wrapping to WrapTight. However, this requires a WrapPolygon with several coordinates. And I can't find any way to determine the polygon coordinates so that they match the size of the image, which is in pixels.
The documentation doesn't even seem to indicate what units are used for these coordinates, let alone how to calculate them from pixels. I can only assume the calculation would involve a DPI value, but I have no idea how to determine what DPI will be used when the user eventually loads the document into Word.
I would also be satisfied if someone can explain why the issues described above is happening in the first place. I can shift the image down and the previous paragraph is no longer affected. But why is this necessary? (The Distance from text setting for both Left and Top is 0".)
The WrapPolygon element has two possible child elements of LineTo and StartPoint that each take a x and y coordinate. According to 2.1.1331 Part 1 Section 20.4.2.9, lineTo (Wrapping Polygon Line End Position) and 2.1.1334 Part 1 Section 20.4.2.14, start (Wrapping Polygon Start) found in the [MS-OI29500: Microsoft Office Implementation Information for ISO/IEC-29500 Standard Compliance]:
The standard states that the x and y attributes are represented in
EMUs. Office interprets the x and y attributes in a fixed coordinate
space of 21600x21600.
As far as converting pixels to EMUs (English Metric Units), take a look at this blog post for an example.
I finally resolved this. Despite what the standard says, the WrapPolygon coordinates are not EMUs (English Metric Units). The coordinates are relative to the fixed coordinate space (21600 x 21600, as mentioned in the quote provided by amurra).
More specifically, this means 0,0 is at the top, left corner of the image, and 21600,21600 is at the bottom, right corner of the image. This is the case no matter what the size of the image is. Coordinates greater than 21600 extend outside the image.
According to this article, "The 21600 value is a legacy artifact from the drawing layer of early versions of the Microsoft Office."