Some new Alpha-related capabilities
Phil M Perry <philperry-N4erKOH/[email protected]> Tue, 25 Sep 2018 22:09:45 -0400
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello all, my first post into this mailing list. If I commit a faux pas, please allow for my unfamiliarity with your system. Some background: I am trying to improve the PNG image importation into PDF::Builder (a Perl-based PDF-creation library) by using libpng. There is a thin wrapper around libpng called Image::PNG::Libpng, maintained by someone else. This is to replace a very slow and limited pure-Perl solution. This is only to read a PNG file and stick it into a PDF; no PNG files are to be written. 1. The image data you return is uncompressed (inflated?). The old (Perl) code managed to unpack (unfilter, anyway) the data and pass it on -- still compressed -- to other routines and write to PDF. For example, one RGB file's data now goes from 0.5MB to 13MB in size, which is unacceptable. For the time being, I can add pure-Perl code to use flate compression on the unpacked data to slim it back down, but it would be nice (and much faster) to have a flag to order that the data supplied to me by libpng be compressed (either never uncompressed in the first place, or recompressed). "flate" compression is the minimum, as PDF supports that (LZW also supported, and possibly other methods). If this doesn't already exist, what are the prospects that this could be done? Obviously, it would be good to query what the existing compression is, so if it's something I can pass to PDF, I can ask that the existing one be used (possibly avoiding a decompression/recompression cycle). Or, I could specify a list of preferred compression methods, and if it's on this list, leave the data compressed (otherwise compress into the first method). I would need to know what the compression used on the image or Alpha channel is, so I can tell the PDF output routines. 2. When the PNG has an Alpha channel, the PDF routines require that I separate the Alpha into its own SMask array (sort of its own subimage, of the same size as the image), and leave the pure image data itself (gray or RGB triplets) separate to pass to PDF (preferably compressed). I can do this in pure Perl, but it makes the whole PNG-read routine about 50 times slower! What would be very handy would be a call to /separate/ (not /strip/) the Alpha data into its own array (and optionally compress it), and provide the pure image data in the normal manner. Is there already such a function? If not, does it sound like something that libpng could provide? Maybe I could always use the "STRIP_ALPHA" functionality, and the Alpha isn't actually /discarded/, but is accessible in a separate call. 3. I also need to process a palette image (cs=3) with optional tRNS chunk (provide Alpha per palette entry), but again I have to separate out a full Alpha subimage SMask, and this is slow. Support to expand the tRNS Alpha entries (for palette) to a full SMask would be great. Color types 0 and 2 already have a fairly clean tRNS implementation (simple Mask, rather than a full SMask), so nothing is needed for them. So basically, I'm looking for libpng to provide some high-speed help in returning already-compressed image (and Alpha) data, separating out any Alpha channel, and building a full Alpha SMask for palette+tRNS. For the time being, I'll have to do these things in pure Perl, which is very slow compared to libpng. Eventually I hope that libpng will do these things natively (if it doesn't do so already!) and Image::PNG::Libpng will be updated to support this. The owner of that package has stated that he's not interested in providing these functions outside of libpng (a thick wrapper instead of thin). I have searched your mailing list archives for keywords like "alpha" and "PDF", but didn't see anything that fit the bill. If I overlooked something, I beg a thousand pardons, but I'm not familiar with your terminology and may not have looked in the right way. PS: looking around, it's not clear whether any PDF reader properly supports 16-bit Alpha in PDF, so it's possible that a 16-bit Alpha value might have to be cut down to 8 bits, while leaving RGB or gray-scale at 16 bits per channel. _______________________________________________ png-mng-implement mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/png-mng-implement