-
Notifications
You must be signed in to change notification settings - Fork 3
Move to ocrd-segment-repair? #2
Comments
Yes, I think so too. It was unclear what exactly ocrd-segment-repair would do to my files other than my hypothetically added re-ordering operation. If ocrd-segment-repair is going down the "let the user choose a single operation" road, I'm happy to add this as one of those single operations. To explain: I needed this to fix problems with some hundred ground truth files. As I wanted to be careful with my ground truth files I wanted to exactly fix this problem, nothing more. Therefore I wrote a separate script and did not add the operation to ocrd-segment-repair. |
Yes, there's definitely going to be fine grained control of what checks and repair heuristics to use for ocrd-segment-repair. Let's delay this until we have baked ocrd-segment-evaluate (PRImA tools re-implementation) and found ourselves some useful module + data structures. |
Agreed. |
Shall we include this in ocrd_all or wait until you've decided whether/how to integrate with ocrd_segment? |
I'd say now is as good a time as ever for ocrd_all. (We want to give users the best possible processing options.) |
Since this is very OCR-D specific stuff, I would actually prefer this moved to |
Sure, but see above – nothing has changed from ocrd_segment's side so far. As soon as we have a good library structure there and self-explaining and orthogonal |
As I've closed #8 (Find a better name) in favor of merging it into some other tool: I suggest a very specific operation name of |
@bertsky wrote in #1:
The text was updated successfully, but these errors were encountered: