Document performance cost of using transparent PNG images #142
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As I hooked up img2pdf for the first time today in my project, I was surprised to see it was running quite slow converting a series of PNG images into PDF. My understanding was that since PNG images would be embedded directly into the PDFs without re-encoding, it should be very fast. I ran my code under a profiler and was surprised to see
img2pdf
seemed to be re-encoding the image into_png_data()
. After skimming that code I made a guess that using non-transparent images might avoid that step, which turned out to be correct.It would be helpful if this performance penalty were documented somewhere, or even explicitly warned about in the same log line about "...will be stored as a separate soft mask..." (which to me is PDF jargon I didn't understand the implications of).
(ps - thanks for such a great library!)
Good point! What do you think about this re-phrasing:
Does this make clear what happens?
That's an improvement, but from an image encoding newbie's perspective it would be even more helpful if it said something explicitly like 'Encoding separate soft mast (/SMask) to support transparency at a performance cost'.
As an aside, I wonder if it could be a nice option to automatically flatten transparent images, since I can't think of a use-case for transparent images in the "one-image-per-page" function I understand this library serves.
Also, it might be helpful to update the readme so the format-colorspace-result table has a separate entry for transparent PNGs, so the behavior is documented outside that log line
Everything done on a computer is "at a performance cost". The only thing not to have a performance cost is to do the same thing or to not do anything. How about replacing "Creating" by "Computing"?
That's why before support for transparent images was added, img2pdf would throw an error when you tried to convert images with transparency to PDF. The one thing that makes img2pdf special is, that it's lossless. That's why img2pdf will not remove the alpha channel from the input because that will be lossy. If you are fine with lossy conversions, then there are a lot of other tools that can convert images to PDF.
No separate entry is needed but the
PNG
line has to be changed so that it documentsdirect
inclusion only happens for input that doesn't have transparency:Those suggestions work for me. I think that doc change in particular would have led me to figuring out the issue much quicker. Thanks!