[NTG-pdftex] Re: Slow PNG inclusion with pdfLaTeX

[Taco Hoekwater]

Hi,

I just uploaded a new patch version (twice, sorry). I felt had
to introduce a new primitive

        \pdfoptionimageapplygamma = <0,1,2>

because otherwise almost all images would be rejected because
of gamma processing. Values:

	0 - never do gamma, i.e. same as versions < 1.21a
         1 - only do gamma if it would not break fast reading
         2 - always do gamma

In order to be acceptable for native copying, the following
constraints must be met:

* minor pdf version must be at least 2
* gray conversion must not be needed.
* if apply gamma is "2", the 'gamma delta' must be near zero
* the image file format must not be interlaced
* the color bit depth must be 8 or less, unless pdf minor is >=5
* the image may not have an alpha channel nor 'gif' transparancy.

The test suite (the variant I use) gives me 78 native file
inclusions with values 0 or 1 for 'apply gamma', and 54 files
with value 2 in 8bit color mode; (these numbers are resp. 98
and 69 in 16bit color mode).


Of course I also ran a speed test:

   $ ls -l hellhuge.png
   -rw-r--r--  1 taco users 12639474 Feb 28 15:23 hellhuge.png
   $ ./pngcheck hellhuge.png
   OK: hellhuge.png (5120x5120, 24-bit RGB, non-interlaced, 83.9%).

   $ time pdfetex \&cont-en fasthuge.tex
   Output written on fasthuge.pdf (1 page, 12626572 bytes).
   Transcript written on fasthuge.log.
   0.31user 0.27system 0:02.27elapsed 25%CPU

   $ time pdfetex \&cont-en slowhuge.tex
   Output written on slowhuge.pdf (1 page, 25379598 bytes).
   Transcript written on slowhuge.log.
   25.86user 1.58system 0:34.68elapsed 79%CPU

Greetings, Taco


Hartmut Henkel wrote:
> Hi Taco,
> 
> On Sun, 27 Feb 2005, Taco Hoekwater wrote:
> 
> 
>>I saw this on c.t.t. Shall I attempt a merge of yours and my patches?
> 
> 
> oh yes, that would be very nice! The reason why i hesitated with this
> patch is that it's not clear to me whether the libpng internally does
> any color transforms or other RGB number tweaking during decompression,
> maybe driven by some special PNG chunks in the image file. The fast
> reading patch would ignore these chunks. But until now i couldn't verify
> that libpng would do such calculations at all. Likely not; then the
> patch would be safe.
> 
> Regards, Hartmut