[Paraview-developers] ParaView Usability Improvements
David E DeMarle
dave.demarle at kitware.com
Fri Mar 19 07:13:06 EDT 2010
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.
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.
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.
David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109
On Sun, Mar 7, 2010 at 7:37 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com
> wrote:
> Well, transform is special, since one wouldn't really be expecting the
> data type to be changed by a transform. In any case, like Berk said,
> we should support volume rendering etc. for structured grids as well.
> So if we do that, then changing type doesn't matter, as far as the
> user experience goes.
>
> Utkarsh
>
> On Sun, Mar 7, 2010 at 5:54 PM, Moreland, Kenneth <kmorel at sandia.gov>
> wrote:
> > 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<http://www.cs.unm.edu/%7Ekmorel>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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<http://www.cs.unm.edu/%7Ekmorel>
> >>
> >>
> >> _______________________________________________
> >> 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<http://www.cs.unm.edu/%7Ekmorel>
> >>
> >>
> >
> >
> >
> >
> > **** Kenneth Moreland
> > *** Sandia National Laboratories
> > ***********
> > *** *** *** email: kmorel at sandia.gov
> > ** *** ** phone: (505) 844-8919
> > *** web: http://www.cs.unm.edu/~kmorel<http://www.cs.unm.edu/%7Ekmorel>
> >
> >
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20100319/10af2e17/attachment-0001.htm>
More information about the Paraview-developers
mailing list