test image label shift

[lucasjinreal]

I have train image label normal but test image label shift, how could that possible? i have exactly same number of images and labels:

Some normal, some shifted.

While train is normal. What's the problem could be?

[glenn-jocher]

@jinfagang unless you can you reproduce this on COCO, your labels are the problem.

[lucasjinreal]

128

[glenn-jocher]

You should clone the repo again, something is wrong with your local version.

[glenn-jocher]

Also the colab notebook shows easy examples of training.

[lucasjinreal]

@glenn-jocher Hi, I found it caused by I have not same length images and labels in the directory.

What should I do if I have multiple batchs data, I placed all images in a single folder and very batch label in a different dir, and every time I using a different batch, I will soft link that batch labels to labels folder.

In this case, it can not load properly since their length not same, how to make it workable if I dont' want make many copies of images. (which waste disk space and not orgniseable)

[glenn-jocher]

@jinfagang yes I understand. The repo caches labels into *.npy files for faster loading. Perhaps a rework of this is in order for greater flexibility.

A quick fix is to delete the *.npy files and use text labels instead, or to update the dataloader to ignore *.npy files:

yolov5/utils/datasets.py

Lines 332 to 341 in c14368d

	np_labels_path = str(Path(self.label_files[0]).parent) + '.npy' # saved labels in *.npy file
	if os.path.isfile(np_labels_path):
	s = np_labels_path # print string
	x = np.load(np_labels_path, allow_pickle=True)
	if len(x) == n:
	self.labels = x
	labels_loaded = True
	else:
	s = path.replace('images', 'labels')

[balag59]

@jinfagang yes I understand. The repo caches labels into *.npy files for faster loading. Perhaps a rework of this is in order for greater flexibility.

A quick fix is to delete the *.npy files and use text labels instead, or to update the dataloader to ignore *.npy files:

yolov5/utils/datasets.py

Lines 332 to 341 in c14368d

	np_labels_path = str(Path(self.label_files[0]).parent) + '.npy' # saved labels in *.npy file
	if os.path.isfile(np_labels_path):
	s = np_labels_path # print string
	x = np.load(np_labels_path, allow_pickle=True)
	if len(x) == n:
	self.labels = x
	labels_loaded = True
	else:
	s = path.replace('images', 'labels')

@glenn-jocher Thank you for your work! I seem to be facing the same issue currently. Has there been any fix that's been attempted to resolve this? I've commented out the part in dataset.py where l is created from the npy file if labels_loaded=True so that l is created directly from the txt files. However, the visualized training batch 0 and 1 still seem to suffer from this issue.

Will this affect only the visualizations or will the predictions be affected too?
Is there anything else that can I do to ensure that this doesn't happen?

[glenn-jocher]

@balag59 ha, the visualizations are not there to look pretty, they are showing you the actual data used for training. If they are not correct, your training won't be correct. If you delete npy files and are still seeing problems, then your actual labels are likely problematic. I'm working on a major upgrade of label caching and loading. This should be done this week or next week.

In the meantime start from the tutorial, which works well, and make sure your custom dataset is aligned exactly the same format and directory structure as coco128. You can inspect coco128 in Kaggle datasets also:
https://www.kaggle.com/ultralytics/coco128

[balag59]

@balag59 ha, the visualizations are not there to look pretty, they are showing you the actual data used for training. If they are not correct, your training won't be correct. If you delete npy files and are still seeing problems, then your actual labels are likely problematic. I'm working on a major upgrade of label caching and loading. This should be done this week or next week.

In the meantime start from the tutorial, which works well, and make sure your custom dataset is aligned exactly the same format and directory structure as coco128. You can inspect coco128 in Kaggle datasets also:
https://www.kaggle.com/ultralytics/coco128

@glenn-jocher Thank you for the prompt response! I have used your yolov3 implementation before on custom datasets extensively and it worked great and this preparation here is very similar to that except the yml part. This dataset is a collection of 4 datasets(one of them being coco) and there seems to be a weird issue where the image shown and the name for the image shown itself don't match. I've added a prefix to each of the other 3 datasets and none to coco so I know where each image is from. Could there be an issue of a mismatch between the images and labels? The number of images and labels in the train folder are not the same.I'm using a single class only( people class).Here is what the visualizations look like:

[glenn-jocher]

Yes it may be related to a different number of images and labels. The yolov5 repo has updates that removed the need to create a list of images used for training, you can now simply supply an /images folder in your data.yaml file, and it will look for any labels in a corresponding /labels folder. This is how coco128 works.

[balag59]

Yes it may be related to a different number of images and labels. The yolov5 repo has updates that removed the need to create a list of images used for training, you can now simply supply an /images folder in your data.yaml file, and it will look for any labels in a corresponding /labels folder. This is how coco128 works.

I'm aware and that is that is what I'm doing right now. I've just given the path to the images folder in the yml file. This is still happening.Would creating a list make any difference or is there something else that I need to try?

[MarioDuran]

Hi @balag59 if the number of images and labels of your custom dataset is less than 1000, there is no problem, but if you have more than 1000 images, you will need to fill your custom dataset with new or repeated data, so you end up with a custom dataset of size in multiples of 1000.

at least this workaround is working for me. hope it helps.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.