Hi Pawel, The main problem was not in your input: during the merge of pngextra.ch, the last change entry was not carried over to the main change file. To be precise, this bit is missing: @x @p procedure check_and_set_pdfoptionpdfminorversion; begin @y @p procedure check_and_set_pdfoptionpdfminorversion; begin fixed_gamma := fix_int(pdf_gamma, 0, 1000000); fixed_image_gamma := fix_int(pdf_image_gamma, 0, 1000000); fixed_image_hicolor := fix_int(pdf_option_pdf_image_hicolor, 0, 1); fixed_image_apply_gamma := fix_int(pdf_option_image_apply_gamma, 0, 1); @z Because of that, you always ended up with the compile-time defaults. Martin, can you look into this please? The minor problem is that the primitives behave like \pdfminorversion: they are document-global and should be set before any typesetting is done (the reason for that is that querying the image info and actually reading the image data are disjunct processes in pdftex). This should have been make clear in my documentation, I'm sorry. Greetings, Taco Pawel Jackowski wrote:
Hi Taco,
i've a problem with advanced PNG handling in pdfTeX-1.30-rc2. The attachement contains a sample with 16-bit PNG. As expected, /BitsPerComponent is 16 or 8, if the version of PDF is 1.5 or less than 1.5. Thats OK. But \pdfimagehicolor seems to be ignored. Regardless the value of \pdfimagehicolor, if \pdfminorversion is greater than 4, images are always loaded in 16-bit mode. Is it normal behaviour? If so, what is the usage \pdfimagehicolor?
The second problem is that I can't see any effects of applying gamma correction (also in the attachement). I always get (PNG copy) in log file, regardless \pdfimageapplygamma valuse.
Any clue what I'm doing wrong?
Greetings,