[vtk-developers] RequestUpdateExtent not called after modified
Jé Velut
jerome.velut at gmail.com
Wed Feb 24 12:17:57 EST 2016
Thanks Berk,
Thanks a lot ! Indeed checking out the master did solve the issue (and
more! Good surprise!)
Best regards,
Jerome
2016-02-24 16:30 GMT+01:00 Berk Geveci <berk.geveci at kitware.com>:
> It is hard to guess whether the problem is the same without seeing code.
> However, this issue was fixed in VTK master so you may want to update and
> see for yourself. I am including below the documentation explaining the
> change (also available in Documentation/Doxygen/ChangesVTK-7-1.md).
>
> However, if RequestInformation() executes and RequestData() executes, it
> is impossible for RequestUpdateExtent() not to execute. There is no code
> path for this. So something is fishy.
>
> Best,
> -berk
>
>
> Pipeline Update Methods
> -----------------------
>
> The following methods were deprecated in VTK 7.1:
>
> ### vtkAlgorithm:
>
> int SetUpdateExtentToWholeExtent(int port);
> int SetUpdateExtentToWholeExtent();
> void SetUpdateExtent(int port,
> int piece,int numPieces, int ghostLevel);
> void SetUpdateExtent(
> int piece,int numPieces, int ghostLevel);
> void SetUpdateExtent(int port, int extent[6]);
> void SetUpdateExtent(int extent[6]);
>
> ### vtkStreamingDemandDrivenPipeline:
>
> int SetUpdateExtentToWholeExtent(int port);
> static int SetUpdateExtentToWholeExtent(vtkInformation *);
> int SetUpdateExtent(int port, int extent[6]);
> int SetUpdateExtent(int port, int x0, int x1, int y0, int y1, int z0,
> int z1);
> static int SetUpdateExtent(vtkInformation *, int extent[6]);
> int SetUpdateExtent(int port,
> int piece, int numPieces, int ghostLevel);
> static int SetUpdateExtent(vtkInformation *,
> int piece, int numPieces, int ghostLevel);
> static int SetUpdatePiece(vtkInformation *, int piece);
> static int SetUpdateNumberOfPieces(vtkInformation *, int n);
> static int SetUpdateGhostLevel(vtkInformation *, int n);
> int SetUpdateTimeStep(int port, double time);
> static int SetUpdateTimeStep(vtkInformation *, double time);
>
> The following new methods were added:
>
> ### vtkAlgorithm:
>
> int Update(int port, vtkInformationVector* requests);
> int Update(vtkInformation* requests);
> int UpdatePiece(int piece, int numPieces, int ghostLevels, int*
> extents=0);
> int UpdateExtent(int piece, int numPieces, int ghostLevels, int*
> extents=0);
> int UpdateTimeStep(double time,
> int piece=-1, int numPieces=1, int ghostLevels=0, int* extents=0);
>
> ### vtkStreamingDemandDrivenPipeline:
>
> int Update(int port, vtkInformationVector* requests);
>
> The main reason behind these changes is to make requesting a particular
> time step or a particular spatial subset (extent or pieces) during an
> update easier and more predictable. Prior to these changes, the following
> is the best way to request a subset during update:
>
> vtkNew<vtkRTAnalyticSource> source;
> // Set some properties of source here
> source->UpdateInformation();
> source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
> source->Update();
>
> Note that the following will not work:
>
> vtkNew<vtkRTAnalyticSource> source;
> // Set some properties of source here
> // source->UpdateInformation(); <-- this was commented out
> source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
> source->Update();
>
> This is because when the output of an algorithm is initialized, all
> request meta-data stored in its OutputInformation is removed. The
> initialization of the output happens during the first *RequestInformation*,
> which is why `UpdateInformation()` needs to be called before setting any
> request values. To make things more complicated, the following will also
> not work:
>
> vtkNew<vtkRTAnalyticSource> source;
> // Set some properties of source here
> source->UpdateInformation();
> source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
> source->Modified();
> source->Update();
>
> This is because during *RequestInformation*, the extent and piece requests
> are initialized to default values (which is the whole dataset) and
> *RequestInformation* is called during update if the algorithm has been
> modified since the last information update.
>
> This necessary sequence of calls has been mostly tribal knowledge and is
> very error prone. To simplify pipeline updates with requests, we introduced
> a new set of methods. With the new API, our example would be:
>
> vtkNew<vtkRTAnalyticSource> source;
> int updateExtent[6] = {0, 5, 0, 5, 2, 2};
> // Set some properties of source here
> source->UpdateExtent(updateExtent);
>
> To ask for a particular time step from a time source, we would do
> something like this:
>
> vtkNew<vtkExodusIIReader> reader;
> // Set properties here
> reader->UpdateTimeStep(0.5);
> // or
> reader->UpdateTimeStep(0.5, 1, 2, 1);
>
> The last call asks for time value 0.5 and the first of two pieces with one
> ghost level.
>
> The new algorithm also supports directly passing a number of keys to make
> requests:
>
> typedef vtkStreamingDemandDrivenPipeline vtkSDDP;
> vtkNew<vtkRTAnalyticSource> source;
> int updateExtent[6] = {0, 5, 0, 5, 2, 2};
> vtkNew<vtkInformation> requests;
> requests->Set(vtkSDDP::UPDATE_EXTENT(), updateExtent, 6);
> reader->Update(requests.GetPointer());
>
> This is equivalent to:
>
> typedef vtkStreamingDemandDrivenPipeline vtkSDDP;
> vtkNew<vtkRTAnalyticSource> source;
> int updateExtent[6] = {0, 5, 0, 5, 2, 2};
> source->UpdateInformation();
> source->GetOutputInformation(0)->Set(vtkSDDP::UPDATE_EXTENT(),
> updateExtent, 6);
> reader->Update();
>
> We expect to remove the deprecated methods in VTK 8.0.
>
> On Wed, Feb 24, 2016 at 3:01 AM, Jé Velut <jerome.velut at gmail.com> wrote:
>
>> Dear all,
>>
>> I am struggling with the pipeline mechanism.
>> I wrote an image reader that wraps the ITK gdcm reader. When I change the
>> directory,
>> the reader does update. However, if the extent of the second volume is
>> larger than the
>> first one, I get the warning message :
>>
>> ERROR: In
>> C:\Users\Jerome\Dev\VTK\vtk-src\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx,
>> line 857
>> vtkCompositeDataPipeline (000002913075DB70): The update extent specified
>> in the information for output port 0 on algorithm
>> vtkITKGDCMImageReader(000002913074A470) is 0 255 0 255 0 255, which is
>> outside the whole extent 0 255 0 255 0 197.
>>
>> Strangely, I wrote a simple test for this reader and the warning is not
>> thrown. The test set the file path, updates, then changes the file path and
>> updates again. The warning appears in a more complicated pipeline.
>>
>> The odd is that I implemented the RequestUpdateExtent, that simply
>> returns the Superclass::RequestUpdateExtent result. In the simple test,
>> this function is called at each pipeline update. In the full application,
>> it is not called the second time (while requestInformation is correctly
>> called...).
>>
>> I guess the pipeline does not notify correctly the reader to change the
>> update extent. But why?
>> I found this thread which may be close to my issue :
>>
>> http://markmail.org/search/?q=update_extent+not+updated#query:update_extent%20not%20updated+page:1+mid:xmi3dp3xqbnp2hzv+state:results
>>
>> Thanks a lot !
>> Jerome
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160224/d4295667/attachment.html>
More information about the vtk-developers
mailing list