Sign in to continue learning
PyTorch: Fundamentals
24h5m
Welcome back. You've built a working Oxford Flowers pipeline, but how robust is it? What if your dataset contains corrupted images? Or what if your model has to recognize flowers in different or poor lighting? And how can you be sure that your pipeline even works before you start training for hours? In this video you'll learn the techniques to make your pipeline more reliable and your model more robust. You'll add data augmentation to handle real world variations, run a single batch test to catch errors early, and add error handling so that one bad image doesn't crash your entire training run. Let's start with data augmentation. So far your model has only seen the original Oxford Flowers images and they're all taken in similar conditions. To help it recognize flowers in more varied situations you can use data augmentation to generate new versions of those images. But why does that help? Well if your model only sees perfect centered roses in bright sunlight it might fail when someone shows it an image that's off-centered and in the shade. By showing the same flower from different angles in different lighting and with subtle changes you're teaching the model to focus on the essential features like the shape and the color rather than superficial details or the placement of the flower in the image itself. One way to do this is by saving flipped, rotated, or brightness adjusted copies as new files. But PyTorch has a smarter solution, on-the-fly augmentation. Instead of storing extra files, PyTorch applies random transformations every time an image is loaded. So for example in epoch 1 flower 42 might be flipped horizontally and then in epoch 2 it might be rotated slightly and darkened. This gives your model endless variation of training data without taking up extra storage. To make this work we'll define separate transforms for training and validation. This transform applied during training includes random changes as you can see in this code. Here you might add a horizontal flip or rotation or perhaps a color jitter which randomly will mess with the lighting and color of an image. You can also learn more about all of the other augmentations in the course resources. Now you can see here in validation I removed those augmentations. But why would you skip augmentation for validation? Well that's because you want to evaluate your model on consistent data. If validation images change randomly too, you couldn't tell whether performance changes were real due to real model improvements or just because of the different inputs. So now that you've added augmentation to make your model more robust, let's make your pipeline more robust too. And here's a frustrating scenario. Your training has been running smoothly and then two hours in, crash. One corrupted image brings everything down. Or maybe an image is technically valid but so small that it breaks your transforms. These issues are more common than you might think, especially with real world data sets. The Oxford Flowers data set is relatively clean but what if a file was only partially downloaded and corrupted or maybe somebody accidentally saved a broken image? Let's build a dataset that handles these problems gracefully. The first step is simple. Instead of crashing, we track errors. Then comes the important part, making get item resilient to bad data. It starts out as usual but now we can add a few safety checks. Verify confirms that the file is not corrupted. A size check skips tiny images that might break your transforms. Convert RGB fixes grayscale images that might have snuck in. But here's the key. What happens when something still goes wrong? Well instead of crashing, we can log exactly what went wrong. We can print a warning and then we can gracefully skip to the next image. That recursive call to __getitem__ will keep your pipeline moving even when files are broken. Finally we'll add a method to review the issues after training. So now when training completes, you can inspect which images had problems and then decide whether you want to fix them or leave them out. With error handling in place, your pipeline will not crash on bad data and you will have a clear record of what went wrong. But there's another subtle issue that can hurt your model's performance and that's overly aggressive augmentation. I've seen pipelines where the augmentations were so extreme that the flowers turned into unrecognizable blobs of color. And if your model can't tell what it's looking at, well it can't learn the features and then can't learn to classify. So how do you know if your augmentation is reasonable? Well one simple thing is just look at it. We can build a quick visualization tool. So every time you call dataset idx, the random augmentation will create a new variation. We can use that to show eight different versions of the same flower. But there's a catch. The images are normalized so we need to undo that before we display them. This code reverses normalize so you can actually see the colors instead of the distorted values. Now you can test your augmentation and here's what to look for. If the flower is clearly recognizable in each version then you're in good shape. If they all look identical then your augmentation probably isn't working. If they look like abstract art it's probably too aggressive. And if the images are all black or have wild colors it could be a normalization issue. So you've handled errors gracefully and verified the augmentations look reasonable. But here's a key question. How do you know your pipeline is actually working during training? You might have images that are never accessed because of a shuffling bug or maybe some images might be loaded far more often than others. Without monitoring you would never know. So let's add some lightweight tracking to shine a light on what's happening under the hood. This will extend your dataset to track which images get loaded, how often each one is accessed, how long each load takes, and then we'll add a simple method to review all of these stats and call it just after each training epoch. And this kind of monitoring can reveal shuffling bugs where some images are never accessed, performance issues such as slow load times, data imbalance where certain images are accessed too often. It's good for you to catch these problems early and it's better to do it now than discover after days of training. And that's it. You've transformed your Oxford Flowers pipeline from a basic loader into a production-ready system. If you want to see all of these pieces in action, check out the lab for this module where you'll build and explore the complete pipeline, putting your data through real-world tests before training even begins. You've prepared the data, now it's time to go build something amazing with it. Congratulations on mastering PyTorch's data pipeline and we'll see you in the next module.