Prev: Need help with graphing points calculated in a for loop!!
Next: edit box values to be passed to a function
From: SHark on 16 Apr 2010 14:31 Hi, The goal of my code is to generate a grid of channels with defined thickness. It will later be used to plot the motion of a particle moving through this grid, by bounding the particle to move only within the line, which has a thickness and a color. So far, I'm plotting my lines using the function " line([x1, x2], [y1,y2], 'Color','r','LineWidth',2) " where x1, x2, y1, and y2 are generated by a for loop. So I was wondering if there is a way to return all coordinates of pixels used to draw that line. I have tried using " h = get(gca,'Children'); h2 = get(h,'XData') " But it returns a list of "[1x2 double]" Also, is there a way to set the Unit of linewidth to pixels, or perhaps a better way to accomplish this? Thanks in advance.
From: Walter Roberson on 16 Apr 2010 15:31
SHark wrote: > line([x1, x2], [y1,y2], 'Color','r','LineWidth',2) > So I was wondering if there is a way to return all coordinates of pixels > used to draw that line. No, not without doing a screen capture and analyzing the matrix of pixels that gets returned by that. There are different algorithms in use (by different programs) to decide which pixels should be lit or not, especially for lines at an angle. To make sense of it, you have to start thinking of drawn lines as reflecting something to do with positions that are within LineWidth/2 along the normal to the slope of the zero-width ideal line connecting the coordinates. You then have to figure out how to deal with pixels that are mathematically _partly_ covered by this "brush" that is LineWidth/2 wide. Especially if you are creating hardcopy then you do not necessarily want to treat all coverage occurrences the same way -- that tends to lead to "banding" on hardcopy. So your algorithm might decide that a pixel is to be completely lit if there is a mathematical coverage (possibly combined from several different lines) of 1/2 or more of the area of the pixel, or your algorithm might decide that a pixel is to be completely lit based upon a probability proportional to the mathematical coverage of the pixel... or the algorithm might take into account also more distant pixels and the "trend" and discretized curvatures... One important question that has to be answered early on in developing any such algorithm, is what _exactly_ the coordinates refer to. Is (0,0) the bottom left (or top right) corner of a pixel, with the centre of that pixel being at (1/2, 1/2) ? If you adopt that definition then a simple one-pixel width line between (0,0) and (10,0) [say] is either going to be jagged or going to disappear, or is going to end up drawing a two-pixel-wide line (because on each side of the boundary, linewidth/2 = 1/2 and you may be using the rule that 1/2 or more means light the pixel.) It can thus make more sense for drawing purposes if you define the coordinates associated with any one pixel as defining the centre of the pixel.. though that can get messy in itself if your pixels (perhaps in hard copy) are not square. |