This is probably more of a VTK list issue, but if you are going to extend transformations on image data or rectilinear grids you may want to do what ITK (and other image processing systems do) and extend these datasets to include a transformation matrix (in ITK direction cosines for each axis are used). This would ensure compatibility with ITK; however some filters can be significantly impacted (derivatives for example). I think you really want to avoid massive and surprising memory bloat operations that conversion to structured grids would entail.<br>
<br><div class="gmail_quote">On Fri, Mar 5, 2010 at 6:29 PM, Moreland, Kenneth <span dir="ltr"><<a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">I’m clearly adding to this conversation late because I was on travel yesterday. I was going to comment that we should change some filters to handle more types of data. We had talked long ago about automatically running cell to point for filters that only accept point data. I’m no longer convinced that is a great idea as that filter implicitly mangles the data. For example, what does it mean to contour cell data? To me, it seems the right thing to me is to extract all faces that have neighbors with cell values on the opposite sides of the contour (or at least that is the best you can do without mangling the data).<br>
<br>
Here is some other oddness I have noticed or has been brought up on the mailing list:<br>
<br>
</span></font><ul><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There are separate gradient filters for image and unstructured data. It would be straightforward to write a metafilter that picks the correct gradient implementation given the input.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">The transform filter only works on point data sets. Users have wanted to use it on image data. It would be easy and not to memory consumptive to have the transform filter convert images and rectilinear grids to structured grids. Likewise for warp by scalar or vector.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There are two “clean” filters, and the names don’t make sense. I can’t believe more people haven’t complained about it. I figure they must be too confused to ask. At the very least the names should be more representative of what they do: “Clean Poly Data” and “Clean to Unstructured Grid”. It might be nice if they were somehow rolled into one (poly data input would stay poly data input, all others converted to unstructured grids). However, that might be confusing behavior.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">I’ve seen users get confused that the “Generate Surface Normals” filter only works on poly data. This is especially confusing because unstructured grids often look like poly data and poly data is sometimes converted to unstructured grids without the user knowing (for example, if running the clip filter). Perhaps this filter could be changed to work on unstructured grids as well (ignoring non 2D cells). Or perhaps it could implicitly extract the external surface.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Speaking of the external surface, the filter name “Extract Surface” is stupid. Extract what surface? A contour is a surface. A plane is a surface. The filter should be named “Extract External Surface” or simply “External Surface”.
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">At some point, the statistics functionality needs to be reworked (sorry, Dave). They are hard to use even if you know what you are doing, and few people do.<br>
</span></font></li></ul><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
-Ken<div><div></div><div class="h5"><br>
<br>
On 3/4/10 8:19 AM, "Utkarsh Ayachit" <<a href="http://utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div class="h5"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Autoconverting to some extent is reasonable and already planned eg.<br>
converting point data to cell data etc., but converting image data to<br>
unstructured grid (or such) can be risky due the memory bloat. Maybe<br>
when a filter is disabled, showing why it is disabled in the status<br>
bar (or something) may not be a bad idea.<br>
<br>
Utkarsh<br>
<br>
On Thu, Mar 4, 2010 at 10:15 AM, Jeff Baumes <<a href="http://jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a>> wrote:<br>
> Along with Dave's comment, I think auto-converting would be good to<br>
> help with this. For example, if you want to warp an image, can't you<br>
> just implicitly convert it to geometry? The result is that many things<br>
> would not be greyed out anymore.<br>
><br>
> It seems that would help with the cognitive load, so people don't even<br>
> need to know what all the different vtkDataObject subclasses are and<br>
> how to convert between them manually.<br>
><br>
> That said, making icons for the different data types in the pipeline<br>
> browser would probably help too, instead of everything just being a<br>
> green cube.<br>
><br>
> Jeff<br>
><br>
> On Thu, Mar 4, 2010 at 9:41 AM, David E DeMarle<br>
> <<a href="http://dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.com</a>> wrote:<br>
>> One thing that new users don't like is that it is hard to find out<br>
>> what filters do really and more frustratingly, why they are greyed out<br>
>> once you know what one you want.<br>
>><br>
>> We should do a better job of documenting the input and output types of<br>
>> each reader/source/filter/writer, what specifically it does, and what<br>
>> the input restrictions (domains) are. Perhaps we can automate the<br>
>> collection of that from the class hierarchy, doxygen, and the xml and<br>
>> expose it in some intuitive manner in the UI. For example using icons<br>
>> to represent input data set types and presence of cell/point scalars<br>
>> etc.<br>
>><br>
>> I will try to put up some mockup on the wiki page shortly.<br>
>><br>
>> David E DeMarle<br>
>> Kitware, Inc.<br>
>> R&D Engineer<br>
>> 28 Corporate Drive<br>
>> Clifton Park, NY 12065-8662<br>
>> Phone: 518-371-3971 x109<br>
>><br>
>><br>
>><br>
>> On Sat, Feb 27, 2010 at 11:45 AM, Moreland, Kenneth <<a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a>> wrote:<br>
>>> There is lots of good stuff here. I added a bunch of megalomaniacal<br>
>>> comments.<br>
>>><br>
>>> -Ken<br>
>>><br>
>>><br>
>>> On 2/26/10 10:27 AM, "Utkarsh Ayachit" <<a href="http://utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>> wrote:<br>
>>><br>
>>> Folks,<br>
>>><br>
>>> Following a discussion with Berk, I've started consolidating the ideas<br>
>>> for the improvements on a Wiki page.<br>
>>> Please start contributing your suggestions.<br>
>>><br>
>>> <a href="http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements" target="_blank">http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements</a><br>
>>><br>
>>> Utkarsh<br>
>>> _______________________________________________<br>
>>> Paraview-developers mailing list<br>
>>> <a href="http://Paraview-developers@paraview.org" target="_blank">Paraview-developers@paraview.org</a><br>
>>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> **** Kenneth Moreland<br>
>>> *** Sandia National Laboratories<br>
>>> ***********<br>
>>> *** *** *** email: <a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a><br>
>>> ** *** ** phone: (505) 844-8919<br>
>>> *** web: <a href="http://www.cs.unm.edu/~kmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Paraview-developers mailing list<br>
>>> <a href="http://Paraview-developers@paraview.org" target="_blank">Paraview-developers@paraview.org</a><br>
>>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Paraview-developers mailing list<br>
>> <a href="http://Paraview-developers@paraview.org" target="_blank">Paraview-developers@paraview.org</a><br>
>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Jeff Baumes, Ph.D.<br>
> R&D Engineer, Kitware Inc.<br>
> (518) 881-4932<br>
> <a href="http://jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a><br>
> _______________________________________________<br>
> Paraview-developers mailing list<br>
> <a href="http://Paraview-developers@paraview.org" target="_blank">Paraview-developers@paraview.org</a><br>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
><br>
<br>
<br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt"><br>
**** Kenneth Moreland<br>
*** Sandia National Laboratories<br>
*********** <br>
*** *** *** email: <a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a><br>
** *** ** phone: (505) 844-8919<br>
*** web: <a href="http://www.cs.unm.edu/~kmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font>
</div></div></div>
<br>_______________________________________________<br>
Paraview-developers mailing list<br>
<a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>William J. Schroeder, PhD<br>Kitware, Inc.<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">http://www.kitware.com</a><br>(518) 881-4902<br>