<div dir="ltr">Bill-<div><br></div><div>I added a couple of methods to point locator and need to push them. I'll do that shortly, sorry for the hassle. It'll be later today,</div><div><br></div><div>W</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 11:22 AM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Will,<br>
<br>
When I try to build the latest I get:<br>
/Users/lorensen/ProjectsGIT/VTK/Remote/vtkPointCloud/vtkVoxelGrid.cxx:76:<br>
error: ‘class vtkStaticPointLocator’ has no member named<br>
‘GetBucketIds’<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 3, 2016 at 8:24 AM, Geoff Wright <<a href="mailto:gpwright@gmail.com">gpwright@gmail.com</a>> wrote:<br>
> Hi Will,<br>
><br>
> Looks good! I like the use of SMP. I'll definitely try it out once the<br>
> interpolation is in place, it will be great to eliminate PCL as a<br>
> dependency.<br>
><br>
> Regards,<br>
> Geoff<br>
><br>
><br>
> On Tue, Feb 2, 2016 at 4:42 PM Will Schroeder <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>><br>
> wrote:<br>
>><br>
>> Geoff-<br>
>><br>
>> I pushed an in progress version of VoxelGrid. As well as a hierarchical<br>
>> points binner. This is a work in progress so be forewarned. In particular,<br>
>> VoxelGrid does not yet interpolate its attributes yet. This is because I've<br>
>> got another branch in VTK for point interpolation, including interpolation<br>
>> kernels, that must ripen and placed in master first. Then the interpolation<br>
>> will be easy to add.<br>
>><br>
>> W<br>
>><br>
>> On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder<br>
>> <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
>>><br>
>>> Okay I have a quick and dirty design for "file" format and algorithmic<br>
>>> approach that I'll start implementing shortly. We'll clean it up with time.<br>
>>> Any feedback is welcome.<br>
>>><br>
>>> The data file format has three basic logical parts, which could be<br>
>>> written into separate files or one file, whatever. 1) metadata, 2) offsets,<br>
>>> and 3) sorted points.<br>
>>><br>
>>> The key idea is that the points are in sorted order, beginning with level<br>
>>> 0 root node, followed by level 1 bins (8 bins) and their points, and level 2<br>
>>> bins (64 bins) and their points, and so on. The points are just a contiguous<br>
>>> array of x-y-z, x-y-z, of type float or double (user specified), etc. Data<br>
>>> attributes could be stored in similar fashion (all easily changeable<br>
>>> depending on what you prefer). Since the number of points in each bin is<br>
>>> variable and may even be zero, this is where the offsets come into play.<br>
>>> (Note that points are not repeated, and statistically sampled as you suggest<br>
>>> ~1/(total number of bins)*NumberOfPoints points in each bin.)<br>
>>><br>
>>> The offsets are integral values that simply refer to a position in the<br>
>>> sorted points array corresponding to the beginning of each bin. So (level 0,<br>
>>> bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), (1,7),<br>
>>> (2,0), (2,1), ... you get the idea. For your example of a 3-level octree,<br>
>>> there would be 73 offset values (or T=73 total bins). Note that if offset_i<br>
>>> == offset_(i+1) then there are zero points in the bin referred to by<br>
>>> offset_i. We can also represent the offsets with different integral types<br>
>>> depending on the number of points (to save memory).<br>
>>><br>
>>> The metadata contains something like (assuming multiple separate files,<br>
>>> which of course can be memory mapped, etc):<br>
>>> NumberOfPoints #npts<br>
>>> NumberOfLevels #numLevels<br>
>>> Divisions 2 2 2<br>
>>> Bounds (xmin,xmax,ymin,ymax,zmin,zmax)<br>
>>> Points type "points.file"<br>
>>> Offsets type "offsets.file"<br>
>>> Array type numComp "scalars.file"<br>
>>> Array type numComp "vectors.file"<br>
>>><br>
>>> Note that the Divisions are variable, the structure does not have to be<br>
>>> an octree. This is useful to produce bins that are closer to uniform shape,<br>
>>> or even create a 2.5D, sorta flat binning tree (e.g. z-divisions always ==<br>
>>> 1).<br>
>>><br>
>>> Algorithmic approach: (this can easily be threaded):<br>
>>> For every point p_i in the input point cloud, generate a random number r<br>
>>> (0<=r<1). Assume that there are T total bins.<br>
>>> The probability (assuming an octree) that p_i is in level 0: is 1/T; in<br>
>>> level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into<br>
>>> proportional subranges that r maps into. Thus r will randomly select which<br>
>>> level of the tree a point belongs in.<br>
>>><br>
>>> Once p_i is assigned a level, compute a hash index h_i which consists of<br>
>>> the (i,j,k) bin index added to T_l, there T_l is the total number of bins at<br>
>>> the beginning of level l. This hash index is the key to get the sort in the<br>
>>> right order; using the level information is a way to segment the bins from<br>
>>> different levels into contiguous runs.<br>
>>><br>
>>> Now sort the points based on this hash index. The sort is where most of<br>
>>> the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted<br>
>>> points list. Next create the offsets array by running through the sorted<br>
>>> hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's<br>
>>> easy to do, and can even be done in parallel.)<br>
>>><br>
>>> From the mapper point of view: knowing the bounds, divisions, current<br>
>>> level, and (i,j,k) bin index it is possible to construct a local bounding<br>
>>> box for each bin. Then there is direct access to the list of points in each<br>
>>> bin (through the offsets). And of course since this is a hierarchy of<br>
>>> uniform bins, you can easily perform view culling etc. and choose the<br>
>>> appropriate level for LODs.<br>
>>><br>
>>> That's it in a nutshell. Unfortunately I've got lots of pointy-haired<br>
>>> boss stuff to do so this might take a bit to complete, but I'd really like<br>
>>> to get a prototype class written this week<br>
>>> (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-)<br>
>>> Initially I'll have this class build the data structures, with a special<br>
>>> back-door method to write the data out. Later on we'll decide if we need to<br>
>>> separate this backdoor IO into a separate class, etc.<br>
>>><br>
>>> Best,<br>
>>> W<br>
>>><br>
>>><br>
>>> On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin <<a href="mailto:ken.martin@kitware.com">ken.martin@kitware.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a<br>
>>>> simple ascii X Y Z R G B type format that I usually immediately convert to<br>
>>>> VTK XML format as that is far faster and more compact. So unfortunately PTS<br>
>>>> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some<br>
>>>> bounding box metadata.<br>
>>>><br>
>>>> Ken<br>
>>>><br>
>>>> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder<br>
>>>> <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
>>>>><br>
>>>>> Ken-<br>
>>>>><br>
>>>>> I am totally with you. I am writing some simple stuff at the moment<br>
>>>>> like VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly<br>
>>>>> to get my head around the challenges and serve as a stop gap until our<br>
>>>>> better stuff comes along. I really like your idea and I do plan to implement<br>
>>>>> this; it's really not too hard to do from what I understand and given the<br>
>>>>> pieces available in VTK.<br>
>>>>><br>
>>>>> So I'll wrap up this simple VoxelGrid and then take a crack at the<br>
>>>>> beast you've envisioned. The two major pieces seems to be 1) create a class<br>
>>>>> that builds the hierarchical structure, and 2) write a reader/writer pair<br>
>>>>> that can perform associated IO. In an earlier email you mentioned a PTS<br>
>>>>> reader that you made improvement to; is this a good exemplar data format or<br>
>>>>> do you have a better starting point?<br>
>>>>><br>
>>>>> It seems I have a homework assignment for the weekend :-)<br>
>>>>><br>
>>>>> Best,<br>
>>>>> W<br>
>>>>><br>
>>>>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin <<a href="mailto:ken.martin@kitware.com">ken.martin@kitware.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> Nice, can I make a specific request Will? :-) Part of what I want to<br>
>>>>>> do for large point clouds is something like the following:<br>
>>>>>><br>
>>>>>> 1) Open a VTK multipiece file and read in the bounding boxes of the<br>
>>>>>> pieces (but not the data)<br>
>>>>>><br>
>>>>>> 2) Read in the first piece and use it for rendering<br>
>>>>>><br>
>>>>>> 3) In the background read in more pieces, as they are loaded make them<br>
>>>>>> available to the mapper<br>
>>>>>><br>
>>>>>> 4) The mapper based on the current camera parameters and bounding<br>
>>>>>> boxes of the pieces intelligently selects what pieces to render. This<br>
>>>>>> provides a happy fast interactive experience leading to world peace.<br>
>>>>>><br>
>>>>>> For this to work well my thought was to have the pieces be broken up<br>
>>>>>> in a special way sort of like an octree but a spatial hash etc would be just<br>
>>>>>> as good as long as it is hierarchical and structured. Think of breaking up<br>
>>>>>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the<br>
>>>>>> data covering the entire bounding box. The next eight pieces also each<br>
>>>>>> contain about 1/73 of the data each constrained by their octant of the<br>
>>>>>> bounding box. Same idea for the next 64 boxes, they are just one level<br>
>>>>>> further down. This would work really well for a smart mapper providing fast<br>
>>>>>> first render plus fast LOD/subsequent renders. I can implement 1-4 pretty<br>
>>>>>> quickly.<br>
>>>>>><br>
>>>>>> But .... for it to work I need someone to create the 73 piece file the<br>
>>>>>> right way. (it does not have to be 73, and clearly some of those 73 will be<br>
>>>>>> empty, it just needs to be hierarchical and structured so that a group of<br>
>>>>>> pieces can be represented at a lower level of detail by some other piece) My<br>
>>>>>> gut feeling was to have the LOD pieces use actual points of the dataset (not<br>
>>>>>> centroids or similar) that way as more pieces are loaded we are just<br>
>>>>>> providing more detail, not replacing fake data (centroids) with real data.<br>
>>>>>> But really either approach is pretty easy to implement in the mapper. The<br>
>>>>>> latter approach just means the entire dataset footprint is larger because<br>
>>>>>> some of the points are not part of the full res dataset because you<br>
>>>>>> generated them.<br>
>>>>>><br>
>>>>>> I could be totally off base but that was my gut feeling on rendering ><br>
>>>>>> 2GB point clouds in a nice zippy manner.<br>
>>>>>><br>
>>>>>> TLDR: I want someone to write a filter/writer subclass to create a<br>
>>>>>> special 73 piece vtk file :-)<br>
>>>>>><br>
>>>>>> Ken<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder<br>
>>>>>> <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Geoff-<br>
>>>>>>><br>
>>>>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's<br>
>>>>>>> threaded and seems to be fast.<br>
>>>>>>><br>
>>>>>>> Question for you before I push the work to the repository: averaging<br>
>>>>>>> points in each bin provides a nice subsampled point position. But what do<br>
>>>>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These<br>
>>>>>>> could be averaged too. There are however other options like finding the<br>
>>>>>>> closest point to the subsampled point and using those attribute values, or<br>
>>>>>>> if you want to get really fancy, using an interpolation kernel to<br>
>>>>>>> interpolate to the subsampled point.<br>
>>>>>>><br>
>>>>>>> Thoughts?<br>
>>>>>>> W<br>
>>>>>>><br>
>>>>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder<br>
>>>>>>> <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Thanks for the feedback. I have some downsampling filters in the<br>
>>>>>>>> works now, I'll let you know when I have something ready.<br>
>>>>>>>><br>
>>>>>>>> BTW we are on a similar path. PCL is awesome, but we have some<br>
>>>>>>>> common workflows that would be better served with more compact software<br>
>>>>>>>> environments, and with minimal IO and/or data transfer. So we're trying to<br>
>>>>>>>> knock of a small kernel of capability to achieve this.<br>
>>>>>>>><br>
>>>>>>>> Best,<br>
>>>>>>>> W<br>
>>>>>>>><br>
>>>>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright <<a href="mailto:gpwright@gmail.com">gpwright@gmail.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Hi Will,<br>
>>>>>>>>><br>
>>>>>>>>> This is good to see. I'm currently using VTK to generate surfaces<br>
>>>>>>>>> from some point cloud data. I have some initial pre processing steps that I<br>
>>>>>>>>> use PCL (point cloud library) for, and then a vtk stage that converts PCL<br>
>>>>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to eliminate the<br>
>>>>>>>>> PCL dependency and use exclusively vtk. My point cloud data grows very<br>
>>>>>>>>> large over time with a lot of redundant points so its very important to<br>
>>>>>>>>> downsample them onto uniform spacing (<br>
>>>>>>>>> <a href="http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html" rel="noreferrer" target="_blank">http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html</a> ) before<br>
>>>>>>>>> processing them in vtk. Would it make sense to add something like this to<br>
>>>>>>>>> your library?<br>
>>>>>>>>><br>
>>>>>>>>> Geoff<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder<br>
>>>>>>>>> <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> FYI- I have committed an initial set of filters for performing<br>
>>>>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is<br>
>>>>>>>>>> an initial prototype. The work is currently available as a remote module to<br>
>>>>>>>>>> VTK (vtkPointCloud) via this repository:<br>
>>>>>>>>>> <a href="https://gitlab.kitware.com/vtk/point-cloud.git" rel="noreferrer" target="_blank">https://gitlab.kitware.com/vtk/point-cloud.git</a><br>
>>>>>>>>>><br>
>>>>>>>>>> A couple of notes:<br>
>>>>>>>>>> + Right now I am using vtkPolyData to represent the point cloud<br>
>>>>>>>>>> via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells<br>
>>>>>>>>>> created to save on memory.<br>
>>>>>>>>>> + The classes will process as input any vtkPointSet dataset<br>
>>>>>>>>>> + There is a general framework for filtering point clouds via the<br>
>>>>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these<br>
>>>>>>>>>> filters also have an optional, second output which contains any points<br>
>>>>>>>>>> removed from the input.<br>
>>>>>>>>>> + Current filters include vtkRadiusOutlierRemoval,<br>
>>>>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an<br>
>>>>>>>>>> implicit function). Some of these names are inspired by PCL names.<br>
>>>>>>>>>> + All filters are threaded using vtkSMPTools using a threaded<br>
>>>>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast,<br>
>>>>>>>>>> although I have not done much testing.<br>
>>>>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken<br>
>>>>>>>>>> wrote that is very fast.<br>
>>>>>>>>>><br>
>>>>>>>>>> As usual comments and suggestions are requested. In particular any<br>
>>>>>>>>>> suggestions for other filters to write are welcome (to round out some of the<br>
>>>>>>>>>> core functionality). The repository is in flux as I try crazy ideas and try<br>
>>>>>>>>>> to educate myself, so be forewarned.<br>
>>>>>>>>>><br>
>>>>>>>>>> Best,<br>
>>>>>>>>>> W<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>>>>>>>>>><br>
>>>>>>>>>> Visit other Kitware open-source projects at<br>
>>>>>>>>>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>>>>>>>>><br>
>>>>>>>>>> Search the list archives at:<br>
>>>>>>>>>> <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>>>>>>>>>><br>
>>>>>>>>>> Follow this link to subscribe/unsubscribe:<br>
>>>>>>>>>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> --<br>
>>>>>>>> William J. Schroeder, PhD<br>
>>>>>>>> Kitware, Inc. - Building the World's Technical Computing Software<br>
>>>>>>>> 28 Corporate Drive<br>
>>>>>>>> Clifton Park, NY 12065<br>
>>>>>>>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
>>>>>>>> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
>>>>>>>> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> William J. Schroeder, PhD<br>
>>>>>>> Kitware, Inc. - Building the World's Technical Computing Software<br>
>>>>>>> 28 Corporate Drive<br>
>>>>>>> Clifton Park, NY 12065<br>
>>>>>>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
>>>>>>> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
>>>>>>> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>>>>>>><br>
>>>>>>> Visit other Kitware open-source projects at<br>
>>>>>>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>>>>>><br>
>>>>>>> Search the list archives at:<br>
>>>>>>> <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>>>>>>><br>
>>>>>>> Follow this link to subscribe/unsubscribe:<br>
>>>>>>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Ken Martin PhD<br>
>>>>>> Chairman & CFO<br>
>>>>>> Kitware Inc.<br>
>>>>>> 28 Corporate Drive<br>
>>>>>> Clifton Park NY 12065<br>
>>>>>> <a href="tel:518%20371%203971" value="+15183713971">518 371 3971</a><br>
>>>>>><br>
>>>>>> This communication, including all attachments, contains confidential<br>
>>>>>> and legally privileged information, and it is intended only for the use of<br>
>>>>>> the addressee. Access to this email by anyone else is unauthorized. If you<br>
>>>>>> are not the intended recipient, any disclosure, copying, distribution or any<br>
>>>>>> action taken in reliance on it is prohibited and may be unlawful. If you<br>
>>>>>> received this communication in error please notify us immediately and<br>
>>>>>> destroy the original message. Thank you.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> William J. Schroeder, PhD<br>
>>>>> Kitware, Inc. - Building the World's Technical Computing Software<br>
>>>>> 28 Corporate Drive<br>
>>>>> Clifton Park, NY 12065<br>
>>>>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
>>>>> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
>>>>> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Ken Martin PhD<br>
>>>> Chairman & CFO<br>
>>>> Kitware Inc.<br>
>>>> 28 Corporate Drive<br>
>>>> Clifton Park NY 12065<br>
>>>> <a href="tel:518%20371%203971" value="+15183713971">518 371 3971</a><br>
>>>><br>
>>>> This communication, including all attachments, contains confidential and<br>
>>>> legally privileged information, and it is intended only for the use of the<br>
>>>> addressee. Access to this email by anyone else is unauthorized. If you are<br>
>>>> not the intended recipient, any disclosure, copying, distribution or any<br>
>>>> action taken in reliance on it is prohibited and may be unlawful. If you<br>
>>>> received this communication in error please notify us immediately and<br>
>>>> destroy the original message. Thank you.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> William J. Schroeder, PhD<br>
>>> Kitware, Inc. - Building the World's Technical Computing Software<br>
>>> 28 Corporate Drive<br>
>>> Clifton Park, NY 12065<br>
>>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
>>> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
>>> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> William J. Schroeder, PhD<br>
>> Kitware, Inc. - Building the World's Technical Computing Software<br>
>> 28 Corporate Drive<br>
>> Clifton Park, NY 12065<br>
>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
>> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
>> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
</div></div><div class="HOEnZb"><div class="h5">Unpaid intern in BillsBasement at noware dot com<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div>
</div>