No Post-processing Without Decollate!

Describe the bug https://github.com/Project-MONAI/MONAI/blob/3edff7449984f87c371ac87c99244e6b00e97a92/monai/engines/workflow.py#L167-L171

Not all the metrics accepting decollated tensors, for instance ignite.metrics.Accuracy expects individual tensors, so disabling the entire post-processing transformation when decollate=False is limiting and in fact it has broken the pathology pipeline.

Expected behavior The post-processing being applied regardless of decollate status.

[Nic-Ma]

Hi @wyli ,

Thanks for your suggestions and comments, makes sense to me. Actually, I think we have discussed this topic several times before, and at that time our data shape is not flexible and also need to consider the TransformInverter and Metrics a lot, but now we don’t have those restrictions anymore. So I made an enhancement proposal based on our current implementation and your suggestions:

1. _run_postprocessing always executes no matter decollate=True / False.
2. Enhance _run_postprocessing to run engine_apply_transform directly if not both batch and output are lists, so it can also support other postprocessing methods instead of MONAI transforms.
3. Develop a DecollateBatch handler, so users can set decollate=False in the trainer and do some other logic then decollate the data in handlers, just a similar idea as the Postprocessing handler.

I can implement this proposal ASAP, what do you think?

Thanks.

[wyli]

Thanks for the reply @Nic-Ma let’s track pathology pipeline bugs in a separate ticket if there’s any…

For the main topic here, the postprocessing’s type is a generic Optional[Callable] (instead of monai.transforms.Transform) https://github.com/Project-MONAI/MONAI/blob/3edff7449984f87c371ac87c99244e6b00e97a92/monai/engines/workflow.py#L98 we should keep this flexibility throughout the base workflow implementation. The decollate can be viewed as a slightly special postprocessing step at this workflow level.

For the workflow flexibility, I have another two comments, (1) for on(IterationEvents.MODEL_COMPLETED) of the monai engine, the user should be able to set a sequence of event handlers in an arbitrary order, for example: “MyEventHandler1 -> Decollate -> MyEventHandler2 -> MyEventHandler3”, in this way the workflow allows for some customised event handling before the decollate. But by default, we could provide Decollate -> monai.handlers.Postprocessing -> any user specified handlers. Might be good to have a Decollate handler?

(2) I think the postprocessing logic is also too restrictive: https://github.com/Project-MONAI/MONAI/blob/3edff7449984f87c371ac87c99244e6b00e97a92/monai/engines/workflow.py#L196-L201 https://github.com/Project-MONAI/MONAI/blob/3edff7449984f87c371ac87c99244e6b00e97a92/monai/handlers/postprocessing.py#L54-L58

both case should be changed to something like:

def _run_postprocessing(engine: Engine) -> None:
    if not isinstance(engine.state.batch, list) or not isinstance(engine.state.output, list):
        warnings.warn("postprocessing requires `engine.state.batch` and `engine.state.outout` to be lists.")
        engine.state.batch, engine.state.output = engine_apply_transform(engine.state.batch, engine.state.output, transform)
    else:
        for i, (b, o) in enumerate(zip(engine.state.batch, engine.state.output)):
            engine.state.batch[i], engine.state.output[i] = engine_apply_transform(b, o, posttrans)