Add AutoAugment and ImageNet policy

[stiepan]

Category:

New feature (non-breaking change which adds functionality)

Description:

Adds AutoAugment: augmentation scheme that applies augmentations randomly per sample based on a policy. The policy consits of sub-polcies, each sub-policy is a sequence of augmentations to apply. Sub-policies are chosen uniformy at random for each sample. Then, the augmentations from the sequence are applied one-by-one. Each augmentation is described with the probability of it being applied or skipped and a magnitude - inuitevely a strenght of the operation.

The ImageNet policy is a policy found by the authors of the paper that introduces AA shown to improve the accuracy (https://arxiv.org/abs/1805.09501).

Additional information:

This is a part of Automatic Augmentation module #4648

The implementation groups the same augmentations from different sub-policies in hope for bigger partial-batches. For example, the ImageNet policy has 25 sub-policies, but in fact only 8 augmentations at each stage of the sub-policy.

Take the policy:

num_magnitude_bins = 11
[
[(rotate, 0.5, 7), (solarize, 0.3, 2)],
[(shear_x, 0.2, 5), (posterize, 0.6, 8)],
[(rotate, 0.9, 6), (posterize, 0.1, 10)],
]

Here the samples processing is split in three paths. However images that fall into 1st and 3rd sub-policy can be run together in first stage. Similarily, in the second stage, the samples that fall into 2nd and 3rd policy can be run together.

DALI will execute such policy by first: splitting batch into one that is omitted this time based on the probabilities from the first stage, i.e. (0.5, 0.2 and 0.9) and the one to process in the given stage, then the latter batch is split between rotate and shear_x. The rotate is called with per-sample angle that corresponds to the magnitudes from sub_policy (7 and 6). The batch is then merged and similar split is done for the second stage.

Affected modules and functionalities:

Key points relevant for the review:

Tests:

• Existing tests apply
• New tests added
  • Python tests
  • GTests
  • Benchmark
  • Other
• N/A

Checklist

Documentation

• Existing documentation applies
• Documentation updated
  • Docstring
  • Doxygen
  • RST
  • Jupyter
  • Other
• N/A

DALI team only

Requirements

• Implements new requirements
• Affects existing requirements
• N/A

REQ IDs: N/A

JIRA TASK: DALI-3193

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [7543750]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [7543750]: BUILD FAILED

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [7563307]: BUILD STARTED

[stiepan]

Fixed

[stiepan]

Fixed

[dali-automaton]

CI MESSAGE: [7563307]: BUILD FAILED

[awolant]

Well documented, well tested (+1 for using nose2 utils), very good descriptions of errors. Nice

[dali-automaton]

CI MESSAGE: [7563307]: BUILD PASSED

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [7566484]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [7566484]: BUILD FAILED

[dali-automaton]

CI MESSAGE: [7566484]: BUILD PASSED

[szalpal]

This appears in multiple places throughout our codebase. Wouldn't it be better to just add a dependency to the DALI wheel?

[stiepan]

I kind of followed a pattern here used elsewhere in DALI, but that makes a lot of sense. If we decide to change it, we can remove all such import wrapper at once.