-
Notifications
You must be signed in to change notification settings - Fork 709
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
Refactor feature extraction key #748
Refactor feature extraction key #748
Conversation
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.
great effort, thanks!
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. I had a close look at the design and I have some concerns, which are outlined below, along with some minor comments.
anomalib/models/components/feature_extractors/feature_extractor.py
Outdated
Show resolved
Hide resolved
anomalib/models/components/feature_extractors/feature_extractor.py
Outdated
Show resolved
Hide resolved
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.
Similar to what @djdameln raised, my primary concern is the following line in torch_model.py
and lightning_model.py
:
feature_extractor: FeatureExtractorParams
feaature_extractor
variable actually contains feature extractor parameters. Storing these as feature_extractor causes a confusion since the codebase has so many feature_extractor here and there.
This is way too much effort for a part that we plan to deprecate. Really appreciate your effort @ashwinvaidya17 ! |
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, huge improvement now that one layer of wrapper has been removed. I am not 100% convinced that we need the wrapper design at all, since the functionality added by the wrapper classes is only used for the construction of the model. But to speed things up, let's stick with this design for now. We can revisit the design once we deprecate timm.
Is there a github discussion/issue from which one can read why
? |
@jpcbertoldo, we have recently spotted that timm feature extractor provides inconsistent results, which overall adversely impact the performance of the models. We therefore decided to use torchfx feature extractor |
I've gathered our motivation here #779 |
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. Just two minor comments left:
@@ -3,14 +3,16 @@ | |||
# Copyright (C) 2022 Intel Corporation |
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.
Should this module be called feature_extraction
? This would be more in line other modules under models.components
(e.g. dimensionality_reduction
and sampling
)
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, only a single comment. Thanks a lot for your effort!
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!
Description
FeatureExtractor
selects timm or torchfx based on the parameters passed to it.Changes
Checklist