Robert Sachunsky

Results 721 comments of Robert Sachunsky
trafficstars

> CI is broken (unrelated to this pull request). Yes, it seems that Facebook meanwhile stopped running their [wheel server](https://dl.fbaipublicfiles.com/detectron2/wheels)...

I agree in principle. But we know that core itself, which is used everywhere (CLI decorators), always imports shapely (via ocrd_validators, via ocrd) – before anything else. So that would...

Hi @masc-it! I get a feeling you expect `imgpath` and `outpath` to be a normal path name (perhaps even file name). But OCR-D uses METS-XML as container to manage documents...

See `make test` in https://github.com/bertsky/ocrd_detectron2/blob/master/Makefile or https://github.com/bertsky/ocrd_detectron2/blob/master/.github/workflows/python-app.yml (test results downloadable as [artifact](https://pipelines.actions.githubusercontent.com/serviceHosts/8608b8e2-f994-45a2-abb5-c7c135101f71/_apis/pipelines/1/runs/7/signedartifactscontent?artifactName=test-results&urlExpires=2023-03-21T16%3A05%3A08.4659323Z&urlSigningMethod=HMACV2&urlSignature=SX4KfqK8m4swGLmAN4n7wkeGjkH7F22QZCxolcWw19I%3D)). This runs a complete command line example on - 4 Detectron2 models - 2 OCR-D workspaces - Python...

The first try in [predict-async](https://github.com/bertsky/ocrd_detectron2/tree/predict-async) does not actually reduce wall time (it only reduces CPU seconds a bit). Perhaps we must first disentangle the page loop (make it a pipeline)....

> we do not differentiate between an `OcrdFile`'s `.local_filename` (which may be empty) and its `.url`. The latter could still be downloaded into the `document.directory` under some name and returned...

Not sure if this has the unintended consequence of changing remote URLs to local OTHER refs when in edit mode, because OCR-D core does not differentiate between `.url` and `.local_filename`...

Indeed, it's not more than a workaround as it stands. But apart from a multithreaded solution, couldn't we also replace remote images with placeholder images? These could be downloaded on...

> Can you try if the [support_remote_images](https://github.com/hnesk/browse-ocrd/tree/support_remote_images) branch works for you? > I implemented the threaded download solution there. Fantastic! That works perfectly well, and the wait time is no...

Should I close here, so you can proceed merging https://github.com/hnesk/browse-ocrd/tree/support_remote_images?