Closed liuqc11 closed 3 years ago
Thanks for reporting that! We're looking into this problem and will fix it asap.
fix bug
I revised the mmocr/mmocr/models/textdet/postprocess/wrapper.py file line 502 as follows:
iou_list = np.zeros((len(index), ))
for i in range(len(index)):
B = polygons[index[i]][:-1]
try:
iou_list[i] = boundary_iou(A, B)
except ZeroDivisionError:
iou_list[i] = threshold + 0.01
continue
remove_index = np.where(iou_list > threshold)
index = np.delete(index, remove_index)
and temporarily solve the problem
The major cause of the problem is the unstable model - sometimes it generates invalid polygons whose area could be 0. Scaling the images somehow randomly alleviates the problem. I'll add a zero division handler to boundary_iou
which seems to be a better solution. Thank you again for the insights!
I'm still curious about what's the model's output though, as there can be many reasons zeroing the areas of polygons. Would you mind printing out A and B in your ZeroDivisionError handler and share the output with us? Thanks!
I'm still curious about what's the model's output though, as there can be many reasons zeroing the areas of polygons. Would you mind printing out A and B in your ZeroDivisionError handler and share the output with us? Thanks!
No problem, I just test the eval datasets of ICDAR2017-MLT with epoch_55.pth, I simply reproduce with the
type='MultiScaleFlipAug',
img_scale=(2260, 2260),
the output log when the ZeroDivisionError occurs is as follows.
loading annotations into memory...
Done (t=0.25s)
creating index...
index created!
Use load_from_local loader
[>>>>>>>>>>>>>>>>> ] 633/1800, 1.9 task/s, elapsed: 336s, ETA: 620sA is [136. 834. 136. 834. 136. 835. 137. 835. 138. 835. 138. 835. 139. 834.
140. 834. 141. 833. 142. 832. 142. 832. 142. 832. 142. 833. 142. 834.
141. 835. 141. 835. 140. 835. 140. 835. 139. 835. 139. 834. 138. 834.
138. 833. 137. 833. 137. 834. 136. 834. 136. 834. 136. 834. 136. 833.
135. 833. 134. 833. 133. 833. 132. 833. 131. 834. 130. 834. 129. 835.
129. 835. 129. 835. 129. 834. 130. 833. 130. 833. 131. 832. 131. 832.
132. 832. 132. 833. 133. 834. 133. 834. 134. 835. 134. 835. 135. 834.
135. 834.]
B is [133. 834. 133. 834. 133. 835. 133. 836. 134. 836. 135. 836. 136. 835.
137. 834. 138. 834. 138. 833. 139. 833. 138. 833. 138. 834. 137. 835.
137. 836. 137. 836. 136. 836. 136. 836. 136. 836. 136. 835. 135. 835.
135. 835. 134. 835. 134. 835. 133. 835. 133. 835. 133. 835. 133. 835.
133. 834. 132. 834. 131. 834. 130. 835. 129. 836. 128. 837. 128. 837.
128. 837. 128. 837. 129. 836. 130. 834. 130. 833. 130. 833. 131. 833.
131. 833. 131. 833. 131. 834. 131. 834. 132. 834. 132. 834. 133. 834.
133. 833.]
I calculate the area of A and B using Polygon A.area() = 0.5 B.area() = 1.5 intersection_A_B = 2.0 and union_A_B = A.area() + B.area() - intersection_A_B = 0
Thanks so much for the feedback! Both polygons have self-intersections and thus are invalid, which should have been handled. I'll fix this in the PR soon.
I tried to train FCENet with ICDAR2017-MLT, and I revised the config file fcenet_r50dcnv2_fpn_1500e_ctw1500.py for training. the config file is as follows. It did well in the first 20 epoches.
Describe the bug and Error traceback When evaluating the validation datasets on ICDAR2017-MLT,sometimes it occurs the ZeroDivisionError: float division by zero error. The error log is as follows.
Reproduction When the training process is broken, I tried to test on the latest epoth checkpoint, and I can reproduct the bug with the following command.
Environment
My environment is as follows.
Bug fix I have tried to read the code in mmocr/mmocr/core/evaluation/utils.py, and I guess the bug occurs because the utils.py does not consider when poly_union(poly_det, poly_gt) is zero, it is because in the config file test_pipeline,
The so called 'MultiScaleFlipAug' (Maybe inherited from MMDetection), can see in the Source code for mmdet.datasets.pipelines.test_time_aug does not consider the situation that sometimes Random crop error: ZeroDivisionError: float division by zero, if I revise the img_scale with a larger number in the 'MultiScaleFlipAug' config, sometimes it works. I guess it works because the image size in the eval datasets of ICDAR2017-MLT varies from
300*104
to4128*3096
, if the img_scale is too small, the 'MultiScaleFlipAug' might produce a picture with no text for evalutating or testing? But I suggest to revise the mmocr/mmocr/core/evaluation/utils.py file to go pass those poly_union(poly_det, poly_gt) zero