-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix tiling for Reverse Distillation and STFPM #1319
Conversation
@blaz-r, the tests seem to fail. Will you be able to have a look? |
Okay sure. I think I broke backwards compatibility for fastflow. I'll fix this and rerun tests locally. |
Tests are now passing, and fastflow is now backwards compatible. |
@@ -21,6 +21,7 @@ class Fastflow(AnomalyModule): | |||
|
|||
Args: | |||
input_size (tuple[int, int]): Model input size. | |||
image_size (tuple[int, int]): Original image size (needed in case of tiling). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would having both image_size
and input_size
in the model definition be confusing to the user? @ashwinvaidya17, any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just call it original_image_size
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, not sure if I quite understood it. The only place we use the original_image_size is in anomaly_map_generator so that it can interpolate the flow maps. But why can't we pass the model input_size? Aren't the tiles generated from the input tensor that is in shape of model input_size? Also, won't the visualizer take care of re-scaling it further? Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Input size is in case of tiling equal to tile size, because the fastflow blocks requires actual input size at the time of initialization. If we pass just tile size, we can't really know the size of anomaly maps, and if we pass just image size (by default also input size), we can't init the model as we don't know the tile size in the constructor.
This is not a problem for other models as they don't require tile size in their constructors.
Visualiser can handle this, but the metrics don't, as they expect the same size of GT and anomaly map.
On the other hand, I think this could be renamed to anomal_map_size, which would be better than image_size or original_image_size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright thanks for the explination. Yeah we can rename it to anomaly_map_size
. Apart from this I have no other suggestions.
image_size = input_size | ||
|
||
self.anomaly_map_generator = AnomalyMapGenerator(image_size=image_size, mode=anomaly_map_mode) | ||
self.anomaly_map_generator = AnomalyMapGenerator(image_size=input_size, mode=anomaly_map_mode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A reference for future, but not it might make more sense to rename image_size
argument to input_size
in AnomalyMapGenerator
. As I said, it is not related to this PR, though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blaz-r, thanks for creating this PR. I have a single comment, which we could perhaps discuss with @ashwinvaidya17
Okay. Yeah the naming is a bit weird and I'm open to suggestions for renaming. I'm just not sure what to call image_size since it's called that in AnomalyMapGenerator. In case of normal FastFlow, input size is also image size, but when tiling is performed, input size is actually tile size and image size is image size, so I'm not sure how to name these so this is clearly indicated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the same input_size
comment raised by Samet I have no other feedback. Just one question though
@@ -21,6 +21,7 @@ class Fastflow(AnomalyModule): | |||
|
|||
Args: | |||
input_size (tuple[int, int]): Model input size. | |||
image_size (tuple[int, int]): Original image size (needed in case of tiling). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just call it original_image_size
?
@@ -21,6 +21,7 @@ class Fastflow(AnomalyModule): | |||
|
|||
Args: | |||
input_size (tuple[int, int]): Model input size. | |||
image_size (tuple[int, int]): Original image size (needed in case of tiling). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, not sure if I quite understood it. The only place we use the original_image_size is in anomaly_map_generator so that it can interpolate the flow maps. But why can't we pass the model input_size? Aren't the tiles generated from the input tensor that is in shape of model input_size? Also, won't the visualizer take care of re-scaling it further? Am I missing something?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for the fix
Fastflow tiling will be refactored to match other architectures. |
The addition to fastflow is reverted now. This PR only fixes tiling for Reverse Distillation and STFPM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks
Description
This PR fixes the tiling for STFPM and Reverse Distillation models. It also adds tiling support to Fastflow.
For STFPM and Reverse Distillation, instead of relying on the tiler initialization for size, we avoid this issue by rather untiling the features right before they are returned or use in anomaly map generator.
The implementation of Fastflow tiling is up to debate, but I tried to keep the predictions in tiled shape for the longest duration of procedure to offer the best benefits of reduced memory usage.
This PR does NOT add the callback for tiling setup because it's currently not present so I avoided adding it. To utilize (and verify) tiling, the following should be added to the callbacks:
Changes
Describe the changes you made
Checklist
Ensure that you followed the following