Closed ai-fast-track closed 3 years ago
Because this error is thrown by albumentations, there is no way for adding the image filename to the stacktrace
Maybe you would like to add it in the autofix step?
AUTOFIX-START - ️🔨 Autofixing record with imageid: 2 <FILENAME> ️🔨
Another issue, we cannot assume that FILENAME is always present on the record and you would still need to filter the list of records to find it.
Do you think a function get_record_by_id(records, id)
would already solve this issue?
Yes, we should have a function get_record_by_id(records, id)
, or have a dictionary that stores bothe the ids and the corresponding images.
is this fixed now?
Not really, are you also facing this issue?
yes.
Are you able to share the specific image that is causing the error for you? We can use that to investigate further
ice vision doesn't provide at which particular image id we have faced this error.
Hi @ai-fast-track can you please assign this one to me?
Done @FraPochetti! Thanks a lot for looking into this issue.
Brainstorming out loud here.
For this error to happen, it means that xmax
/ymax
must be >
width
/height
of the image.
I don't see any other logical explanation.
So, it must be an annotation issue in the dataset, right?
If yes, why doesn't the AUTOFIX
pick it up?
I run the following snippet on the plantdoc
records and it finds nothing.
Kind of weird.
Does albumentations stretch boxes out of the image? Seems really awkward.
def check_boxes(r):
w, h = r["width"], r["height"]
ok = True
for box in r["bboxes"]:
xmax, ymax = box.xmax, box.ymax
if xmax > w:
print("X is wrong", xmax, w, r["filepath"])
ok = False
if ymax > h:
print("Y is wrong", ymax, h, r["filepath"])
ok = False
return ok, r
wrong = []
for record in train_records_csv:
ok, record = check_boxes(record)
if not ok:
wrong.append(record)
Does albumentations stretch boxes out of the image? Seems really awkward.
This is what I'm currently thinking, that albumentations itself is causing the issue, which indeed is really weird
If yes, why doesn't the AUTOFIX pick it up?
Exactly! Autofix would pick it up if it was an annotation issue! The only other explanation is if we have a bug there
The only other explanation is if we have a bug there
The code snippet I ran proves the contrary. All records seem fine.
Super weird if albumentations is the root cause.
ok, I have nailed down one wrong image in the plantdoc
dataset, and found something interesting.
Not sure the order of the records is going to be the same from my machine to yours (I am not shuffling), but I want to post everything for you guys to take a look as well.
parser_csv = PlantDocParser(train_labels, source=data_dir, class_map=class_map)
train_records_csv, valid_records_csv = parser_csv.parse(cache_filepath="plantdoc.pkl")
presize = 128
size = 64
train_tfms = tfms.A.Adapter([*tfms.A.aug_tfms(size=size, presize=presize), tfms.A.Normalize()])
train_ds = Dataset(train_records_csv, train_tfms)
train_dl = model_type.train_dl(train_ds, batch_size=1, num_workers=0, shuffle=False)
This is the incriminated record
Record:
- Image ID: 1363
- Filepath: /Users/francescopochetti/PlantDoc-Object-Detection-Dataset/TRAIN/flies.jpg
- Image size (width, height): (3888, 2592)
- Labels: [23]
- BBoxes: [<BBox (xmin:1, ymin:86, xmax:3806, ymax:2430)>]
which throws
ValueError: Expected x_max for bbox (0.00038580246913580245, 0.022119341563786008, 1.4683641975308641, 0.625, 0) to be in the range [0.0, 1.0], got 1.4683641975308641.
Now, if you look at the image (id=44
in train_records_csv
), something looks off
show_record(train_records_csv[44], display_bbox=True, figsize=(8, 10))
The record
reads - Image size (width, height): (3888, 2592)
, whereas it should clearly be (width, height): (2592, 3888)
, e.g. inverted width and height.
The flies.xml
annotation file seems screwed up too:
<annotation>
<folder> tomato leaf </folder>
<filename>flies.jpg</filename>
<path>/home/sohamp/Desktop/done/ tomato leaf /flies.jpg</path>
<source>
<database>Unknown</database>
</source>
<size>
<width>3888</width>
<height>2592</height>
<depth>3</depth>
</size>
<segmented>0</segmented>
<object>
<name>Tomato leaf</name>
<pose>Unspecified</pose>
<truncated>1</truncated>
<difficult>0</difficult>
<bndbox>
<xmin>1</xmin>
<ymin>86</ymin>
<xmax>3806</xmax>
<ymax>2430</ymax>
</bndbox>
</object>
</annotation>
From this SO thread I tried the following and it indeed seems the image is somehow rotated. According to this SO thread:
If you're using Pillow >= 6.0.0, you can use the built-in ImageOps.exif_transpose function do correctly rotate an image according to its exif tag
So, long story short, some images might be rotated! We need to find a way to rotate them back while reading them. Not sure. Any thoughts?
any thoughts on this error ? trying to get to the cause the image is there, why is it looking into "C:\Users\appveyor"
C:\Anaconda\envs\ice\lib\site-packages\icevision\core\record_mixins.py in _load(self)
79
80 def _load(self):
---> 81 self.img = open_img(self.filepath)
82 # TODO, HACK: is it correct to overwrite height and width here?
83 self.height, self.width, _ = self.img.shape
C:\Anaconda\envs\ice\lib\site-packages\icevision\utils\imageio.py in open_img(fn, gray)
8 raise ValueError(f"File {fn} does not exists")
9 color = cv2.COLOR_BGR2GRAY if gray else cv2.COLOR_BGR2RGB
---> 10 return cv2.cvtColor(cv2.imread(str(fn), cv2.IMREAD_UNCHANGED), color)
11
12
error: OpenCV(4.5.1) C:\Users\appveyor\AppData\Local\Temp\1\pip-req-build-vjyn6ztg\opencv\modules\imgproc\src\color.cpp:182: error: (-215:Assertion failed) !_src.empty() in function 'cv::cvtColor'
Hi @attibalazs, I don't think the error you're getting is related to this issue, can you open a separate issue?
why is it looking into "C:\Users\appveyor"
This is not where is looking for the image, but where opencv is installed and the error is being thrown
🐛 Bug
Describe the bug The error occur during training in this Plantdoc notebook:
learn.fine_tune(20, 0.012, freeze_epochs=3)
It occurs in:
Error stack: