New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ready for Prime Time? #26

Closed
PhilterPaper opened this Issue Sep 13, 2018 · 19 comments

Comments

Projects
None yet
2 participants
@PhilterPaper

PhilterPaper commented Sep 13, 2018

I am supporting PDF::Builder (on GitHub and CPAN), which includes a pure Perl library for PNG image support (just reading, I think). It was originally on PDF::API2 (Builder is a fork), so if you have any familiarity with that product, that's a head start. There is a reported bug where RGBA support is hundreds of times slower than RGB image processing, so I am interested in finding a library that would foist most of the nitty gritty of PNG processing off on to someone else. Naturally, it would have to be reasonably complete (at least as complete as the current library, which isn't saying a whole lot), reasonably clean and fast, and supported. What is the state of Image::PNG::Libpng? I see that it has been stuck at release 0.45 for a while, which concerns me.

There's no guarantee that I'll be able to use it, as I will need to understand and remap PDF::Builder's entire PNG processing code into calls to the new libpng-using interface. I think the problem in the current pure Perl library is literally millions of calls to Perl's vec() call (only when handling RBGA), which may not be too fast.

By the way, how do you connect CPAN "Issues" to GitHub? My support is on GitHub, too so it would be nice to redirect CPAN to GitHub.

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 13, 2018

Owner
Owner

benkasminbullock commented Sep 13, 2018

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 13, 2018

Owner

Are you thinking about replacing this code with Image::PNG::Libpng?

https://metacpan.org/source/PMPERRY/PDF-Builder-3.010/lib/PDF/Builder/Resource/XObject/Image/PNG.pm

It will probably be faster than that. I'm not sure what you need to do with the data once it's read in though. The gain for you would be not using the Perl unprocess routine in that.

Owner

benkasminbullock commented Sep 13, 2018

Are you thinking about replacing this code with Image::PNG::Libpng?

https://metacpan.org/source/PMPERRY/PDF-Builder-3.010/lib/PDF/Builder/Resource/XObject/Image/PNG.pm

It will probably be faster than that. I'm not sure what you need to do with the data once it's read in though. The gain for you would be not using the Perl unprocess routine in that.

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 14, 2018

Yes, that's the module. Here's what it supposedly supports:

options: -notrans
No transparency -- ignore tRNS chunk if provided, ignore Alpha channel if provided.

Supported PNG types

  • (0) Gray scale of depth 1, 2, 4, or 8 bits per pixel (2, 4, 16, or 256 gray levels). 16 bps is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (2) RGB 24-bit truecolor with 8 bits per sample (16.7 million colors). 16 bps is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (3) Palette color with 1, 2, 4, or 8 bits per pixel depth (2, 4, 16, or 256 color table entries). 16 bpp is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (4) Gray scale of depth 8 bits per pixel plus 8 bit Alpha channel (256 gray levels and 256 levels of transparency). 16 bpp is not currently supported. The Alpha channel is ignored if the -notrans option is given. The tRNS chunk is not permitted.
  • (6) RGB 24-bit truecolor with 8 bits per sample (16.7 million colors) plus 8 bit Alpha channel (256 levels of transparency). 16 bps is not currently supported. The Alpha channel is ignored if the -notrans option is given. The tRNS chunk is not permitted.

Being able to support the currently unsupported bit depths would be a bonus (provided PDF can handle them!). The library should support in some manner ignoring transparency (Alpha channel or tRNS chunk) -- if I need to modify the data after it's been read in, as long as that's documented somewhere and overall it's faster than the current library, it's OK. This is for PDF output, and I don't think it can do any operations on combining images, so ignoring transparency may not be important. I don't know exactly what the final output is supposed to be that is turned over to other routines -- I guess I'll have to experiment a bit!

Anyway, if you think your library can support these requirements, I'll give it a try. Worst case, it doesn't, and I have to fall back to the current library. I can implement it so both are in use (if yours is installed), preferably using yours unless it encounters something it can't handle. Thanks much!

PhilterPaper commented Sep 14, 2018

Yes, that's the module. Here's what it supposedly supports:

options: -notrans
No transparency -- ignore tRNS chunk if provided, ignore Alpha channel if provided.

Supported PNG types

  • (0) Gray scale of depth 1, 2, 4, or 8 bits per pixel (2, 4, 16, or 256 gray levels). 16 bps is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (2) RGB 24-bit truecolor with 8 bits per sample (16.7 million colors). 16 bps is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (3) Palette color with 1, 2, 4, or 8 bits per pixel depth (2, 4, 16, or 256 color table entries). 16 bpp is not currently supported. Transparency via the tRNS chunk is allowed, unless the -notrans option is given.
  • (4) Gray scale of depth 8 bits per pixel plus 8 bit Alpha channel (256 gray levels and 256 levels of transparency). 16 bpp is not currently supported. The Alpha channel is ignored if the -notrans option is given. The tRNS chunk is not permitted.
  • (6) RGB 24-bit truecolor with 8 bits per sample (16.7 million colors) plus 8 bit Alpha channel (256 levels of transparency). 16 bps is not currently supported. The Alpha channel is ignored if the -notrans option is given. The tRNS chunk is not permitted.

Being able to support the currently unsupported bit depths would be a bonus (provided PDF can handle them!). The library should support in some manner ignoring transparency (Alpha channel or tRNS chunk) -- if I need to modify the data after it's been read in, as long as that's documented somewhere and overall it's faster than the current library, it's OK. This is for PDF output, and I don't think it can do any operations on combining images, so ignoring transparency may not be important. I don't know exactly what the final output is supposed to be that is turned over to other routines -- I guess I'll have to experiment a bit!

Anyway, if you think your library can support these requirements, I'll give it a try. Worst case, it doesn't, and I have to fall back to the current library. I can implement it so both are in use (if yours is installed), preferably using yours unless it encounters something it can't handle. Thanks much!

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 14, 2018

Owner

I think it should be able to do all the things you want. It's meant to be basically a Perl-ized libpng, and almost everything in libpng which seemed to be useful is supported. Let me know how it goes and if you get stuck I'll try to help.

Owner

benkasminbullock commented Sep 14, 2018

I think it should be able to do all the things you want. It's meant to be basically a Perl-ized libpng, and almost everything in libpng which seemed to be useful is supported. Let me know how it goes and if you get stuck I'll try to help.

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 14, 2018

Well, I tried the first step of installing Image::PNG::Libpng on my Windows 10 + Strawberry Perl 5.26, via the "cpan" "install Image::PNG::Libpng" command, and it failed. The first message is that Makefile.PL can't compile the source because "'cc' is not recognized as an internal or external command, operable program or batch file." Strawberry has a C compiler on it (named "gcc") that I can install other packages with -- have you tested on Strawberry? It then goes on to say that libpng is not installed -- it is (C:\strawberry\c\lib\libpng.a). My PDF::Builder package does not send C source, so I can't help with how to build the package. Thoughts?

PhilterPaper commented Sep 14, 2018

Well, I tried the first step of installing Image::PNG::Libpng on my Windows 10 + Strawberry Perl 5.26, via the "cpan" "install Image::PNG::Libpng" command, and it failed. The first message is that Makefile.PL can't compile the source because "'cc' is not recognized as an internal or external command, operable program or batch file." Strawberry has a C compiler on it (named "gcc") that I can install other packages with -- have you tested on Strawberry? It then goes on to say that libpng is not installed -- it is (C:\strawberry\c\lib\libpng.a). My PDF::Builder package does not send C source, so I can't help with how to build the package. Thoughts?

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 14, 2018

Owner

Thanks for the input.

As you correctly said, the use of cc to compile the program is a bug. This is in the file inc/CheckForLibPng.pm, it should be using $Config{cc} to get the same compiler as used to build Perl itself. I'm not sure about the other things. I have not installed this on Strawberry Perl and did not know that it featured libpng. There should be a way to compile it for that system, but it seems to need some special include path headers.

I also found that inc/CheckForLibPng.pm had not been put under version control at all, due to previous use of the inc directory for Devel::CheckLib, so this commit looks a bit strange:

commit 12ca2cb (HEAD -> master, origin/master)
Author: Ben Bullock benkasminbullock@gmail.com
Date: Fri Sep 14 11:54:10 2018 +0900

Put CheckForLibPng.pm under version control; bug with cc

This script had been developed extensively but never put under version control due to an error in .gitignore where inc/* was ignored. That dated from the time I was using Devel::CheckLib to build this system.

Also, this fixes a bug where CheckForLibPng was using cc not
$Config{cc} for the compiler.
Owner

benkasminbullock commented Sep 14, 2018

Thanks for the input.

As you correctly said, the use of cc to compile the program is a bug. This is in the file inc/CheckForLibPng.pm, it should be using $Config{cc} to get the same compiler as used to build Perl itself. I'm not sure about the other things. I have not installed this on Strawberry Perl and did not know that it featured libpng. There should be a way to compile it for that system, but it seems to need some special include path headers.

I also found that inc/CheckForLibPng.pm had not been put under version control at all, due to previous use of the inc directory for Devel::CheckLib, so this commit looks a bit strange:

commit 12ca2cb (HEAD -> master, origin/master)
Author: Ben Bullock benkasminbullock@gmail.com
Date: Fri Sep 14 11:54:10 2018 +0900

Put CheckForLibPng.pm under version control; bug with cc

This script had been developed extensively but never put under version control due to an error in .gitignore where inc/* was ignored. That dated from the time I was using Devel::CheckLib to build this system.

Also, this fixes a bug where CheckForLibPng was using cc not
$Config{cc} for the compiler.
@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 14, 2018

Owner

OK there was an error in the last commit, fixed here:

commit 9e54c8e (HEAD -> master, origin/master)
Author: Ben Bullock benkasminbullock@gmail.com
Date: Fri Sep 14 12:06:52 2018 +0900

Use the $cc variable not cc; die if no $cc found

Now I edit inc/CheckForLibPng.pm to the following lines:

my $png_lib_dir = 'C:/Strawberry/c/lib/';
my $png_include_dir = 'C:/Strawberry/c/include/libpng';

and it installed correctly and also did make test OK:

C:\Users\ben\Documents\Image-PNG-Libpng-0.45>gmake test
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- Libpng.bs blib\arch\auto\Image\PNG\Libpng\Libpng.bs 644
"C:\Strawberry\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/bKGD.t ........... ok
t/bogus.t .......... skipped: libpng version is 1.6.29
t/cHRM.t ........... ok
t/Const.t .......... ok
t/copy-all-png.t ... ok
t/functions.t ...... ok
t/gAMA.t ........... ok
t/get-internals.t .. ok
t/get-text.t ....... ok
t/hIST.t ........... ok
t/Libpng.t ......... ok
t/pHYs.t ........... ok
t/PLTE.t ........... ok
t/sBIT.t ........... ok
t/sCAL.t ........... ok
t/set-text.t ....... ok
t/sPLT.t ........... ok
t/supports.t ....... ok
t/tIME.t ........... ok
t/tRNS.t ........... ok
t/user-limits.t .... ok
All tests successful.
Files=21, Tests=274,  3 wallclock secs ( 0.06 usr +  0.00 sys =  0.06 CPU)
Result: PASS

C:\Users\ben\Documents\Image-PNG-Libpng-0.45>

The only thing left to do is to make it detect the strawberry perl lib locations automatically, then it should be OK.

Owner

benkasminbullock commented Sep 14, 2018

OK there was an error in the last commit, fixed here:

commit 9e54c8e (HEAD -> master, origin/master)
Author: Ben Bullock benkasminbullock@gmail.com
Date: Fri Sep 14 12:06:52 2018 +0900

Use the $cc variable not cc; die if no $cc found

Now I edit inc/CheckForLibPng.pm to the following lines:

my $png_lib_dir = 'C:/Strawberry/c/lib/';
my $png_include_dir = 'C:/Strawberry/c/include/libpng';

and it installed correctly and also did make test OK:

C:\Users\ben\Documents\Image-PNG-Libpng-0.45>gmake test
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- Libpng.bs blib\arch\auto\Image\PNG\Libpng\Libpng.bs 644
"C:\Strawberry\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/bKGD.t ........... ok
t/bogus.t .......... skipped: libpng version is 1.6.29
t/cHRM.t ........... ok
t/Const.t .......... ok
t/copy-all-png.t ... ok
t/functions.t ...... ok
t/gAMA.t ........... ok
t/get-internals.t .. ok
t/get-text.t ....... ok
t/hIST.t ........... ok
t/Libpng.t ......... ok
t/pHYs.t ........... ok
t/PLTE.t ........... ok
t/sBIT.t ........... ok
t/sCAL.t ........... ok
t/set-text.t ....... ok
t/sPLT.t ........... ok
t/supports.t ....... ok
t/tIME.t ........... ok
t/tRNS.t ........... ok
t/user-limits.t .... ok
All tests successful.
Files=21, Tests=274,  3 wallclock secs ( 0.06 usr +  0.00 sys =  0.06 CPU)
Result: PASS

C:\Users\ben\Documents\Image-PNG-Libpng-0.45>

The only thing left to do is to make it detect the strawberry perl lib locations automatically, then it should be OK.

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 14, 2018

Owner

After a bit of work, it seems that nothing more needs to be done to make it find any Strawberry Perl libraries, they seem to be found without any further effort. I've released a provisional testing version to CPAN, if you're still interested in using the module please download from the following link and try installing that.

https://cpan.metacpan.org/authors/id/B/BK/BKB/Image-PNG-Libpng-0.45_01.tar.gz

It works on my Strawberry Perl.

Owner

benkasminbullock commented Sep 14, 2018

After a bit of work, it seems that nothing more needs to be done to make it find any Strawberry Perl libraries, they seem to be found without any further effort. I've released a provisional testing version to CPAN, if you're still interested in using the module please download from the following link and try installing that.

https://cpan.metacpan.org/authors/id/B/BK/BKB/Image-PNG-Libpng-0.45_01.tar.gz

It works on my Strawberry Perl.

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 14, 2018

Owner

The first CPAN testers result on Windows has come through:

http://www.cpantesters.org/cpan/report/a7add179-6bf3-1014-b801-4147b78b2be9

Looks like it is working on Strawberry Perl now. It had never built on Windows before:

http://matrix.cpantesters.org/?dist=Image-PNG-Libpng%200.45

Even if nothing else comes from this discussion, I think that was a good result.

Owner

benkasminbullock commented Sep 14, 2018

The first CPAN testers result on Windows has come through:

http://www.cpantesters.org/cpan/report/a7add179-6bf3-1014-b801-4147b78b2be9

Looks like it is working on Strawberry Perl now. It had never built on Windows before:

http://matrix.cpantesters.org/?dist=Image-PNG-Libpng%200.45

Even if nothing else comes from this discussion, I think that was a good result.

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 14, 2018

Well, I've got something installed now. D/L the .tar.gz file onto my desktop, unpack it via 7-zip, cd to the dir and run perl Makefile.PL, gmake test, and gmake install. "cpan" claims that Image::PNG::Libpng 0.45_01 now exists. I see a new file Libpng.pm in the Strawberry lib/Image/PNG/ directory, as well as Const.pm, Libpng.pod, and memory-test.pl -- is anything else expected?

Time to start playing with this thing. I'll let you know how it turns out. Thanks much for the quick fix.

PhilterPaper commented Sep 14, 2018

Well, I've got something installed now. D/L the .tar.gz file onto my desktop, unpack it via 7-zip, cd to the dir and run perl Makefile.PL, gmake test, and gmake install. "cpan" claims that Image::PNG::Libpng 0.45_01 now exists. I see a new file Libpng.pm in the Strawberry lib/Image/PNG/ directory, as well as Const.pm, Libpng.pod, and memory-test.pl -- is anything else expected?

Time to start playing with this thing. I'll let you know how it turns out. Thanks much for the quick fix.

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 17, 2018

I've been working through it, comparing the Libpng interface to the old (pure Perl) code. It's messy, but I think if I just work very carefully through it, I can get it to function properly. It looks like the new (Libpng) functionality will be a superset of the old, which is an improvement.

I do have a few questions. When unpacking the header (IHDR), the old code produces flags for the compression method, the filter method, and the interlace method. All must be 0.

  1. What is the compression method, and has that been dealt with already (i.e., I can ignore it)?
  2. What is the filter method, and do I need to do anything with it at the point I receive the data?
  3. I see the interlace method comes back with the IHDR: what is the difference between NONE and ADAM7? Is ADAM7 simple scan line interlacing like on a TV (rows 0,2,4,... last-even, 1,3,5,... last-odd), or something else? Has it already been de-interlaced (all rows in order, = progressive scan)? The PDF spec doesn't say anything about interlacing, so I'm assuming it must be non-interlaced at the point I hand it over to the common image support routines.

PhilterPaper commented Sep 17, 2018

I've been working through it, comparing the Libpng interface to the old (pure Perl) code. It's messy, but I think if I just work very carefully through it, I can get it to function properly. It looks like the new (Libpng) functionality will be a superset of the old, which is an improvement.

I do have a few questions. When unpacking the header (IHDR), the old code produces flags for the compression method, the filter method, and the interlace method. All must be 0.

  1. What is the compression method, and has that been dealt with already (i.e., I can ignore it)?
  2. What is the filter method, and do I need to do anything with it at the point I receive the data?
  3. I see the interlace method comes back with the IHDR: what is the difference between NONE and ADAM7? Is ADAM7 simple scan line interlacing like on a TV (rows 0,2,4,... last-even, 1,3,5,... last-odd), or something else? Has it already been de-interlaced (all rows in order, = progressive scan)? The PDF spec doesn't say anything about interlacing, so I'm assuming it must be non-interlaced at the point I hand it over to the common image support routines.
@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 17, 2018

Why do they put the Close button right next to the Comment button....? Piss-poor UI design. Post above continued...

PhilterPaper commented Sep 17, 2018

Why do they put the Close button right next to the Comment button....? Piss-poor UI design. Post above continued...

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 17, 2018

Owner

I've been working through it, comparing the Libpng interface to the old (pure Perl) code. It's messy, but I think if I just work very carefully through it, I can get it to function properly. It looks like the new (Libpng) functionality will be a superset of the old, which is an improvement.

I do have a few questions. When unpacking the header (IHDR), the old code produces flags for the compression method, the filter method, and the interlace method. All must be 0.

The interlace method can be one of two values, but the compression method and the filter method are always zero within libpng itself, they were intended as expansions but were never implemented. You can try the libpng mailing list if you want more details.

  1. What is the compression method, and has that been dealt with already (i.e., I can ignore it)?

Yes, the compression is always done by zlib and you don't need to decompress if you are using libpng. That is done by the library.

  1. What is the filter method, and do I need to do anything with it at the point I receive the data?

See above.

  1. I see the interlace method comes back with the IHDR: what is the difference between NONE and ADAM7? Is ADAM7 simple scan line interlacing like on a TV (rows 0,2,4,... last-even, 1,3,5,... last-odd), or something else? Has it already been de-interlaced (all rows in order, = progressive scan)? The PDF spec doesn't say anything about interlacing, so I'm assuming it must be non-interlaced at the point I hand it over to the common image support routines.

I'm not exactly sure of the details of ADAM7. As mentioned above you could try the libpng mailing list or the document of the PNG format, but you don't need to worry about that since the image data is decompressed and sorted into pixels by libpng. Interlacing like that was used in the 1990s for very slow internet connections, it's not very important now, but the library does it all automatically anyway.

Coincidentally, some info here:

http://libpng.org/pub/png/pngpics.html

I wouldn't bother unless you are interested for its own sake though.

There are some tests of it all in the module somewhere I believe. It incorporates all of the libpng test images in directory t/libpng/.

Owner

benkasminbullock commented Sep 17, 2018

I've been working through it, comparing the Libpng interface to the old (pure Perl) code. It's messy, but I think if I just work very carefully through it, I can get it to function properly. It looks like the new (Libpng) functionality will be a superset of the old, which is an improvement.

I do have a few questions. When unpacking the header (IHDR), the old code produces flags for the compression method, the filter method, and the interlace method. All must be 0.

The interlace method can be one of two values, but the compression method and the filter method are always zero within libpng itself, they were intended as expansions but were never implemented. You can try the libpng mailing list if you want more details.

  1. What is the compression method, and has that been dealt with already (i.e., I can ignore it)?

Yes, the compression is always done by zlib and you don't need to decompress if you are using libpng. That is done by the library.

  1. What is the filter method, and do I need to do anything with it at the point I receive the data?

See above.

  1. I see the interlace method comes back with the IHDR: what is the difference between NONE and ADAM7? Is ADAM7 simple scan line interlacing like on a TV (rows 0,2,4,... last-even, 1,3,5,... last-odd), or something else? Has it already been de-interlaced (all rows in order, = progressive scan)? The PDF spec doesn't say anything about interlacing, so I'm assuming it must be non-interlaced at the point I hand it over to the common image support routines.

I'm not exactly sure of the details of ADAM7. As mentioned above you could try the libpng mailing list or the document of the PNG format, but you don't need to worry about that since the image data is decompressed and sorted into pixels by libpng. Interlacing like that was used in the 1990s for very slow internet connections, it's not very important now, but the library does it all automatically anyway.

Coincidentally, some info here:

http://libpng.org/pub/png/pngpics.html

I wouldn't bother unless you are interested for its own sake though.

There are some tests of it all in the module somewhere I believe. It incorporates all of the libpng test images in directory t/libpng/.

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 17, 2018

OK, I'll give some interlaced (ADAM7) images a try. PDF doesn't seem to do interlaced, but if the flag is just for historical interest and the data has already been de-interlaced, it might work. If not, is there a flag to explicitly de-interlace (if the file is interlaced) that I overlooked? If compression method and filter method were never implemented, I'll just leave a note in the code that they should be 0 (any point in checking?) and they're ignored. So, by the time I receive the image data, it should be in a standardized form with all compression and filtering removed? That would be good if I don't have to handle that in Perl code.

When I request that the Alpha channel be stripped, does that turn a color type 6 into a type 2, or does it still come back as type 6? I'm assuming that stripping the Alpha channel turns a translucent image fully opaque. Likewise, I'm assuming that simply ignoring the tRNS chunk will result in a fully opaque image. Am I misreading either of these? I haven't tried them out yet.

Finally, I need to find some sample images to test in PDF; I hope the ones you supply in t/libpng/ will do the job. I will need gray, gray+alpha, rgb, rgb+alpha, palette, gray+tRNS, rgb+tRNS, and palette+tRNS; all in a variety of bit depths if I want to do a thorough job of testing.

PhilterPaper commented Sep 17, 2018

OK, I'll give some interlaced (ADAM7) images a try. PDF doesn't seem to do interlaced, but if the flag is just for historical interest and the data has already been de-interlaced, it might work. If not, is there a flag to explicitly de-interlace (if the file is interlaced) that I overlooked? If compression method and filter method were never implemented, I'll just leave a note in the code that they should be 0 (any point in checking?) and they're ignored. So, by the time I receive the image data, it should be in a standardized form with all compression and filtering removed? That would be good if I don't have to handle that in Perl code.

When I request that the Alpha channel be stripped, does that turn a color type 6 into a type 2, or does it still come back as type 6? I'm assuming that stripping the Alpha channel turns a translucent image fully opaque. Likewise, I'm assuming that simply ignoring the tRNS chunk will result in a fully opaque image. Am I misreading either of these? I haven't tried them out yet.

Finally, I need to find some sample images to test in PDF; I hope the ones you supply in t/libpng/ will do the job. I will need gray, gray+alpha, rgb, rgb+alpha, palette, gray+tRNS, rgb+tRNS, and palette+tRNS; all in a variety of bit depths if I want to do a thorough job of testing.

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 17, 2018

Owner
Owner

benkasminbullock commented Sep 17, 2018

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 17, 2018

OK, good news on interlacing (i.e., I can ignore it).

I think you misread my question about transparency. Two separate issues: does simply stripping Alpha (parameter to the read function) do the job to make the image opaque (for gray+Alpha, RGB+Alpha), and is the result with the original color type (6 stays 6, and does not become 2)? Second issue: my understanding is that gray and RGB, as well as palette, can have a tRNS transparency chunk. If I want opaque images, I would just ignore any tRNS chunk?

PhilterPaper commented Sep 17, 2018

OK, good news on interlacing (i.e., I can ignore it).

I think you misread my question about transparency. Two separate issues: does simply stripping Alpha (parameter to the read function) do the job to make the image opaque (for gray+Alpha, RGB+Alpha), and is the result with the original color type (6 stays 6, and does not become 2)? Second issue: my understanding is that gray and RGB, as well as palette, can have a tRNS transparency chunk. If I want opaque images, I would just ignore any tRNS chunk?

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 17, 2018

Owner
Owner

benkasminbullock commented Sep 17, 2018

@PhilterPaper

This comment has been minimized.

Show comment
Hide comment
@PhilterPaper

PhilterPaper Sep 25, 2018

Hi Ben,

After struggling for days to understand why Reader kept saying "insufficient image data", I finally figured it out: it's not too little image data -- it's too much! I've got at least my first test case (24 bit RGB and RGB+Alpha) working, but have some issues that you might be able to help with:

  1. The image data you return is uncompressed (inflated?), so I had to remove the filter setting that said it was compressed data. It would be good to feed compressed (deflated?) to PDF, to keep the file size manageable (.5MB vs 13MB, in my RGB test!). I think there is a pure Perl function floating around my library to do this, but I thought I'd check with you to see if libpng.a has any setting like this that you didn't bother to provide. It should certainly be faster to do this recompression (or avoid decompressing in the first place) in C.
  2. When I have an Alpha channel, the PDF routines require that I separate the Alpha into its own mask array, and leave the image data itself (gray or RGB triplets) separate to pass to PDF. 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 compressed), and provide the pure image data in the normal manner. Is there already such a function, or if not, does libpng.a provide it already but you didn't? When I want to suppress transparency, the flag to strip the Alpha channel is of acceptable speed.
  3. I haven't yet tried a palette image (cs=3) with tRNS chunk (provide Alpha per palette entry), but again I have to separate out a full Alpha image mask, and I suspect this will be slow. Support to expand the tRNS entries (for palette) to a full Mask would be great, if libpng.a already has this somewhere but you didn't provide it.

Thanks much for any information on whether these items can be easily provided, or I'm going to have to do them in pure Perl for now.

PhilterPaper commented Sep 25, 2018

Hi Ben,

After struggling for days to understand why Reader kept saying "insufficient image data", I finally figured it out: it's not too little image data -- it's too much! I've got at least my first test case (24 bit RGB and RGB+Alpha) working, but have some issues that you might be able to help with:

  1. The image data you return is uncompressed (inflated?), so I had to remove the filter setting that said it was compressed data. It would be good to feed compressed (deflated?) to PDF, to keep the file size manageable (.5MB vs 13MB, in my RGB test!). I think there is a pure Perl function floating around my library to do this, but I thought I'd check with you to see if libpng.a has any setting like this that you didn't bother to provide. It should certainly be faster to do this recompression (or avoid decompressing in the first place) in C.
  2. When I have an Alpha channel, the PDF routines require that I separate the Alpha into its own mask array, and leave the image data itself (gray or RGB triplets) separate to pass to PDF. 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 compressed), and provide the pure image data in the normal manner. Is there already such a function, or if not, does libpng.a provide it already but you didn't? When I want to suppress transparency, the flag to strip the Alpha channel is of acceptable speed.
  3. I haven't yet tried a palette image (cs=3) with tRNS chunk (provide Alpha per palette entry), but again I have to separate out a full Alpha image mask, and I suspect this will be slow. Support to expand the tRNS entries (for palette) to a full Mask would be great, if libpng.a already has this somewhere but you didn't provide it.

Thanks much for any information on whether these items can be easily provided, or I'm going to have to do them in pure Perl for now.

@benkasminbullock

This comment has been minimized.

Show comment
Hide comment
@benkasminbullock

benkasminbullock Sep 25, 2018

Owner

I've asked you above to ask your questions about what's provided by libpng on the libpng mailing list. I apologise for repeating myself, but if you do have questions about what libpng provides, can you please ask the libpng people about that? Thank you.

Owner

benkasminbullock commented Sep 25, 2018

I've asked you above to ask your questions about what's provided by libpng on the libpng mailing list. I apologise for repeating myself, but if you do have questions about what libpng provides, can you please ask the libpng people about that? Thank you.

Repository owner locked and limited conversation to collaborators Sep 25, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.