From: SHark on
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
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.