Robert Sachunsky

> Check the discussion here: [OCR-D/spec#208](https://github.com/OCR-D/spec/pull/208) Thanks, but I cannot see any arguments for _not_ providing a converter tool from the existing `ocrd process` workflow syntax to the Nextflow syntax...

> If I grok this correctly, the problem is that `make_file_id` is not aware of the `overwrite_mode` of the workspace and should behave differently. It should not try to avoid...

> IIUC you would replace > > ```python > mets_file = next(self.find_files(ID=ID), None) > ``` > > with > > ```python > mets_file = next(self.find_files(fileGrp=fileGrp, pageId=pageId) > ``` > >...

Can we get this moving @kba? #825 is still quite a blow you know...

You said re-review, which I did, but now you already merged without my suggestions…

Example stack trace: ``` Traceback (most recent call last): File "/build/core/ocrd/ocrd/processor/helpers.py", line 101, in run_api processor.process() File "/build/ocrd_segment/ocrd_segment/replace_original.py", line 78, in process mimetype='image/png') File "/build/core/ocrd/ocrd/workspace.py", line 820, in save_image_file image.save(image_bytes,...

> > and usually does not have an info['dpi'] > > Why can't we check whether such information is available? We could, but as I said: usually it is not....

> > We should definitely not write default values which we know to be wrong (I added the label `bug`). > > Okay, but that's probably a bug in Pillow's...

Sorry, I was imprecise: It could have been fixed in an earlier version already. I saw the following with 5.4.1 (leading up to this issue): ```sh python -c "import PIL.Image;...

@wrznr just convinced me that we should indeed take action to ensure core and modules comply with the spec (which requires PPI information to be kept for derived images, cf....