Extract an API to predict the DPI used by img2pdf (with Pillow) #200

Open

mara0004 wants to merge 1 commit from mara0004/img2pdf:dpi_predictor into main

mara0004 commented

2024-08-25 15:22:49 +00:00

Contributor

When embedding img2pdf in a processing pipeline, it may be desired to predict the output size without actually converting the image, to defer any heavy processing to the export layer.

img2pdf applies some adjustments to the DPI provided by Pillow, so factor these out into a separate function that can be used by the embedder to calculate output size.

When embedding img2pdf in a processing pipeline, it may be desired to predict the output size without actually converting the image, to defer any heavy processing to the export layer. img2pdf applies some adjustments to the DPI provided by Pillow, so factor these out into a separate function that can be used by the embedder to calculate output size.

mara0004 added 1 commit 2024-08-25 15:22:51 +00:00

Extract an API to predict the DPI used by img2pdf 67f61d3fad

mara0004 commented

2024-08-26 19:12:25 +00:00

Author

Contributor

A possible issue I see with this is that it only covers the Pillow part, i.e. not the custom MIFF and JP2 parsers.

Pillow should be able to handle JP2 these days (at least current Linux wheels do), and I'm not too interested in MIFF, so this would already be helpful to me.

Yet, it might seem preferable to have a DPI function that could cover all code paths, but I'm not sure that's feasible, as the MIFF and JP2 DPI seem to be buried rather deeply in the control flow, or tied to other work.
And this would need a more complex API design than for just a Pillow image that can be seek()'ed by the caller...

A possible issue I see with this is that it only covers the Pillow part, i.e. not the custom MIFF and JP2 parsers. Pillow should be able to handle JP2 these days (at least current Linux wheels do), and I'm not too interested in MIFF, so this would already be helpful to me. Yet, it might seem preferable to have a DPI function that could cover all code paths, but I'm not sure that's feasible, as the MIFF and JP2 DPI seem to be buried rather deeply in the control flow, or tied to other work. And this would need a more complex API design than for just a Pillow image that can be seek()'ed by the caller...

josch commented

2024-08-27 08:22:35 +00:00

Owner

This change looks okay. Did you run the testsuite for your pull requests?

👍 1

mara0004 commented

2024-08-27 12:17:02 +00:00

Author

Contributor

Thanks. Yes, I did run the test suite.

The thing is, on my distro (Fedora 37), 10 tests are already failing on unaltered main.
This patch does not change the number of failing tests, but perhaps you had better confirm this did not break anything by running tests yourself, assuming there aren't any test suite issues on your end.

Thanks. Yes, I did run the test suite. The thing is, on my distro (Fedora 37), 10 tests are already failing on unaltered main. This patch does not change the number of failing tests, but perhaps you had better confirm this did not break anything by running tests yourself, assuming there aren't any test suite issues on your end.