[Paraview-developers] ParaView Usability Improvements
Moreland, Kenneth
kmorel at sandia.gov
Sun Mar 7 17:54:22 EST 2010
Lots of filters change the data type. Should we disable those, too?
-Ken
On 3/6/10 7: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
>
>
**** Kenneth Moreland
*** Sandia National Laboratories
***********
*** *** *** email: kmorel at sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20100307/e09a5962/attachment-0001.htm>
More information about the Paraview-developers
mailing list