[vtk-developers] Question about DATA_RESOLUTION key

[David Gobbi]

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
>>
>