Re: PNG loading time

Hi Hartmut,

> it's writepng.c in pdftex, which is very restrictive regarding "PNG
> copy":

Yes, I have found that, send Karl a patch to activate the debug logging
(the if (0) ...) on demand via env vars.

Checks for fast embeddability is
	pngcheck -v | grep -P 'RGB\+alpha|gAMA|sRGB|cHRM|iCCP|sBIT|bKGD|hIST|tRNS|sPLT|alpha|(?<!non-)interlaced'
(maybe ;-)

> $ convert x.ppm x.png    # PNG copy skipped because: cHRM bKGD

It works when doing
	magick IN.png -alpha off -strip +profile '*" OUT.png

or
	pngcrunch -rem alla -rem gAMA -rem sRGB -rem cHRM -rem iCCP \
		-rem sBIT -rem bKGB -rem hIST -rem tRNS -rem sPLT \
		-force IN.png OUT.png

I feel that the magick command was the fastest, but I might be wrong.

> When using ImageMagick convert to generate a PNG file, this tool will
> add cHRM and bKGD chunks (without need?), then it's slow. Netpbm

See above.

> The code p_png.c by Thomas Merz, from which "PNG copy" was gleaned,
> supports also palette and does so by added code. But this was not
> implemented in writepng.c (likely due to laziness).

Interesting, PDFLite library code, right?

> Now, experimentally allowing also palette for "PNG copy" without adding
> special palette chunk code in writepng.c seems to produce valid PDFs
> with palette info! :-) Unclear, why, risky. Adding "fast" palette copy

Is this depending on the PDF version used?
Do later PDF versions have more support for different (in particular
RGBA is very common!)?

> PNGs. Room for improvement...

Indeed. And a **huge** time win if implemented.

Best regards

Norbert

--
DI Dr Norbert Preining                        https://www.preining.info
arXiv / Cornell University   +   IFMGA Guide   +   TU Wien  +  TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13