Another point of confusion for new users is that it isn't immediately obvious which arrays are scalars and which are vectors in the output of any given filter. <br><br>You do that by looking at the information tab and looking whether the array has one min/max pair or three pairs separated by commas. That isn't intuitive, especially because the information tab often isn't wide enough to show more than the first pair without scrolling.<br>
<br>I think an icon is called for, (1=scalar, 3=vector, 9=tensor, and other) and we have in the in-app / tooltip documentation somewhere the icon is just a suggestion because VTK isn't quite that rigid. (Ie RGB=scalar). If space is a premium on the page the tooltip can show the type and more.<br>
<br clear="all">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><div class="gmail_quote">On Sun, Mar 7, 2010 at 7:37 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Well, transform is special, since one wouldn't really be expecting the<br>
data type to be changed by a transform. In any case, like Berk said,<br>
we should support volume rendering etc. for structured grids as well.<br>
So if we do that, then changing type doesn't matter, as far as the<br>
user experience goes.<br>
<font color="#888888"><br>
Utkarsh<br>
</font><div><div></div><div class="h5"><br>
On Sun, Mar 7, 2010 at 5:54 PM, Moreland, Kenneth <<a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>> wrote:<br>
> 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="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<br>
><br>
> 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="mailto: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<br>
>> 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="mailto: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<br>
>> are<br>
>> used). This would ensure compatibility with ITK; however some filters can<br>
>> be<br>
>> significantly impacted (derivatives for example). I think you really want<br>
>> 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="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>><br>
>> 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<br>
>> the<br>
>> data. For example, what does it mean to contour cell data? To me, it<br>
>> seems<br>
>> the right thing to me is to extract all faces that have neighbors with<br>
>> 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<br>
>> 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<br>
>> too<br>
>> confused to ask. At the very least the names should be more<br>
>> 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).<br>
>> However,<br>
>> that might be confusing behavior.<br>
>> I’ve seen users get confused that the “Generate Surface Normals” filter<br>
>> only<br>
>> works on poly data. This is especially confusing because unstructured<br>
>> 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<br>
>> 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="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a><br>
>> <<a href="http://utkarsh.ayachit" target="_blank">http://utkarsh.ayachit</a>@<a href="http://kitware.com" target="_blank">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="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a><br>
>> <<a href="http://jeff.baumes" target="_blank">http://jeff.baumes</a>@<a href="http://kitware.com" target="_blank">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="mailto:dave.demarle@kitware.com">dave.demarle@kitware.com</a> <<a href="http://dave.demarle" target="_blank">http://dave.demarle</a>@<a href="http://kitware.com" target="_blank">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="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a><br>
>>>> <<a href="http://kmorel" target="_blank">http://kmorel</a>@<a href="http://sandia.gov" target="_blank">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="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a><br>
>>>>> <<a href="http://utkarsh.ayachit" target="_blank">http://utkarsh.ayachit</a>@<a href="http://kitware.com" target="_blank">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>
>>>>><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="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>>>>> <<a href="http://Paraview-developers" target="_blank">http://Paraview-developers</a>@<a href="http://paraview.org" target="_blank">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="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a> <<a href="http://kmorel" target="_blank">http://kmorel</a>@<a href="http://sandia.gov" target="_blank">sandia.gov</a>><br>
>>>>> ** *** ** phone: (505) 844-8919<br>
>>>>> *** web: <a href="http://www.cs.unm.edu/%7Ekmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Paraview-developers mailing list<br>
>>>>> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>>>>> <<a href="http://Paraview-developers" target="_blank">http://Paraview-developers</a>@<a href="http://paraview.org" target="_blank">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="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>>>> <<a href="http://Paraview-developers" target="_blank">http://Paraview-developers</a>@<a href="http://paraview.org" target="_blank">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="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a> <<a href="http://jeff.baumes" target="_blank">http://jeff.baumes</a>@<a href="http://kitware.com" target="_blank">kitware.com</a>><br>
>>> _______________________________________________<br>
>>> Paraview-developers mailing list<br>
>>> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>>> <<a href="http://Paraview-developers" target="_blank">http://Paraview-developers</a>@<a href="http://paraview.org" target="_blank">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>
>> **** Kenneth Moreland<br>
>> *** Sandia National Laboratories<br>
>> ***********<br>
>> *** *** *** email: <a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a> <<a href="http://kmorel" target="_blank">http://kmorel</a>@<a href="http://sandia.gov" target="_blank">sandia.gov</a>><br>
>> ** *** ** phone: (505) 844-8919<br>
>> *** web: <a href="http://www.cs.unm.edu/%7Ekmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
>><br>
>><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>
>><br>
>><br>
>><br>
>><br>
>> **** Kenneth Moreland<br>
>> *** Sandia National Laboratories<br>
>> ***********<br>
>> *** *** *** email: <a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a><br>
>> ** *** ** phone: (505) 844-8919<br>
>> *** web: <a href="http://www.cs.unm.edu/%7Ekmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
> **** Kenneth Moreland<br>
> *** Sandia National Laboratories<br>
> ***********<br>
> *** *** *** email: <a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a><br>
> ** *** ** phone: (505) 844-8919<br>
> *** web: <a href="http://www.cs.unm.edu/%7Ekmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
><br>
><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>
</div></div></blockquote></div><br>