[vtk-developers] A vtkDataSampler and image interpolation
Biddiscombe, John A.
biddisco at cscs.ch
Wed Jul 6 04:41:19 EDT 2011
I'd say that the interface in your original email was fine. As long as you don't mind people like me adding bits to it if/when we adopt it within other classes.
As far as names are concerned, short is good, I quite like tagging 'Strategy' on the end as it emphasises the use of a design pattern - but ultimately, it is just bloat.
My thoughts regarding particle tracer etc were primarily that to get complicated caching stuff to work, I had to butcher a lot of classes - I considered having a more abstract 'interpolator' but needed to get 'inside' it to add the features required. (I see now that when the streamtracer was upgraded, the cached locator stuff was incorporated too). Effectively the vtkFunctionSet base class with vtkInterpolatedVelocityField etc already serve a very similar purpose as the AbstractInterpolator proposed. They are more generic in the sense that they handle N vars instead of just {x,y,z} and are designed with multi-block type datasets in mind - so the interface reflects this.
// .SECTION See Also
// vtkAbstractInterpolatedVelocityField vtkCellLocatorInterpolatedVelocityField
// vtkGenericInterpolatedVelocityField vtkCachingInterpolatedVelocityField
// vtkTemporalInterpolatedVelocityField vtkFunctionSet vtkStreamer vtkStreamTracer
The new interpolator classes could be used internally by some of these classes - and might simplify some of them (but perhaps not!). I don't think anything I say makes any difference so I shall shut up now.
JB
From: David Gobbi [mailto:david.gobbi at gmail.com]
Sent: 06 July 2011 09:31
To: Biddiscombe, John A.
Cc: Will Schroeder; VTK Developers
Subject: Re: [vtk-developers] A vtkDataSampler and image interpolation
Hi John,
Thanks for the comments, it sounds like this project is going to be even more useful that I originally guessed that it would be.
About the names, though, I'm a fan of succinct names so how about the following:
vtkAbstractInterpolator (base class, interface only)
vtkDataInterpolator (uses FindCell and optional locator, works on any data set)
vtk(whichever)Interpolator (various accelerated interpolators)
vtkAbstractImageInterpolator (base class for image interpolators)
vtkImageInterpolator (the basic image interpolator)
vtkImageSincInterpolator (my sinc interpolator)
vtkImageBSplineInterpolator (my b-spline interpolator)
But I wish that someone would comment on the interface that I proposed in my first email, or look at the header files in the gerrit repository. My main concern before I ready this for submission is that the interface is satisfactory to other VTK developers.
- David
On Wed, Jul 6, 2011 at 12:41 AM, Biddiscombe, John A. <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:
The streamline and particle tracer algorithms could indeed benefit from specialzed InterpolationStrategies. When creating the Particle tracer, I found the findcell method to be far too slow for real use and made changes to the various filters to use locator classes internally (using code which is in vtkModifiedBSPTree), this allowed much faster interpolation than the default method (I still have somewhere uncommitted changes to probefilter etc which have locators enabled). I began the process of making change to the streamline filter to also make use of this, but as I didn't need it directly, I didn't complete the work.
Allowing an InterpolationStrategy class which (let's say - names not important here) is
vtkDefaultUnstructuredInterpolationStrategy (uses FindCell by default),
vtkAcceleratedUnstructuredInterpolationStrategy (uses locator, option OctTree, BSP, Other, but takes more memory and has slower startup time - tree construction so not good for small datasets)
etc etc
would benefit the streamline type filters I'm sure. I suspect quite a lot of work might be involved in getting them upgraded.
For certain specialized cases (particle tracer), I made extensive use of caching of locators over time when grids were static (but scalars were varying). This produced very significant speedups but the interface was quite nasty - I cached individual cellIds and locator+dataset refs for multiblock traversal (see vtkCachingInterpolatedVelocityField for a quick overview and in particular the caching struct IVFDataSetInfo in the header).
If some of this functionality were exposed via the InterpolationStrategy, then it could be shoehorned into the streamline/particle tracer code.
JB
Caution : Writing from memory and it's been a while since I worked on this code. NB. I have a new particle tracer now which is even nastier and has InjectionStrategies and TerminationStrategies which have their own pipeline inputs and are similar to the InterpolationStrategy in terms of abstraction.
From: vtk-developers-bounces at vtk.org<mailto:vtk-developers-bounces at vtk.org> [mailto:vtk-developers-bounces at vtk.org<mailto:vtk-developers-bounces at vtk.org>] On Behalf Of Will Schroeder
Sent: 05 July 2011 20:24
To: David Gobbi
Cc: VTK Developers
Subject: Re: [vtk-developers] A vtkDataSampler and image interpolation
Okay thanks, assuming we document this in some manner (wiki or VTK Journal article) let's put a placeholder for some other potential algorithms. I know in DTI and other medical applications they are computing "streamlines" so this could be very useful for medical image analysis.
W
On Tue, Jul 5, 2011 at 12:51 PM, David Gobbi <david.gobbi at gmail.com<mailto:david.gobbi at gmail.com>> wrote:
Hi Will,
So far I've only considered the filters that I use, mainly vtkProbeFilter and
the implicit functions vtkImplicitDataSet and vtkImplicitVolume. And I've
also considered the possibility of a volume mapper that uses it, so that
people can provide their own specialized interpolation algorithms when they
are volume rendering their data. However, my experience with VTK's more
sophisticated graphics algorithms like streamlines is close to nil... I would
have to rely on other people's expertise to make a full list.
- David
On Tue, Jul 5, 2011 at 10:27 AM, Will Schroeder
<will.schroeder at kitware.com<mailto:will.schroeder at kitware.com>> wrote:
> Pretty cool idea David, thanks for the explanation.
> There are other potential filter applications that come to mind (as I'm sure
> you're aware of) such as streamlines, etc. Have you created a list, or
> thought about, which filters might benefit from this capability?
> W
>
> On Tue, Jul 5, 2011 at 8:26 AM, David Gobbi <david.gobbi at gmail.com<mailto:david.gobbi at gmail.com>> wrote:
>>
>> Hi Will,
>>
>> If I modified the vtkProbeFilter to use the vtkDataSampler, it would
>> allow people to customize the way that vtkProbeFilter interpolates the
>> data.
>>
>> The interface would look like this: a SetDataSampler() method would be
>> added to vtkProbeFilter
>>
>> void vtkProbeFilter::SetDataSampler(vtkDataSampler *);
>>
>> The probe filter would have a default vtkDataSampler object which
>> would use FindCell to interpolate the data (much like the way
>> vtkProbeFilter works now). But here is where the magic comes. The
>> user would be able to provide a different data sampler:
>>
>> vtkImageSampler *isample = vtkImageSampler::New();
>> probeFilter->SetDataSampler(isample);
>>
>> The vtkImageSampler is for image data, it has interpolation code that
>> is specifically written for structured data and is orders of magnitude
>> faster than using FindCell to interpolate the data. Also, it provides
>> the option of choosing different interpolation modes: nearest, linear,
>> and cubic.
>>
>> So, in a nutshell, adding a SetDataSampler() method would make it
>> possible for users to customize the way that vtkProbeFilter
>> interpolates values from its Input. The use of vtkImageSampler here
>> is just one example, if a person needs to use vtkProbeFilter on an FEM
>> data set and knows of an efficient way to interpolate their FEM, then
>> they could write a vtkDataSampler class specifically for their FEM.
>>
>> Another way to describe my goal is as follows: I have a whole bunch of
>> image interpolation code that I've written and tweaked over the past
>> 10+ years, and I want to be able to use this interpolation code with
>> the VTK graphics pipeline. The vtkDataSampler class is how I hope to
>> achieve this.
>>
>> - David
>>
>>
>> On Tue, Jul 5, 2011 at 3:49 AM, Will Schroeder
>> <will.schroeder at kitware.com<mailto:will.schroeder at kitware.com>> wrote:
>> > David-
>> > What's the relationship of this vtkDataSampler class to the
>> > vtkProbeFilter?
>> > W
>> >
>> > On Mon, Jul 4, 2011 at 1:23 PM, David Gobbi <david.gobbi at gmail.com<mailto:david.gobbi at gmail.com>>
>> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> I've written some new interpolation classes for VTK, both for images
>> >> and for other data sets. One thing that I want to ensure is that the
>> >> abstract interface is something that people will be satisfied with.
>> >> I use the same ScalarMode constants as vtkMapper, but there might
>> >> be a better way of selecting arrays that I am not aware of:
>> >>
>> >> class vtkDataSampler : public vtkObject
>> >> {
>> >> // set the data to interpolate (does not establish pipeline
>> >> connection)
>> >> void SetInput(vtkDataObject *);
>> >>
>> >> // update any internal state variables prior to commencing
>> >> interpolation
>> >> void Update();
>> >>
>> >> // get an interpolated value, return "false" if out of bounds
>> >> bool GetSample(const double point[3], double *value);
>> >>
>> >> // get an interpolated value (meant for use by wrapper languages)
>> >> double GetSample(double x, double y, double z, int component);
>> >>
>> >> // set the scalar mode (same as vtkMapper scalar modes)
>> >> void SetScalarMode(int mode);
>> >> void SetScalarModeToDefault();
>> >> void SetScalarModeToUsePointData();
>> >> void SetScalarModeToUseCellData();
>> >> void SetScalarModeToUsePointFieldData();
>> >> void SetScalarModeToUseCellFieldData();
>> >>
>> >> // set the array, if chosen scalar mode is field data
>> >> void SetArrayName(const char *name);
>> >>
>> >> void SetTolerance(double);
>> >> void SetLocator(vtkLocator *locator);
>> >> };
>> >>
>> >> The changes are on gerrit, if people want to see the full
>> >> implementation:
>> >> http://review.source.kitware.com/2004
>> >>
>> >> - David
>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com<mailto:will.schroeder at kitware.com>
> http://www.kitware.com
> (518) 881-4902<tel:%28518%29%20881-4902>
>
--
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com<mailto:will.schroeder at kitware.com>
http://www.kitware.com
(518) 881-4902<tel:%28518%29%20881-4902>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110706/cb502ed4/attachment.html>
More information about the vtk-developers
mailing list