Search before asking
User problem
Would the maintainers be open to a focused notebook showing how to take a Roboflow object-detection export through a safe, inspectable augmentation step and produce a train-ready derived dataset without breaking the relationship between bounding boxes and class IDs?
Roboflow makes it straightforward to download a labeled dataset in a training format. Once a user adds an external geometric augmentation step, however, the image, box coordinates, class IDs, class-name mapping, and output dataset layout all have to remain consistent. A transform that changes the image but mishandles a box or its class ID can silently corrupt training data.
The useful example is therefore the complete dataset boundary, not a minimal A.Compose snippet. AlbumentationsX would transform each image, its YOLO-format boxes, and their class IDs together. The Roboflow workflow and Supervision visualization would make the resulting dataset directly usable and inspectable by the notebook reader.
Proposed outcome
The notebook would:
- download a small public object-detection dataset through the existing Roboflow workflow in YOLO format;
- read the training images, normalized box coordinates, class IDs, and class-name mapping from the export;
- define a bounded AlbumentationsX training policy with
A.BboxParams(coord_format="yolo", label_fields=["class_labels"]);
- derive a stable per-sample
invocation_seed, so rerunning or reordering dataset generation does not change a sample unexpectedly;
- apply the policy to each training image, box list, and class-ID list in one call;
- validate that box and label counts still match and that the returned YOLO coordinates remain valid;
- write the transformed images and labels to a parallel YOLO dataset while preserving the class mapping and leaving validation/test data unchanged;
- visualize representative original and transformed samples with Supervision; and
- show the generated dataset path and
data.yaml that a compatible trainer can consume, without adding a model-training loop to the notebook.
The user outcome would be a reproducible derived dataset whose annotations have been checked visually and structurally before training. The notebook would also state the annotation format at each boundary rather than hiding conversions inside helper code.
Repository scope
The notebook would be self-contained for Colab and would not change Roboflow packages or existing tutorials. Following the contributor guide, the pull request would add one notebook under notebooks/, one CSV entry, and the regenerated README table. It would make no performance or superiority claims.
Dependency details
AlbumentationsX's current public release is AGPL-3.0-only and requires PyTorch to be installed. PyTorch is intentionally not selected by the package metadata because users need the CPU, CUDA, or MPS build appropriate for their environment. I am asking before preparing the notebook so the maintainers can decide whether those dependency constraints are acceptable for this repository.
If this workflow fits Roboflow Notebooks, I can prepare and run the pull request end to end.
Are you willing to submit a PR?
Search before asking
User problem
Would the maintainers be open to a focused notebook showing how to take a Roboflow object-detection export through a safe, inspectable augmentation step and produce a train-ready derived dataset without breaking the relationship between bounding boxes and class IDs?
Roboflow makes it straightforward to download a labeled dataset in a training format. Once a user adds an external geometric augmentation step, however, the image, box coordinates, class IDs, class-name mapping, and output dataset layout all have to remain consistent. A transform that changes the image but mishandles a box or its class ID can silently corrupt training data.
The useful example is therefore the complete dataset boundary, not a minimal
A.Composesnippet. AlbumentationsX would transform each image, its YOLO-format boxes, and their class IDs together. The Roboflow workflow and Supervision visualization would make the resulting dataset directly usable and inspectable by the notebook reader.Proposed outcome
The notebook would:
A.BboxParams(coord_format="yolo", label_fields=["class_labels"]);invocation_seed, so rerunning or reordering dataset generation does not change a sample unexpectedly;data.yamlthat a compatible trainer can consume, without adding a model-training loop to the notebook.The user outcome would be a reproducible derived dataset whose annotations have been checked visually and structurally before training. The notebook would also state the annotation format at each boundary rather than hiding conversions inside helper code.
Repository scope
The notebook would be self-contained for Colab and would not change Roboflow packages or existing tutorials. Following the contributor guide, the pull request would add one notebook under
notebooks/, one CSV entry, and the regenerated README table. It would make no performance or superiority claims.Dependency details
AlbumentationsX's current public release is AGPL-3.0-only and requires PyTorch to be installed. PyTorch is intentionally not selected by the package metadata because users need the CPU, CUDA, or MPS build appropriate for their environment. I am asking before preparing the notebook so the maintainers can decide whether those dependency constraints are acceptable for this repository.
If this workflow fits Roboflow Notebooks, I can prepare and run the pull request end to end.
Are you willing to submit a PR?