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