Data Augmentation

Goal

By the end of this lesson, you can explain augmentation as a task-specific invariance claim, distinguish safe from label-changing transformations, and diagnose augmentation problems by inspecting transformed examples with their labels.

An augmentation makes a promise about label meaning

Suppose the task is to classify an image as vertical bar or horizontal bar.

A small horizontal shift of a vertical bar changes pixel positions but not orientation. Keeping the vertical label makes sense.

A 90-degree rotation turns the vertical bar into a horizontal bar. Keeping the old vertical label would now be wrong.

That gives the central rule:

A supervised augmentation is safe only when the transformed example still deserves the same label.

Augmentation teaches an invariance

An invariance is a change that the prediction should ignore.

If translated objects should keep the same class, showing shifted examples tells the model that exact position is not the important distinction.

This can reduce memorization of accidental details in a small training set.

But an invariance is task-specific. Horizontal flipping may be safe for many animal images and unsafe for text, road signs, left/right medical anatomy, or directional arrows.

Inspect transformations and labels together

The Lab applies shifts, flips, and rotations to a tiny vertical-bar image.

1. Click Run. The original image is a vertical bar, so original: vertical.
2. Read each transformed line next to original label still valid:. The one-column shift and the left-right flip both stay vertical, so the label is still valid (True).
3. Read the rotation line: rotated: horizontal | original label still valid: False. If an augmentation pipeline rotated this image but kept the label vertical, it would teach the model a wrong answer. That is label noise created by augmentation.
4. Now make the shift bigger. Find shifted = shift_right(image, 1) and change 1 to 2. Before running, explain whether a vertical bar moved two columns to the right is still vertical.
5. Click Run. The shifted line is still vertical ... True: shifting moves where the bar is, not which way it points.
6. Press Reset afterward.

Loading lab…

Technically correct code can create a data-quality bug

An augmentation function may execute perfectly, return the right shape, and still destroy supervision.

If an arrow-up image is rotated 180 degrees but the label remains up, optimization receives contradictory evidence.

When augmentation hurts validation behavior, inspect actual transformed examples before changing optimizer settings or model capacity.

More augmentation is not automatically better

Aggressive transformation can make training data unrealistic or erase signals the task needs.

Useful augmentation policy therefore depends on:

• the target semantics;
• the expected real-world variation;
• whether the transformation preserves the prediction moment and label;
• validation evidence under realistic conditions.

An augmentation encodes an assumption about what should stay unchanged

Suppose a cat image is shifted two pixels to the right. If the task is “cat versus dog,” the correct label should usually stay the same.

A small translation can therefore create another plausible training example with the same label.

But not every transformation is label-preserving. Flipping a handwritten 6 vertically could create something that no longer belongs to the original class. Rotating a medical image may violate how that imaging system is normally interpreted.

So augmentation is not “make random changes.” It is a task-specific assumption:

this transformation should preserve the target meaning.

Apply augmentation only on the training path

Validation and test sets are meant to provide stable evidence about unseen data.

If random augmentation is also applied during evaluation, the measured score can change because the evaluation inputs changed, not because the model changed.

Training may use random augmentation to expose variation. Evaluation should normally use a fixed, documented preprocessing path so runs can be compared fairly.

Quick Check

1. When is an augmentation unsafe?

Whenever the transformation is deterministic instead of randomWhen it changes the correct label meaningWhenever it changes low-level pixel values, even if the class meaning stays the same

2. What evidence most directly tests whether an augmentation preserved the task label?

Average augmentation strength by itselfThe model's parameter countTransformed examples paired with their labels

3. What does a valid augmentation encode?

A task-specific claim that this change should not alter the correct answerA new class that the model should learn separatelyA guarantee that validation performance must improve

0 of 3 questions answered.

Key Takeaways

• Augmentation encodes task-specific invariances.
• The transformed example must still deserve its label.
• A popular transform can be safe for one task and wrong for another.
• Bad augmentation is a data/semantics bug even when the code is correct.
• Inspect transformed examples with labels before tuning the model.

Next Lesson

Next, the important structure changes from two-dimensional position to ordered steps in time.

References

• Torchvision, Transforming and augmenting images.