-
Notifications
You must be signed in to change notification settings - Fork 106
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
Double checking the num_layer assignment in mds_ensemble_postprocessor #227
Comments
@Dengyu-Wu Thank you for pointing it out. Let me answer in two steps.
|
Thanks for the fast reply. I can understand that only outputs of the residual blocks would be used, but there is not only one residual connection, isn't it? My understanding is that num_layer would be a value related to the number of the features, not process_feature_type. Another issue is that I tried 'flat' in line 6. It ran out of 64 GB CPU memory on Cifar10 and crashed the workstation. A fix of this issue would also be helpful. |
Yes your understanding is correct and that is what I tried to explain in my point 2 in the previous comment. The memory issue is expected and there won't be a "fix" for it because with 'flat' you will be flattening out the feature map and dealing with a very high-dimensional vector, which is expected to blow your memory. The original Mahalanobis implementation always takes the mean if I remember correctly, so for example if a feature map is 256 x 16 x 16, it will take the mean over the last two dimensions and get a 256-d vector, which will be used later to compute feature statistics and perform OOD detection (this is also achieved by OpenOOD when using 'mean'). Yet with 'flat', you will be using the whole 256x16x16=65536-d vector as the feature. |
I see, thanks a lot. |
line 192 num_layer = len(feature_type_list), which only ranges from 1-3 according to config file line 6. Is it correct?
The text was updated successfully, but these errors were encountered: