Hello,
You also need to graft the input and output so that updates and propagation of the mini-pipeline does not propagate beyond the mini-pipeline[1] [2].
Your approach sounds about right. But there are a lot of stumbling block with this approach and just a couple ways to do everything âproperâ. Also this goal of âcachingâ the internal data, is not what is generally done in ITK. Most filters in ITK, prefer to release the data and keep memory usage to a minimum. It frequently turns out, that keeping a pipelineâs memory foot print small is important to fast execution and allows the processing to scale to larger data sets too.
The âReleaseDataâ flag does not cause the pipeline to be re-executed. You will have to examine the pipeline code and the time stamps of the relevant objects to determine the effect of âmanualâ releasing the data, and how to best do it for your situation.
HTH,
Brad
[1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFeature/include/itkUnsharpMaskImageFilter.hxx#L78-L79
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFeature/include/itkUnsharpMaskImageFilter.hxx#L100-L102
On Apr 25, 2017, at 11:55 AM, asertyuio via Insight-users <insight-***@itk.org<mailto:insight-***@itk.org>> wrote:
Thanks for your answer Brad !
Just to confirm that I understood well:
To unsure that only the needed parts are actualized I call the global update, I need to:
*
use the H, R, RS, W, WS, M filters as members
*
set up their relationships in the filter constructor
*
do the update at the M filter
Then I can call manually releaseData on the R and W filter after the call to M update().
And that should do the trick, and release data should not make the downstream filters RS and WS to update, right ?
Ok, after rereading what the software guide tells about that:
Filter execution occurs
when a) the filter is modified as a result of modifying an instance variable; b) the input to the filter
changes; c) the input data has been released
â ITK Software guide p. 200
So it seems like if I release the data of W or R, updating M will force WS and RS to update⊠Am I wrong ?
If I want the filter to have the expected behavior, Is it possible to trigger the update manually ?
Iâm thinking of disconnecting RS and WS by using new smart pointers for R and W output, checking manually the modified state to conditionally call update when relevant.
Yann
Le 24/04/2017 à 17:35, Lowekamp, Bradley (NIH/NLM/LHC) [C] a écrit :
Hello,
To the best of my knowledge and experience with the ITK pipeline, when the output of a filter ( H or R ) is used as multiple inputs with the ReleaseData, the data from the output ( H or R ) will be release after _each_ filter which use that output data. So the result is that the minimal amount of memory is consumed! But in a complex pipeline like yours filters will be executed multiple times for a single update.
Based on your comments you likely want to set only R and W to ReleaseData automatically. This ensures that all the inputs to M are cached and available. The trade off is that R will get execute twice. Alternatively, you could just manually release the output of R after execution.
HTH,
Brad
On Apr 22, 2017, at 12:46 PM, asertyuio via Insight-users <insight-***@itk.org<mailto:insight-***@itk.org>> wrote:
Dear Users,
I have trouble applying the concepts behind the release data flag, and memory management of itk to a particular problem.
Iâm developing a filter with, for part of it, it a rather complex mini pipeline.
H, R, RS, W, WS and M are itk filters.
The filter will be updated frequently, and Iâm trying to make the update only update necessary parts, while keeping memory imprinting as low as possible.
Here is a schematic, simplified graph representing my filter :
H
| \
v \
R \ -> take as input a parameter P1 that do not change often
| \
/ \ /\
v v v |
RS W |
| | |
| v |
\ WS |
\ | /
v v v
M -> takes parameters P2 that are often updated
I would like to be able to release the output data of the filter R and of the filter W, updating them only if the parameter P1 change (which would trigger update for the whole pipeline), while still being able to change P2 without having to recalculate R, W and RS.
I think it may be possible with the releaseData flag, donât really understand where it should be putted, and if this will do what I need.
Thanks a lot for you help !
Yann
â
_____________________________________
Powered by www.kitware.com<http://www.kitware.com/>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users
â
_____________________________________
Powered by www.kitware.com<http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users