Skip to content
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

GradCAM varying on multiple calls #153

Open
palatos opened this issue Oct 29, 2020 · 3 comments
Open

GradCAM varying on multiple calls #153

palatos opened this issue Oct 29, 2020 · 3 comments
Labels
bug Something isn't working v1.0.0

Comments

@palatos
Copy link

palatos commented Oct 29, 2020

I'm running the GradCAM function on a pretrained model for a given image, and every time I generate the heatmap I get a different one. This happens whether or not I use the guided gradients option. The heatmaps are very different, too.

Is this expected?

@RaphaelMeudec
Copy link
Collaborator

This is not expected at all. Can you provide a sample code so I can easily reproduce this issue? Thanks for raising the issue

@RaphaelMeudec RaphaelMeudec added the bug Something isn't working label Oct 30, 2020
@palatos
Copy link
Author

palatos commented Oct 30, 2020

Sure! I think I actually tracked down the problem to augmentation layers I was using. I created a simple mock version of my problem in this notebook:
https://github.com/palatos/mynotes/blob/main/gradcam-with-augmentation-layers-problem.ipynb

If you run this you'll notice the augmentation layers screw up the GradCAM output because they are active by default when you add them to the model. They have a parameter "training = True" that gets turned off during predictions or evaluations, but the operations performed by explainer.explanation() don't count as prediction/evaluation, so the augmentation layer is active.

The only workarounds I found so far were mangling the already trained model to try and remove the augmentation layers, or manually redefining the model and explicitly passing the "training = False" argument in the relevant layers.

Neither of these solutions feels good though, because they require me to reconstruct the model in some way. It would be ideal to fix this only using the pretrained model somehow. I also think this might be a problem with Batch Normalization layers, which also have the same "training" parameter.

Let me know if you find a different solution?

@RaphaelMeudec
Copy link
Collaborator

Let's make sure in v1.0.0 that the parameter training=True is passed to the model.predict in tf-explain methods

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working v1.0.0
Projects
None yet
Development

No branches or pull requests

2 participants