Need insight on AutoIt's support for PNGs

[qwert]

I'd like to get some insight and guidance from someone versed in the mechanics AU3’s support for images in PNG format.

 

I’ve used PNGs in various ways in AutoIt for years.  But I happened upon a case where a screen capture resulted in a PNG file that was over 2 megabytes. It seemed odd that a 1200x900 pixel image would be that large. Comparable images that I work with are always less than a megabyte ... usually, far less.  In fact, the efficiency of PNG (as a lossless format) has always impressed me.

 

So I searched the Au3 help and found a function I’ve never noticed:

_WinAPI_CompressBitmapBits() ... “Creates a compressed data block from the specified bitmap ($hBitmap)”

 

As a crude test, I added it to my script to post-process the 1200-pixel image and got an unexpected result: the PNG increased by 1000 bytes.

 

So I searched the Internet looking for insights and came to a rather comprehensive description of PNG:

http://www.libpng.org/pub/png/book/chapter01.html

 

Here are a couple of notable excerpts:

 

"Practically speaking, independent implementation of the deflate algorithm is both difficult and unnecessary. Almost every PNG implementation available today makes use of the freely available zlib compression library"

 

"Despite PNG's potential for excellent compression, not all implementations take full advantage of the available power. Even those that do can be thwarted by unwise choices on the part of the user."

 

And there are some really interesting points in these sections:

  1.2.4. Compression

  1.2.4.1. Compression filters

  1.2.4.2. Compression oopers

 

  9.4. Practical Compression Tips

  9.4.1. Tips for Users

  9.4.2. Tips for Programmers

 

So, I think my most-basic question is this:

Does _GDIPlus_ImageSaveToFile( "...png") apply a compression step?

 

And related:  Is there ever a reason to try to apply _WinAPI_CompressBitmapBits()?

If so, are there any examples of compressing images for PNGs in this manner?

Obviously, this can be quite involved ... a real forest of possibilities.  What I'm seeking is an efficient path through those woods.

 

Thanks in advance for any suggestions.

 

 

 

[UEZ]

Afaik, GDI+ doesn't support PNG compression settings.
 
What you can do is to use 3rd party command line tools to compress a PNG image better than GDI+ does, e.g. pngout.exe which is in the XnView package.

Edited April 8, 2015 by UEZ

[qwert]

Thanks for looking at this.

Do you think there's any potential in trying to work with _WinAPI_CompressBitmapBits()?

I'm not sure my crude attempt used valid settings.  And, unfortunately, I can't consider 3rd-party software for the applications I working on.

[UEZ]

I never used _WinAPI_CompressBitmapBits - might be working.

[UEZ]

I looked into the _WinAPI_CompressBitmapBits function and it streams the bitmap to a PNG without the possibility to set PNG compression settings because it uses WinAPI/GDI+ to do the streaming.

Compression setting is only for JPEG file format!

Edited April 9, 2015 by UEZ

[qwert]

Thanks for looking into it.  It's good to know what the choices are (and aren't).

I did some testing just to confirm what (I hoped) I already knew:  Upon writing a PNG, GDI+ does compress a bitmap image.  I've attached one of my results.

Granted, the bmp in my example is extremely compressible.  The others I referenced in my original post obviously weren't.  I guess that leaves the question of whether there are any choices regarding the algorithm GDI+ uses.

Meanwhile, I'll see what else I can learn by watching these type conversions more closely.

 

[qwert]

As a footnote to this thread, these paragraphs are from the PNG specification, tenth draft:

 

  Compression type is a single-byte integer that indicates the

  method used to compress the image data. At present, only

  compression type 0 (deflate/inflate compression with a 32K

  sliding window) is defined. All standard PNG images must be

  compressed with this scheme. The compression type code is

  provided for possible future expansion or proprietary variants.

  Decoders must check this byte and report an error if it holds an

  unrecognized code. See Deflate/Inflate Compression for details.

 

  Filter type is a single-byte integer that indicates the

  preprocessing method applied to the image data before

  compression. At present, only filter type 0 (adaptive filtering

  with five basic filter types) is defined. As with the compression

  type code, decoders must check this byte and report an error if it

  holds an unrecognized code. See Filter Algorithms for details.

 

This explains the "compressed" result received from a GDI save operation: deflate/inflate is an integral part of the processing of PNGs.