-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Got exception using ocrd_detectron 2 with ocrd_all Release v2022-12-01 #15
Comments
Can you please show the contents of your model file |
It is a VERY BIG file:
And, I have not downloaded in advance (I have thought, that this is done automatically, when I use --> So, maybe I should do ?
And, now it see the output of
|
No, we have a PR for that OCR-D/core#799 but it got delayed because it is difficult to test. To me it looks like the data got corrupted during download. Try
|
No, that one seems correct. I also believe some earlier download attempt must have been corrupted. |
Has not helped - still VERY BIG file.
|
That is to be expected, it's a ZIP file containing a huge neural network (model itself is 797 MiB). But does it work now with the processor, i.e. has the bitflip been corrected by redownloading? |
Sorry, forgot to mention: I still get the same Exception:
|
This is still strange for me, as I would expect to get the unzipped-yaml file (which should a be very small text file) |
Now, I have used
@kba , @bertsky : If you like, we can do a VC, where I can show this directly ... |
you misspelled. |
oops :-( |
indeed, it should. Trying to reproduce with most recent version of ocrd_detectron2 (or did you say most recent version of ocrd_all?)... |
Most recent version of |
Sorry, next try - but still not working:
|
I can confirm the extraction of the zip-file does not work with resmgr in core v2.43. There's the correct |
sry, the URL does not work with wget. It seems Dropbox forces you to interact with the download button, which yields a temporary download link. Too bad. What should we do? |
I will try out |
me bad. The problem was that I misspelled the URL in the tool json ( Fixed on master. |
@stefanCCS can you please try again (both examples) after updating (in the usual way, i.e. git pull of the submodule, then remake ocrd-detectron2-segment in the main module)? |
With
Which might be related to:
Which might be not exactly the same name as for the JSON: |
No, it does not, the |
Yes, and it was ill-conceived to begin with. Just because the URL is a zip-file does not mean the resource itself must be. On the contrary, But that changes the question to: why did resmgr download not extract the file in the first place?? |
Or am I getting even more confused now? What should resmgr care if a file is an archive or not, except for the purpose of extracting it at install-time? |
Because it did not know that it was an archive, so downloaded it and was done for the day.
The |
ok, thanks for clarification! So it is correct now (on master). Alas:
Also ambiguous: the |
@kba it seems that zip files have never been supported in resmgr to date. Should I open an issue? |
Yeah, that's why the type was originally
It's only used for the download bar. OCR-D/spec#233 |
After updating I still have troubles using model "PubLayNet_R_50_FPN_3x_JPLeoRX", where I get the following error (some name mismatching):
--> Maybe the json-Preset-File is not correct? |
And/or another try:
And got this:
--> Please clarify. |
I get the same, if I manually
|
This seems to be an issue with _BASE_: "../Base-RCNN-FPN.yaml" which should be _BASE_: "../configs/Base-RCNN-FPN.yaml" I think. That solves the FileNotFoundError for me. Unfortunately, this still gives me So I think this is an issue with the third-party models themselves, not ocrd_detectron2. |
@kba: Concerning
|
Well, I have put a soft link in all five places - as you can see here:
--> unfortunately, this has no worked :-( I have create a softlink for a whole config folder in temp like this
--> I have made this, because my error I have got now always was this:
--> this has worked, but I do not understand, if this is always the case, or in general, what is the logic behind.
--> So, what is the general solution? |
Yes, some model providers make crazy assumptions on where in the original Detectron2 repo your CWD is. That's why I already have to do a temporary
Indeed, this particular config is even worse. I took it from https://github.com/JPLeoRX/detectron2-publaynet. They help themselves by using the vanilla COCO config (which is for photo scenery, not for PubLayNet document images), but overriding the Since this applies to all JPLeoRX's models, and they are trained on PubLayNet no other than hpanwar08's, I think it would suffice to just switch over to those configs. I'll make a fix. |
the PubLayNet/JPLeoRX models should be fixed with 07fbdbf now. @stefanCCS could you please reinstall, redownload and try again? |
@kba , @bertsky : |
Sure, the next ocrd_all will certainly update ocrd_detectron2 to 0.1.5. (You'll still need to run |
I have got an exception using
ocrd-detectron2-segment
as follows - please clarify (I can provide workspace, if needed):The text was updated successfully, but these errors were encountered: