-
Notifications
You must be signed in to change notification settings - Fork 710
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
metrics[0]: add per-image overlap (pimo) [GSoC 2023 @ OpenVINO] #1247
metrics[0]: add per-image overlap (pimo) [GSoC 2023 @ OpenVINO] #1247
Conversation
* New printing stuff * Remove dead code + address codacy issues * Refactor try/except + log to comet/wandb during runs * pre-commit error * third-party configuration --------- Co-authored-by: Ashwin Vaidya <[email protected]>
* ignore mask check when dataset has only normal samples * update changelog
Revert "🚚 Refactor Benchmarking Script (openvinotoolkit#1216)" This reverts commit 784767f.
* Fix metadata path * Update benchmarking notebook
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.
@jpcbertoldo, thanks for this! I just have minor comments, majority of which are naming-related.
@@ -20,9 +20,22 @@ | |||
from .collection import AnomalibMetricCollection | |||
from .min_max import MinMax | |||
from .optimal_f1 import OptimalF1 | |||
from .perimg import AUPImO, PerImageBinClfCurve, PImO |
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.
Can this be per_img
instead?
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.
Is it possible to name PerImageBinClfCurve
something more explicit. BinClf may not be obvious initially. Do you think if PerImageBinaryClassificationCurve
would be too verbose?
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.
I used PerImageBinaryClassificationCurve
at first but it feels very wordy and some lines will become tough to read.
binclf
is what I found in torchmetrics so i copied them.
per_img
i think it's ok; put it in the list of refactors.
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.
is common.py
needed? Could these be in __init__.py
. Or alternatively, can this be a utils.py
?
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.
Can you add doctoring and other headers as well?
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.
is
common.py
needed? Could these be in__init__.py
. Or alternatively, can this be autils.py
?
In __init__.py
it would create circular imports (in future PRs).
common.py
-> utils.py
is fine IMO, but it will later have more things inside that are not really "utils". I'll add this to the refactors.
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.
Can you add doctoring and other headers as well?
Sure. I'll add the docstrings, but what other headers specifically (apart from license)?
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.
Can you add doctoring and other headers as well?
Sure. I'll add the docstrings, but what other headers specifically (apart from license)?
I reviewed and incremented module docstrings in a future PR.
|
||
# =========================================== METRICS =========================================== | ||
|
||
PImOResult = namedtuple( |
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.
do you have any specific motivation why use named tuple instead of data class. I was just curious :) Just preference or any other motivation?
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.
Yes and more or less.
It's possible to just unpack the things, like
_, __, shared_fpr, tprs, image_classes = self.compute()
Also it's just a tuple, I think it makes user code less dependent on in-anomalib
classes. I tend to use it for this type of case where I actually just want to return many things but there are so many that it's easier to document it as a namedtuple. I noticed scipy
does something similar (?).
Otherwise I'm a big fan of dataclass : )
List of refactors before merging feature branch: Adds from this PR
|
@samet-akcay i put the naming issues in the todo list for the final refactor |
Notebook tests are failing due to your notebook, but you could address that later too |
Description
This is part of Anomaly Segmentation Metrics for Anomalib — GSoC 2023 @ OpenVINO.
Previously in #1220
Per-Image Overlap (PImO)
Adding the metric Per-Image Overlap (PImO) and its area under the curve (AUC).
At each given threshold:
I choose the vocabulary 'overlap' insted of TPR because it echoes with the Per-Region Overlap (PRO).
binclf curve
The per-image overlap (tpr) needs the binary classification matrix curve (binclf curve), which has to be computed per image , while they must share the thresholds (Since the x-axis (FPR) is shared).
You'll find a weird-looking funciton using itertools to compute thos binclf curves, which i found to be much faster on CPU than the two alternatives in torchmetrics (the latter mentioned in the former's doc) -- image below shows some WIP comparisons; a proper version on the way.
However, there is a
tensor.cpu().numpy()
in there, and I only tested with tensors already in the CPU.Perhaps when using tensors in the GPU that operation might make the fastest algorithm change?
Changes
Checklist