[vtk-developers] Question about DATA_RESOLUTION key

[David Gobbi]

Thanks for the advice.  Yeah, I'm really thinking that I can avoid a
lot of hassle by dealing with this at the application level instead of
messing with the pipeline.

 - David


On Tue, Jul 26, 2011 at 9:55 AM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
> 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