Robert Sachunsky

I wonder if it would be much effort to incorporate [gputil](https://github.com/anderskm/gputil) for (avg/peak) GPU memory usage statistics. (Or perhaps one could add it to memory_profiler as an alternative `backend`?)

> I wonder if it would be much effort to incorporate [gputil](https://github.com/anderskm/gputil) for (avg/peak) GPU memory usage statistics. (Or perhaps one could add it to memory_profiler as an alternative `backend`?)...

@kba we could really use that prior to #875. Would you consider fast-tracking this?

That's exactly what I have already proposed [here](https://github.com/OCR-D/core/issues/376#issuecomment-562349028) a while ago: > Perhaps we should start adding other mechanisms that affect all processors equally (like the loglevel override): > ......

> Any reason not to include in the next release together with #744 and #753? Just to differentiate purely technical changes (the other PRs) from functional ones / new behaviour...

Also not behaving in a useful way: without `-I`, whatever is specified as `DEST` does **not** get used directly as output directory. Instead, a **new** subdirectory with a randomized name...

I see the need, too. But we already rely on core's `OcrdExif` info to pass into Tesseract. Shouldn't this override be available to all processors, @kba?

> Yes, but it's not trivial I'm afraid. My idea would be to allow overriding the pixel density values in the OcrdExif constructor but that gets called in workspace methods...

Anyway, IMO this issue should be transferred to core or spec, since it involves/affects more people/projects.

At least for the DPI override, another processor-independent mechanism could be to have a dedicated processor earlier in the pipeline writing `/PcGts/Page/@imageXResolution` as an override to the image metadata parsed...