Questions about mosaic and affine transformation data augmentation.

[zhangtingyu11]

Search before asking

• I have searched the YOLOv5 issues and discussions and found no similar questions.

Question

I have been examining the source code of the data augmentation in YOLOv5, which utilizes mosaic and affine transformations. The mosaic method concatenates four images into a single image. In the augmentations.pyfile , the height and width are set to 640. However, the height and width of the concatenated image are 1280 and 1280, respectively.
From my understanding, the following code indicates that the rotation and scale operations should be performed around the center point. Therefore, a translation matrix is used to move the source point to the image center.

C = np.eye(3)
C[0, 2] = -im.shape[1] / 2  # x translation (pixels)
C[1, 2] = -im.shape[0] / 2  # y translation (pixels)

The translation matrix is defined as follows:

T = np.eye(3)
T[0, 2] = random.uniform(0.5 - translate, 0.5 + translate) * width  # x translation (pixels)
T[1, 2] = random.uniform(0.5 - translate, 0.5 + translate) * height  # y translation (pixels)

Is the 0.5 deliberately set? In my opinion, the source point should be translated from the image center to the top left point, and 0.5 should be changed to 1 since width and height is only the half of the concatenated image dimensions.
Additionally, I checked the image returned by the __getitem__ function, shown below:

Only the bottom right image is complete, while the other three are almost unrecognizable. Is this behavior consistent with the intended design?

Additional

No response

[github-actions]

👋 Hello @zhangtingyu11, thank you for your interest in YOLOv5 🚀! Please visit our ⭐️ Tutorials to get started, where you can find quickstart guides for simple tasks like Custom Data Training all the way to advanced concepts like Hyperparameter Evolution.

If this is a 🐛 Bug Report, please provide a minimum reproducible example to help us debug it.

If this is a custom training ❓ Question, please provide as much information as possible, including dataset image examples and training logs, and verify you are following our Tips for Best Training Results.

Requirements

Python>=3.8.0 with all requirements.txt installed including PyTorch>=1.8. To get started:

git clone https://github.com/ultralytics/yolov5  # clone
cd yolov5
pip install -r requirements.txt  # install

Environments

YOLOv5 may be run in any of the following up-to-date verified environments (with all dependencies including CUDA/CUDNN, Python and PyTorch preinstalled):

• Notebooks with free GPU:
• Google Cloud Deep Learning VM. See GCP Quickstart Guide
• Amazon Deep Learning AMI. See AWS Quickstart Guide
• Docker Image. See Docker Quickstart Guide

Status

If this badge is green, all YOLOv5 GitHub Actions Continuous Integration (CI) tests are currently passing. CI tests verify correct operation of YOLOv5 training, validation, inference, export and benchmarks on macOS, Windows, and Ubuntu every 24 hours and on every commit.

Introducing YOLOv8 🚀

We're excited to announce the launch of our latest state-of-the-art (SOTA) object detection model for 2023 - YOLOv8 🚀!

Designed to be fast, accurate, and easy to use, YOLOv8 is an ideal choice for a wide range of object detection, image segmentation and image classification tasks. With YOLOv8, you'll be able to quickly and accurately detect objects in real-time, streamline your workflows, and achieve new levels of accuracy in your projects.

Check out our YOLOv8 Docs for details and get started with:

pip install ultralytics

[glenn-jocher]

@zhangtingyu11 hello! Great questions regarding the data augmentation techniques used in YOLOv5.

1. Mosaic Augmentation: The mosaic augmentation indeed concatenates four images into one larger image. The dimensions you mentioned (1280x1280 for a 640x640 input) are correct, as each of the four images is resized to 640x640, and then arranged in a 2x2 grid to form the larger image. This helps the model learn from different scales and contexts by viewing multiple images at once.

2. Affine Transformations: Regarding the translation matrix, the 0.5 factor in the matrix is intentional. It's used to scale the translation values to keep the transformations centered around the middle of the image rather than shifting too far off, which helps in maintaining the context of the original images. Changing this to 1 would indeed move the source point more towards the edges, which might not be desirable as it could lead to more significant parts of the image being cropped out or translated out of the frame.

3. Image Output from __getitem__: The behavior you're observing where only the bottom right image appears complete while others do not, might suggest an issue with how the images are being combined or transformed. It's intended that all segments of the mosaic should be recognizable to some extent. If they are not, it could be due to overly aggressive transformations or misalignment in the augmentation code.

It might be helpful to review the parameters being used for transformations (like rotation, scaling, and translation values) to ensure they are within a reasonable range that preserves the integrity of the images. If the issue persists, consider adjusting these parameters slightly to see if it improves the output.

For a deeper dive into the architecture and augmentation strategies, you might find the YOLOv5 architecture description helpful: https://docs.ultralytics.com/yolov5/tutorials/architecture_description/

Hope this helps clarify your queries! 😊

[zhangtingyu11]

@zhangtingyu11 hello! Great questions regarding the data augmentation techniques used in YOLOv5.

1. Mosaic Augmentation: The mosaic augmentation indeed concatenates four images into one larger image. The dimensions you mentioned (1280x1280 for a 640x640 input) are correct, as each of the four images is resized to 640x640, and then arranged in a 2x2 grid to form the larger image. This helps the model learn from different scales and contexts by viewing multiple images at once.
2. Affine Transformations: Regarding the translation matrix, the 0.5 factor in the matrix is intentional. It's used to scale the translation values to keep the transformations centered around the middle of the image rather than shifting too far off, which helps in maintaining the context of the original images. Changing this to 1 would indeed move the source point more towards the edges, which might not be desirable as it could lead to more significant parts of the image being cropped out or translated out of the frame.
3. Image Output from __getitem__: The behavior you're observing where only the bottom right image appears complete while others do not, might suggest an issue with how the images are being combined or transformed. It's intended that all segments of the mosaic should be recognizable to some extent. If they are not, it could be due to overly aggressive transformations or misalignment in the augmentation code.

It might be helpful to review the parameters being used for transformations (like rotation, scaling, and translation values) to ensure they are within a reasonable range that preserves the integrity of the images. If the issue persists, consider adjusting these parameters slightly to see if it improves the output.

For a deeper dive into the architecture and augmentation strategies, you might find the YOLOv5 architecture description helpful: https://docs.ultralytics.com/yolov5/tutorials/architecture_description/

Hope this helps clarify your queries! 😊

Thank you for your response. I have a question regarding the warpAffine function. The dstsize parameter is set to (640, 640), while the size of the large concatenated image is (1280, 1280). This configuration results in cropping the image. If the concatenation point is in the middle of the image, each of the four smaller images will only contribute 1/4 of their area to the final image, assuming no additional affine transformations are applied.

Is this behavior reasonable? I believe the image should contain enough information for effective model training.

Would it be possible to use the minimum bounding rectangle that encompasses all four images, and then resize this rectangle to (640, 640)? I think this approach would retain more information compared to simple cropping, although resizing might affect the scale.

I would appreciate your advice on this matter.

[glenn-jocher]

Hello @zhangtingyu11! You've brought up a valid point regarding the handling of the concatenated image in the warpAffine function.

The current behavior where dstsize is set to (640, 640) indeed results in cropping the larger (1280, 1280) image, which can potentially lead to loss of valuable information from the peripheries of the individual images. This setup is primarily designed to maintain a consistent input size for the model, which is crucial for batch processing and GPU optimization.

Your suggestion to use the minimum bounding rectangle to encompass all four images and then resize it to (640, 640) is an interesting approach. It could help in retaining more contextual information from each of the four images, although, as you mentioned, resizing could affect the scale and aspect ratio of objects within the images, which might influence how the model learns object proportions and spatial relationships.

An alternative could be to adjust the affine transformation parameters to reduce the extent of translation and scaling, ensuring that more of each image is retained within the final 640x640 output. This approach would allow you to keep the current pipeline while minimizing information loss.

Experimenting with these configurations and observing their impact on model performance (e.g., validation loss, detection accuracy) would be the best way to determine the most effective strategy. Each dataset might behave differently under these transformations, so tuning according to your specific use case is recommended.

Hope this helps, and happy experimenting! 😊

[zhangtingyu11]

Hello @zhangtingyu11! You've brought up a valid point regarding the handling of the concatenated image in the warpAffine function.

The current behavior where dstsize is set to (640, 640) indeed results in cropping the larger (1280, 1280) image, which can potentially lead to loss of valuable information from the peripheries of the individual images. This setup is primarily designed to maintain a consistent input size for the model, which is crucial for batch processing and GPU optimization.

Your suggestion to use the minimum bounding rectangle to encompass all four images and then resize it to (640, 640) is an interesting approach. It could help in retaining more contextual information from each of the four images, although, as you mentioned, resizing could affect the scale and aspect ratio of objects within the images, which might influence how the model learns object proportions and spatial relationships.

An alternative could be to adjust the affine transformation parameters to reduce the extent of translation and scaling, ensuring that more of each image is retained within the final 640x640 output. This approach would allow you to keep the current pipeline while minimizing information loss.

Experimenting with these configurations and observing their impact on model performance (e.g., validation loss, detection accuracy) would be the best way to determine the most effective strategy. Each dataset might behave differently under these transformations, so tuning according to your specific use case is recommended.

Hope this helps, and happy experimenting! 😊

Thank you for your advice! I will try these configurations and test their performance.

[glenn-jocher]

You're welcome! I'm glad to hear you'll be experimenting with those configurations. If you have any more questions or need further assistance as you test, feel free to reach out. Happy coding and best of luck with your model tuning! 😊