Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: Beginner Question: PlotS rasterization info?
Ted (sehgal@oasis.rad.upenn.edu) writes: > When PlotS or Plot rasterizes straight lines between endpoints/vertices, > what's the best way to get the coordinates of all the points > interpolated? Surely this information is stored somewhere. Can I get > these coordinates without actually plotting anything to the screen? I > tried a Bresenham algorithm, but it doesn't return exactly the same > interpolated points as PlotS--there appears to be some sort of roundoff > difference. Any help would be appreciated, since currently I'm > resorting to the roundabout and no doubt inefficient method of plotting > to a pixmap, TVRD-ing, and then WHERE-ing the screen-dumped array.... Given the points (x1,y1) and (x2,y2), I think something like this should work: nPoints = ABS(x2-x1+1) > ABS(y2-y1+1) xloc = x1 + (x2 - x1) * Findgen(nPoints) / (nPoints - 1) yloc = y1 + (y2 - y1) * Findgen(nPoints) / (nPoints - 1) You might have to ROUND the locations, but this should get you pretty close, I think. Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
sandy <sehgal@oasis.rad.upenn.edu> writes: > When PlotS or Plot rasterizes straight lines between endpoints/vertices, > what's the best way to get the coordinates of all the points > interpolated? Surely this information is stored somewhere. Can I get > these coordinates without actually plotting anything to the screen? I > tried a Bresenham algorithm, but it doesn't return exactly the same > interpolated points as PlotS--there appears to be some sort of roundoff > difference. Any help would be appreciated, since currently I'm > resorting to the roundabout and no doubt inefficient method of plotting > to a pixmap, TVRD-ing, and then WHERE-ing the screen-dumped array.... Greetings Ted (Sandy?)-- If it's really important to you to have exactly the same pixels on the screen and in your array, then probably your pixmap/WHERE approach is the most reliable. If you already have the Bresenham algorithm coded, then what reason is there to use PLOTS? In other words, why not plot the pixel values you determined from the Bresenham, and then you can be sure you know them exactly? Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
> Greetings Ted (Sandy?)-- > > If it's really important to you to have exactly the same pixels on the > screen and in your array, then probably your pixmap/WHERE approach is > the most reliable. > > If you already have the Bresenham algorithm coded, then what reason is > there to use PLOTS? In other words, why not plot the pixel values you > determined from the Bresenham, and then you can be sure you know them > exactly? > > Craig > Thanks David and Craig, It's Ted--Sandy is just the default name on this computer. It is important to have the same pixels on the screen. I'm using a modified CW_DefRoi function to draw multiple regions of interests on multiple frames of QuickTime movies. The modified function only returns the vertices of the region of interest (instead of the subscripts of the interior). These ROIs may overlap one another, but I want to be able to select and erase one or some of them without erasing any pixels of the others from the screen. So I can't just use Device, Copy, the way I understand it. I also need to extract data from the frames at the pixel coordinates of the boundaries in order to analyze them, not just to replace/erase the ROI data with the original image data. I've thought about just plotting everything with the Bresenham like Craig suggests, but that would require further modifications to the CW_DefRoi function, since it almost surely uses the IDL Plot algorithm. It would also mean that for the sake of consistency future versions of the program could not use IDL's plot function either, and I'm not comfortable with that, since IDL's Plot is certainly much more reliable than my 15 lines of Bresenham code. I haven't actually overplotted results from David's approach on a PlotS line yet, but I'm thinking this technique will probably have the same roundoff problems as the Bresenham--I'll check on it. But what algorithm is IDL using to plot lines, anyway? I don't have that strong computer programming background--LabVIEW and one C programming course. I get the feeling I'm re-inventing the wheel. Now that I've described the program in greater detail, is there a better way? Thanks, Ted
Ted (sehgal@oasis.rad.upenn.edu) writes: > It's Ted--Sandy is just the default name on this computer. I hate it when those computers start doing that~ :-( > It is important to have the same pixels on the screen. I'm using a modified > CW_DefRoi function to draw multiple regions of interests on multiple frames > of QuickTime movies. The modified function only returns the vertices of the > region of interest (instead of the subscripts of the interior). You could get the interior pixels easy enough, though, with POLYFILLV. > These ROIs > may overlap one another, but I want to be able to select and erase one or > some of them without erasing any pixels of the others from the screen. So I > can't just use Device, Copy, the way I understand it. I also need to > extract data from the frames at the pixel coordinates of the boundaries in > order to analyze them, not just to replace/erase the ROI data with the > original image data. The trouble with CW_DEFROI, and the reason I have never really used it, is that it doesn't do just what you want it do it. It seems to do *almost* just what you want it to do. I always end up writing my own ROI code. It's not always pretty, but I do end up knowing how to control it. I'm afraid you may end up with something like that here, although I have to admit it sounds like you are going to a lot of trouble for little benefit. (At least it seems that way to me.) > I've thought about just plotting everything with the Bresenham like Craig > suggests, but that would require further modifications to the CW_DefRoi > function, since it almost surely uses the IDL Plot algorithm. It would also > mean that for the sake of consistency future versions of the program could > not use IDL's plot function either, and I'm not comfortable with that, since > IDL's Plot is certainly much more reliable than my 15 lines of Bresenham > code. You are probably right about the PLOT command, but I wouldn't even give you even money on the CONTOUR command. On the other hand, when something doesn't work most of us can find it if we only have to look in 15 lines of code. :-) > But what algorithm is IDL using to plot lines, anyway? This is exactly the kind of question most of us are using IDL to avoid answering. High level languages are suppose to shield you from these kinds of questions. It's probably the Dithered-Biffle Algorithm found in any good "Computer Graphics in C" text book. > I don't have that strong computer programming background--LabVIEW and one C > programming course. I get the feeling I'm re-inventing the wheel. Now that > I've described the program in greater detail, is there a better way? I'm sure there is. I just don't have a clear enough picture of the problem to know what it is. :-( Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155