-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YOLO format without normalization and denormalization #924
Conversation
…tion to prevent rounding errors
@Dipet @ternaus what's the current status of the YOLO normalization bug with Albumentations? I have a YOLOv5 Albumentations PR in progress in ultralytics/yolov5#3882, but scanning the YOLO-related issues here in the albumentations repo raises some concerns currently. Can you explain the problem and the solution roadmap if this has not been resolved already? Thanks! |
@Dipet @ternaus is this PR present in v1.0.2? I'm getting this error today using v1.0.2 when training with the new YOLOv5 integration, and I'm certain that none of the YOLOv5 labels are out of bounds, as we strictly check for this on dataloader init.
EDIT: Another anomaly here is that I have no spatial transforms, so I don't see why the bounding boxes would be examined or checked/modified by Albumentations. The transforms I use are here: self.transform = A.Compose([
A.CLAHE(p=0.1),
A.RandomBrightnessContrast(p=0.0),
A.RandomGamma(p=0.0),
A.Blur(p=0.0),
A.MedianBlur(p=0.0),
A.ToGray(p=0.0),
A.ImageCompression(quality_lower=75, p=0.0),
], |
@Dipet @ternaus I modified all probabilities to 0.0, but somehow I am still seeing the same error from albumentations. Now I'm doubly confused about why the boxes are being examined when 1) all probabilities are 0.0, and 2 ) there are no spatial transforms present that would affect the bboxes. self.transform = A.Compose([
A.CLAHE(p=0.0),
A.RandomBrightnessContrast(p=0.0),
A.RandomGamma(p=0.0),
A.Blur(p=0.0),
A.MedianBlur(p=0.0),
A.ToGray(p=0.0),
A.ImageCompression(quality_lower=75, p=0.0),
], |
@Dipet @ternaus to double check that YOLO is not creating out of bounds labels somehow I inserted this code right before the albumentations call: if self.augment:
if np.any(labels[:, 1:5] > 1.0): # bboxes > 1.0
print(labels[:, 1:5])
# Albumentations
img, labels = self.albumentations(img, labels) And during my training nothing is printed before the albumentations error. So I suspect that albumentations is performing some operations on the labels that are causing them to lose numerical precision, even though no augmentations are asked for (probabilities are all zeros), and even though no spatial transforms are called for (labels should never change). Since I see this with v1.0.2, which appears to include this PR, I would say that this PR has not resolved the issue. |
This looks like float numbers rounding error, because This check is incorrect because it is doesn't check real bbox coordinates. Albumentations uses internal bbox format - some kind of normalized pascal_voc. x, y, h, w = bbox
x1 = x - w / 2
x2 = x1 + w
y1 = y - h / 2
y2 = y1 + h
if x1 < 0 or x2 > 1 or y1 < 0 or y2 > 1:
print(f"Bbbox greater than image: {[x1, y1, x2, y2]}") |
We have simplified our code and so bboxes and keypoints preprocessors will now be called regardless of whether dual transforms exist in the pipeline or not. |
@Dipet it seems like float32 loses precision on xyxy to xywh and back conversions resulting in the error. I didn't find a good solution so I simply implemented a clip with epsilon in 'Numerical stability fix for Albumentations' PR ultralytics/yolov5#3958. This adds about 50 us of overhead per image unfortunately in the dataloader. An alternative might be to implement an epsilon value in your Albumentation checks, i.e. for normalized data this might be something like: eps = 1E-6
assert -eps < x < (1 + eps) rather than the current hard bounds: assert 0.0 < x < 1.0 |
Hey @glenn-jocher We have released the |
@creafz thanks! I've updated our requirements to 1.0.3 in ultralytics/yolov5#4068. |
|
My issue was that I:
before the transformations. Albumentations expect the image in |
Check if your bbox is inside the image. Here's a short piece of code I wrote to check that.
|
I am facing below error -> |
@sainisatish me too....
|
@PawelKinczyk As of now I have dropped the images that display the mention error. |
@sainisatish yeah I did the same but in 500 data I dropped 60 images... |
This comment was helpful for me.
|
Since
yolo
andalbumentations
are normalized formats, we don't need to normalize and denormalize the values in the conversion step.The previous approach gave round-off errors.
These changes should fix the following issues:
convert_bbox_to_albumentations
#883