Implement Cutout in Numpy, PyTorch, and TensorFlow

[f4str]

Description

Implementation of the Cutout data augmentation defense in the Numpy, PyTorch, and TensorFlow frameworks.

Fixes # (issue)

Type of change

Please check all relevant options.

• Improvement (non-breaking)
• Bug fix (non-breaking)
• New feature (non-breaking)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Testing

Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

• Tests for the Cutout preprocessor in Numpy
• Tests for the Cutout preprocessor in PyTorch
• Tests for the Cutout preprocessor in TensorFlow

Test Configuration:

• OS
• Python version
• ART version or commit number
• TensorFlow / Keras / PyTorch / MXNet version

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[codecov-commenter]

Codecov Report

Merging #1850 (3156f32) into dev_1.13.0 (89bf92f) will decrease coverage by 1.31%.
The diff coverage is 98.05%.

@@              Coverage Diff               @@
##           dev_1.13.0    #1850      +/-   ##
==============================================
- Coverage       85.87%   84.55%   -1.32%     
==============================================
  Files             248      251       +3     
  Lines           23310    23464     +154     
  Branches         4212     4244      +32     
==============================================
- Hits            20017    19841     -176     
- Misses           2230     2560     +330     
  Partials         1063     1063              

Impacted Files	Coverage Δ
.../defences/preprocessor/cutout/cutout_tensorflow.py	97.77% <97.77%> (ø)
art/defences/preprocessor/cutout/cutout.py	98.11% <98.11%> (ø)
art/defences/preprocessor/cutout/cutout_pytorch.py	98.11% <98.11%> (ø)
art/defences/preprocessor/__init__.py	100.00% <100.00%> (ø)
.../estimators/speech_recognition/pytorch_espresso.py	15.68% <0.00%> (-76.48%)	⬇️
...estimators/speech_recognition/tensorflow_lingvo.py	18.27% <0.00%> (-73.10%)	⬇️
...timators/poison_mitigation/neural_cleanse/keras.py	78.47% <0.00%> (-13.89%)	⬇️
art/estimators/certification/abstain.py	90.90% <0.00%> (-9.10%)	⬇️
art/estimators/scikitlearn.py	66.66% <0.00%> (-8.34%)	⬇️
art/estimators/poison_mitigation/strip/strip.py	94.44% <0.00%> (-5.56%)	⬇️
... and 1 more

[lgtm-com]

This pull request introduces 1 alert when merging 2ddd96c into 8641de9 - view on LGTM.com

new alerts:

• 1 for Module is imported more than once

[lgtm-com]

This pull request introduces 1 alert when merging ee7f856 into 8641de9 - view on LGTM.com

new alerts:

• 1 for Module is imported more than once

[lgtm-com]

This pull request introduces 1 alert when merging 0e704fc into 8641de9 - view on LGTM.com

new alerts:

• 1 for Module is imported more than once

[lgtm-com]

This pull request introduces 1 alert when merging 1f12a39 into 89bf92f - view on LGTM.com

new alerts:

• 1 for Module is imported more than once

[lgtm-com]

This pull request introduces 1 alert when merging 7285511 into 89bf92f - view on LGTM.com

new alerts:

• 1 for Module is imported more than once

[lgtm-com]

This pull request introduces 2 alerts when merging 21a54c2 into 89bf92f - view on LGTM.com

new alerts:

• 2 for Module is imported more than once

[lgtm-com]

This pull request introduces 2 alerts when merging 214c2e7 into 89bf92f - view on LGTM.com

new alerts:

• 2 for Module is imported more than once

[f4str]

@beat-buesser once you've taken a look, please let me know if you think there should really be a different implementation for each framework. I don't believe there is much benefit from having framework specific implementations for PyTorch and TensorFlow since there is not much being done that offers a speedup from GPU. In fact, the bottleneck of converting between ndarray and tensor might actually make things slower. I think only having one Numpy version would make more sense here, but I'm open to suggestions.

[lgtm-com]

This pull request introduces 2 alerts when merging 8e47a93 into 89bf92f - view on LGTM.com

new alerts:

• 2 for Module is imported more than once

[beat-buesser]

Hi @f4str That's a good question. Can we think of an application where accurate gradient back-propagation would be useful? E.g for an adaptive poisoning attack on DP-InstaHide?

[lgtm-com]

This pull request introduces 2 alerts when merging 6131f95 into 89bf92f - view on LGTM.com

new alerts:

• 2 for Module is imported more than once

[f4str]

Hi @f4str That's a good question. Can we think of an application where accurate gradient back-propagation would be useful? E.g for an adaptive poisoning attack on DP-InstaHide?

Hi @beat-buesser thank you for the response. There may be some scenarios where accurate gradient backprop is useful. Adaptive poisoning attacks are definitely one use-case since the DP-InstaHide paper does actually evaluate against adaptive attacks, specifically using gradient matching (Witches' Brew). Whitebox evasion attacks like PGD might also be a use-case since that requires full gradients to the original image.

However, since DP-InstaHide (and all of the data augmentation algorithms) are randomized, it is unclear how important accurate gradient backprop really is.

[lgtm-com]

This pull request introduces 3 alerts when merging 99f1b53 into 89bf92f - view on LGTM.com

new alerts:

• 2 for Module is imported more than once
• 1 for Non-callable called

[lgtm-com]

This pull request introduces 5 alerts when merging 1db4e0a into 89bf92f - view on LGTM.com

new alerts:

• 3 for Redundant comparison
• 2 for Module is imported more than once

[lgtm-com]

This pull request introduces 7 alerts when merging 3156f32 into 89bf92f - view on LGTM.com

new alerts:

• 3 for Redundant comparison
• 2 for Wrong name for an argument in a call
• 2 for Module is imported more than once

[beat-buesser]

Hi @f4str The augmentations are random, but an adaptive attacker still can take advantage of accurate gradients corresponding to the respective randomly sampled augmentation.

[f4str]

Hi @f4str The augmentations are random, but an adaptive still needs accurate gradients corresponding to the respective randomly sampled augmentation.

Hi @beat-buesser that is true. In that case, it does make sense to have framework specific implementations to ensure that gradients are accurate. This is already the case, I'll just continue as is.

[beat-buesser]

Hi @f4str Thank you very much for contributing the first set of data augmentation preprocessors and congratulations to your first contribution to ART!