<HTML>
<HEAD>
<TITLE>Re: [Paraview-developers] ParaView Usability Improvements</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Lots of filters change the data type. Should we disable those, too?<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 3/6/10 7:53 PM, "Utkarsh Ayachit" <<a href="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Another thing to be concerned about with silently changing type to<BR>
structured grid is the fact that volume rendering and other image data<BR>
specify filter will suddenly be unavailable, which may take the user<BR>
by surprise.<BR>
<BR>
Utkarsh<BR>
<BR>
On Sat, Mar 6, 2010 at 2:03 PM, Moreland, Kenneth <<a href="kmorel@sandia.gov">kmorel@sandia.gov</a>> wrote:<BR>
> I suggested it because I didn’t think converting image data to structured<BR>
> data added “massive and surprising memory bloat.” You basically just add a<BR>
> coordinates array to the grid, don’t you? There is no more memory added<BR>
> than, say, running the gradient filter. In fact, it’s really not any more<BR>
> than running the transform filter on any type of point data, since a new<BR>
> coordinates array is created anyway.<BR>
><BR>
> Maybe we’ll just agree to disagree.<BR>
><BR>
> -Ken<BR>
><BR>
><BR>
> On 3/6/10 5:11 AM, "Will Schroeder" <<a href="will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<BR>
><BR>
> This is probably more of a VTK list issue, but if you are going to extend<BR>
> transformations on image data or rectilinear grids you may want to do what<BR>
> ITK (and other image processing systems do) and extend these datasets to<BR>
> include a transformation matrix (in ITK direction cosines for each axis are<BR>
> used). This would ensure compatibility with ITK; however some filters can be<BR>
> significantly impacted (derivatives for example). I think you really want to<BR>
> avoid massive and surprising memory bloat operations that conversion to<BR>
> structured grids would entail.<BR>
><BR>
> On Fri, Mar 5, 2010 at 6:29 PM, Moreland, Kenneth <<a href="kmorel@sandia.gov">kmorel@sandia.gov</a>> wrote:<BR>
><BR>
> I’m clearly adding to this conversation late because I was on travel<BR>
> yesterday. I was going to comment that we should change some filters to<BR>
> handle more types of data. We had talked long ago about automatically<BR>
> running cell to point for filters that only accept point data. I’m no<BR>
> longer convinced that is a great idea as that filter implicitly mangles the<BR>
> data. For example, what does it mean to contour cell data? To me, it seems<BR>
> the right thing to me is to extract all faces that have neighbors with cell<BR>
> values on the opposite sides of the contour (or at least that is the best<BR>
> you can do without mangling the data).<BR>
><BR>
> Here is some other oddness I have noticed or has been brought up on the<BR>
> mailing list:<BR>
><BR>
> There are separate gradient filters for image and unstructured data. It<BR>
> would be straightforward to write a metafilter that picks the correct<BR>
> gradient implementation given the input.<BR>
> The transform filter only works on point data sets. Users have wanted to<BR>
> use it on image data. It would be easy and not to memory consumptive to<BR>
> have the transform filter convert images and rectilinear grids to structured<BR>
> grids. Likewise for warp by scalar or vector.<BR>
> There are two “clean” filters, and the names don’t make sense. I can’t<BR>
> believe more people haven’t complained about it. I figure they must be too<BR>
> confused to ask. At the very least the names should be more representative<BR>
> of what they do: “Clean Poly Data” and “Clean to Unstructured Grid”. It<BR>
> might be nice if they were somehow rolled into one (poly data input would<BR>
> stay poly data input, all others converted to unstructured grids). However,<BR>
> that might be confusing behavior.<BR>
> I’ve seen users get confused that the “Generate Surface Normals” filter only<BR>
> works on poly data. This is especially confusing because unstructured grids<BR>
> often look like poly data and poly data is sometimes converted to<BR>
> unstructured grids without the user knowing (for example, if running the<BR>
> clip filter). Perhaps this filter could be changed to work on unstructured<BR>
> grids as well (ignoring non 2D cells). Or perhaps it could implicitly<BR>
> extract the external surface.<BR>
> Speaking of the external surface, the filter name “Extract Surface” is<BR>
> stupid. Extract what surface? A contour is a surface. A plane is a<BR>
> surface. The filter should be named “Extract External Surface” or simply<BR>
> “External Surface”.<BR>
> At some point, the statistics functionality needs to be reworked (sorry,<BR>
> Dave). They are hard to use even if you know what you are doing, and few<BR>
> people do.<BR>
><BR>
> -Ken<BR>
><BR>
><BR>
> On 3/4/10 8:19 AM, "Utkarsh Ayachit" <<a href="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a><BR>
> <<a href="http://utkarsh.ayachit@kitware.com">http://utkarsh.ayachit@kitware.com</a>> > wrote:<BR>
><BR>
> 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="jeff.baumes@kitware.com">jeff.baumes@kitware.com</a><BR>
> <<a href="http://jeff.baumes@kitware.com">http://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="dave.demarle@kitware.com">dave.demarle@kitware.com</a> <<a href="http://dave.demarle@kitware.com">http://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="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
>>> <<a href="http://kmorel@sandia.gov">http://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="utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a><BR>
>>>> <<a href="http://utkarsh.ayachit@kitware.com">http://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>
>>>><BR>
>>>> <a href="http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements">http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements</a><BR>
>>>><BR>
>>>> Utkarsh<BR>
>>>> _______________________________________________<BR>
>>>> Paraview-developers mailing list<BR>
>>>> <a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
>>>> <<a href="http://Paraview-developers@paraview.org">http://Paraview-developers@paraview.org</a>><BR>
>>>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers">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="kmorel@sandia.gov">kmorel@sandia.gov</a> <<a href="http://kmorel@sandia.gov">http://kmorel@sandia.gov</a>><BR>
>>>> ** *** ** phone: (505) 844-8919<BR>
>>>> *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
>>>><BR>
>>>><BR>
>>>> _______________________________________________<BR>
>>>> Paraview-developers mailing list<BR>
>>>> <a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
>>>> <<a href="http://Paraview-developers@paraview.org">http://Paraview-developers@paraview.org</a>><BR>
>>>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
>>>><BR>
>>>><BR>
>>> _______________________________________________<BR>
>>> Paraview-developers mailing list<BR>
>>> <a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
>>> <<a href="http://Paraview-developers@paraview.org">http://Paraview-developers@paraview.org</a>><BR>
>>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers">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="jeff.baumes@kitware.com">jeff.baumes@kitware.com</a> <<a href="http://jeff.baumes@kitware.com">http://jeff.baumes@kitware.com</a>><BR>
>> _______________________________________________<BR>
>> Paraview-developers mailing list<BR>
>> <a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a> <<a href="http://Paraview-developers@paraview.org">http://Paraview-developers@paraview.org</a>><BR>
>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
>><BR>
><BR>
><BR>
><BR>
><BR>
> **** Kenneth Moreland<BR>
> *** Sandia National Laboratories<BR>
> ***********<BR>
> *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a> <<a href="http://kmorel@sandia.gov">http://kmorel@sandia.gov</a>><BR>
> ** *** ** phone: (505) 844-8919<BR>
> *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
><BR>
><BR>
> _______________________________________________<BR>
> Paraview-developers mailing list<BR>
> <a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
> **** Kenneth Moreland<BR>
> *** Sandia National Laboratories<BR>
> ***********<BR>
> *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
> ** *** ** phone: (505) 844-8919<BR>
> *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
><BR>
><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="1"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:7.5pt'><BR>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** *** ** phone: (505) 844-8919<BR>
*** web: <a href="http://www.cs.unm.edu/~kmorel">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>
</BODY>
</HTML>