The "estimate_orientation" contains some bugs

[WalidHadri-Iron]

Hi,

I was looking at the estimate_orientation function, I took the segmentation map for words given by a detector (db_restnet) passed it to the estimate_orientation but didn't get the correct angle even on easy examples. So I did some digging in the function, I found out that are some issues (I might be wrong or misunderstood things):

1. In this part of the code _, (w, h), angle = cv2.minAreaRect(contour), we assume after that w>h for horizontal lines, which is not all the time True, as the cv2.minAreaRect for the same countour could return w, h flipped with an angle difference of 90.
2. Less critical but still very important, is that the parameter ratio_threshold_for_lines should not have a fixed defined value like 5, but rather statistically depends on the seg map, on some examples I tested on, no contours were accepted, and the angle return was 0 when it was not.
3. n_ct picking up the first 50 contours could be enhanced, by instead picking up the contours with the most popular area (to put away noisy instances)

Let me know if you need more details or clarification, but to my findings the first point and second point are really messing up the function.

[felixdittrich92]

Hi @WalidHadri-Iron 👋,

If you test with rotated samples i highly suggest to test it with one of the fast models and the main branch (v0.9.0a0).
We have already faiced that the capacity of the current DB and LinkNet models is very limited (We started already to train the models from scratch with an updated augmentation pipeline)

We are always happy about new contributors so if you have optimizations in mind would you like to open a PR where we can iterate on ? :)

FYI: The current workflow works only for rotations in range -90 - 90 (no upside down) but we have already started to work on that support (only waiting for the TF models atm) --> https://github.com/mindee/doctr/pull/1553/files

Best regards,
Felix