[vtk-developers] Question about DATA_RESOLUTION key

[Biddiscombe, John A.]

David

The way I have solved this issue is by creating a vtkBoundsExtentTranslator which maps pieces to bounding boxes, the filter/reader replaces the extent translator with this one and downstream filters can convert pieces to bounds using it.

If a filter producing structured output is added, the bounds are converted to Extents using the WholeExtent to compute spacing and from there to local extents. it works, but IMHO you may find it easier to just add a SetResolution to your source!

JB

-----Original Message-----
From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Gobbi
Sent: 26 July 2011 17:42
To: David E DeMarle
Cc: VTK Developers
Subject: Re: [vtk-developers] Question about DATA_RESOLUTION key

Hi Dave,

Thanks for the pointers.  It looks like the best approach would be for
me to use unstructured extents, but they don't quite give me what I
need.  If the unstructured extent description included another key
called UPDATE_BOUNDS (double [6]) so that I could request pieces
from a spatially restricted region of the data set then it would be
perfect.

But I think that I'll skip the use of pipeline keys altogether and
just add a SetResolution() method directly to my image source.  My
intent is to make an image filter that caches an image at various
resolutions (i.e. like filtered mipmaps) and whose output corresponds
to a linear blending of the two mipmaps that are closest to the
requested resolution.  Ideally, it would respond to RESOLUTION
and BOUNDS update requests (if the latter existed) from the pipeline.

 - David


On Tue, Jul 26, 2011 at 7:40 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> Hello,
>
> My suggestion is to ask for the update extent in the scaled down space
> which is [0,127,0,127,0,0] in your example.
> But be warned, I haven't used it with structured extents directly and
> I'm not sure how it will behave. In my work I've always been working
> inside ParaView where the requests start out as unstructured piece
> requests but then make it back and are translated along the way before
> they get to the structured readers that I've been working with so far.
>
>
> Here are more details:
>
> In the ParaView source code, see
> vtkStreamingHarness::ComputePiecePriority() for an example of how I
> drive the pipeline to ask for a particular piece at a particular
> resolution.
>
> That first tells the pipeline it is interested in a particular piece
> at a particular resolution via the UPDATE_PIECE,
> UPDATE_NUMBER_OF_PIECES, and UPDATE_RESOLUTION keys.
>
> It then calls vtkStreamingDemandDrivenPipeline::ComputePriority()
> where I've put the various pipeline passes that make the pipeline flow
> just the way I needed it to.
>
> ComputePriority eventually makes the reader's RequestInformation().
> There the reader figures out what the real whole extent is as it
> normally would, but then it uses a more or less arbitrary function to
> decide what it should pretend the whole extent is based on the real
> whole extent and the UPDATE_RESOLUTION key. Afterward it provides that
> scaled down whole extent to the pipeline and from there on all
> requests take place in the scaled down space.
>
> Eventually RequestUpdateExtent and RequestData get called, and both
> are within the scaled down space.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
>
>
>
> On Mon, Jul 25, 2011 at 2:54 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Dave,
>>
>> I have a question about the way that UPDATE_RESOLUTION and
>> UPDATE_EXTENT are used with 3D extents.  My intent is to have certain
>> image filters and mappers request a desired UPDATE_RESOLUTION.
>> But I'm not sure exactly how this ties in with UPDATE_EXTENT.
>>
>> For example: let's say that the full-resolution 3D extent is [0, 255,
>> 0, 255, 0, 0] and a mapper wants half-resolution.  Should it request
>> an UPDATE_RESOLUTION of 0.5 but keep the UPDATE_EXTENT
>> at [0, 255, 0, 255, 0, 0]?  And would the updated data then have an
>> extent of [0, 127, 0, 127, 0, 0]?
>>
>>  - David
>>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers