[Paraview-developers] ParaView Usability Improvements

Berk Geveci berk.geveci at kitware.com
Sun Mar 7 10:17:19 EST 2010 

In an ideal world, all of those filters would be available for
rectilinear/structured grids. The fact that they are not currently
should not impact design decisions too strongly.

-berk

On Sat, Mar 6, 2010 at 9:53 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Another thing to be concerned about with silently changing type to
> structured grid is the fact that volume rendering and other image data
> specify filter will suddenly be unavailable, which may take the user
> by surprise.
>
> Utkarsh
>
> On Sat, Mar 6, 2010 at 2:03 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
>> I suggested it because I didn’t think converting image data to structured
>> data added “massive and surprising memory bloat.”  You basically just add a
>> coordinates array to the grid, don’t you?  There is no more memory added
>> than, say, running the gradient filter.  In fact, it’s really not any more
>> than running the transform filter on any type of point data, since a new
>> coordinates array is created anyway.
>>
>> Maybe we’ll just agree to disagree.
>>
>> -Ken
>>
>>
>> On 3/6/10 5:11 AM, "Will Schroeder" <will.schroeder at kitware.com> wrote:
>>
>> 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.
>>
>> On Fri, Mar 5, 2010 at 6:29 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
>>
>> 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).
>>
>> Here is some other oddness I have noticed or has been brought up on the
>> mailing list:
>>
>> 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.
>> 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.
>> 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.
>> 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.
>> 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”.
>> 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.
>>
>> -Ken
>>
>>
>> On 3/4/10 8:19 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com
>> <http://utkarsh.ayachit@kitware.com> > wrote:
>>
>> Autoconverting to some extent is reasonable and already planned eg.
>> converting point data to cell data etc., but converting image data to
>> unstructured grid (or such) can be risky due the memory bloat. Maybe
>> when a filter is disabled, showing why it is disabled in the status
>> bar (or something) may not be a bad idea.
>>
>> Utkarsh
>>
>> On Thu, Mar 4, 2010 at 10:15 AM, Jeff Baumes <jeff.baumes at kitware.com
>> <http://jeff.baumes@kitware.com> > wrote:
>>> Along with Dave's comment, I think auto-converting would be good to
>>> help with this. For example, if you want to warp an image, can't you
>>> just implicitly convert it to geometry? The result is that many things
>>> would not be greyed out anymore.
>>>
>>> It seems that would help with the cognitive load, so people don't even
>>> need to know what all the different vtkDataObject subclasses are and
>>> how to convert between them manually.
>>>
>>> That said, making icons for the different data types in the pipeline
>>> browser would probably help too, instead of everything just being a
>>> green cube.
>>>
>>> Jeff
>>>
>>> On Thu, Mar 4, 2010 at 9:41 AM, David E DeMarle
>>> <dave.demarle at kitware.com <http://dave.demarle@kitware.com> > wrote:
>>>> One thing that new users don't like is that it is hard to find out
>>>> what filters do really and more frustratingly, why they are greyed out
>>>> once you know what one you want.
>>>>
>>>> We should do a better job of documenting the input and output types of
>>>> each reader/source/filter/writer, what specifically it does, and what
>>>> the input restrictions (domains) are. Perhaps we can automate the
>>>> collection of that from the class hierarchy, doxygen, and the xml and
>>>> expose it in some intuitive manner in the UI. For example using icons
>>>> to represent input data set types and presence of cell/point scalars
>>>> etc.
>>>>
>>>> I will try to put up some mockup on the wiki page shortly.
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 28 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-371-3971 x109
>>>>
>>>>
>>>>
>>>> On Sat, Feb 27, 2010 at 11:45 AM, Moreland, Kenneth <kmorel at sandia.gov
>>>> <http://kmorel@sandia.gov> > wrote:
>>>>> There is lots of good stuff here.  I added a bunch of megalomaniacal
>>>>> comments.
>>>>>
>>>>> -Ken
>>>>>
>>>>>
>>>>> On 2/26/10 10:27 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com
>>>>> <http://utkarsh.ayachit@kitware.com> > wrote:
>>>>>
>>>>> Folks,
>>>>>
>>>>> Following a discussion with Berk, I've started consolidating the ideas
>>>>> for the improvements on a Wiki page.
>>>>> Please start contributing your suggestions.
>>>>>
>>>>>
>>>>> http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements
>>>>>
>>>>> Utkarsh
>>>>> _______________________________________________
>>>>> Paraview-developers mailing list
>>>>> Paraview-developers at paraview.org
>>>>> <http://Paraview-developers@paraview.org>
>>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    ****      Kenneth Moreland
>>>>>     ***      Sandia National Laboratories
>>>>> ***********
>>>>> *** *** ***  email: kmorel at sandia.gov <http://kmorel@sandia.gov>
>>>>> **  ***  **  phone: (505) 844-8919
>>>>>     ***      web:   http://www.cs.unm.edu/~kmorel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Paraview-developers mailing list
>>>>> Paraview-developers at paraview.org
>>>>> <http://Paraview-developers@paraview.org>
>>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Paraview-developers mailing list
>>>> Paraview-developers at paraview.org
>>>> <http://Paraview-developers@paraview.org>
>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Baumes, Ph.D.
>>> R&D Engineer, Kitware Inc.
>>> (518) 881-4932
>>> jeff.baumes at kitware.com <http://jeff.baumes@kitware.com>
>>> _______________________________________________
>>> Paraview-developers mailing list
>>> Paraview-developers at paraview.org <http://Paraview-developers@paraview.org>
>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>
>>
>>
>>
>>
>>    ****      Kenneth Moreland
>>     ***      Sandia National Laboratories
>> ***********
>> *** *** ***  email: kmorel at sandia.gov <http://kmorel@sandia.gov>
>> **  ***  **  phone: (505) 844-8919
>>     ***      web:   http://www.cs.unm.edu/~kmorel
>>
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>>
>>
>>
>>
>>    ****      Kenneth Moreland
>>     ***      Sandia National Laboratories
>> ***********
>> *** *** ***  email: kmorel at sandia.gov
>> **  ***  **  phone: (505) 844-8919
>>     ***      web:   http://www.cs.unm.edu/~kmorel
>>
>>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>

More information about the Paraview-developers mailing list