preserve 9patches

[kherink]

thanks for an awesome tool. it would be great if it could recognize 9-patched images and preserve the 9-patch formatting. imo this functionality would make this the tool of choice for android development. here is some info about 9pathes if you're not familiar: http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch http://developer.android.com/tools/help/draw9patch.html

[michaelbarlow7]

I CONCUR!

[kornelski]

In the documentation I don't see any information about PNG-specific metadata to preserve.

Is this only about preserving 9.png extension?

Could you give me an example unoptimized 9-patch file and how pngquant changes it?

[kherink]

this issue is about preserving the image border region which defines the stretchable and content areas of the image:

The border is used to define the stretchable and static areas of the image. You indicate a stretchable section by drawing one (or more) 1-pixel-wide black line(s) in the left and top part of the border (the other border pixels should be fully transparent or white).

I believe this could be solved by keeping the 1 pixel wide frame unmodified and ensuring that pure white, pure black, and clear transparent colors are in the palette.

[kornelski]

As far as I understand, pngquant already does that. Can you give me an example of a file where these colors are not preserved?

[psyke83]

pornel,

I've hooked pngquant (2.0.1) into the Android build of a project I'm associated with (androidarmv6) to preprocess the png files: http://review.androidarmv6.org/#/c/6126/

It works great for regular pngs in the build, but I can confirm that it really does break the 9patch files (lots of widgets become corrupted). I'll investigate this some more, but please let me know if you want any specific information to help troubleshoot this issue.

[kornelski]

To help resolve this issue:

• Please attach source RGBA image that doesn't get converted properly.
• Please explain exactly what you mean by "corrupted"—which colors/pixels are wrong, what they should be. Screenshots and examples of images that are converted correctly would be useful.

[Furniel]

Looks like program must preserve npTc chunks to make compiled 9.pngs work after optimization and preserve 1 pixel borders in not compiled images. I attached source of 9.png image, compiled 9.png, optimized image with pngquant and tweakpng info.

Useful info about 9.png images: http://www.curioustech.net/ninepatch.html

[kornelski]

That's very helpful. I'll see if I can copy the extra chunk.

[kornelski]

Fixed in 2e7cf0a1aad9aae5f6d68d6c7f3979e2abfa128f

[psyke83]

Hi pornel,

Unfortunately, the latest revision doesn't seem to fix the issue. Please download this archive: http://goo.im/devs/psyke83/pngquant-tests/pngquant-test.zip

It contains two .apk files: the original Calculator app, the same app the assets optimized using pngquant (the latest revision that I downloaded and compiled today), and two screenshots to illustrate how invalid 9patch images affects the app. In order to see the original or optimized .9.png files, simply rename the .apk files to .zip, and then you can open as normal zip files. The res/drawable-mdpi folder contains the assets that are used for my device (and in the screenshots you see).

Please let me know if I can help any further.

[kornelski]

Oh, bugger. png_set_unknown_chunks works with libpng 1.7, but not 1.5 :(

[psyke83]

pornel,

I had built pngquant against libpng 1.2 (and missed the warning given about the recommended version of 1.5). Given your last comment, I recompiled pngquant with the libpng1.7.0beta33 source and statically linked the libraries into the executable (as I'd prefer to leave libpng maintained by my distribution). It seems that 9patch optimization now works with this binary. Thanks!