[ITK-users] releaseData flag, partial update in a complex pipeline

[asertyuio]

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-users at itk.org <mailto:insight-users at 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
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20170425/d32f3ded/attachment.html>