Even if I use -zl121 with pngout, some mobile phones by LG (e.g. KG800, C1100, C3300) cannot load these PNGs. This happens in most cases with very small files (<300 bytes).
I created two PNGs with the same image. -one optimized with pngout -zl121 -one created with pngrewrite and with manually removed gAMA chunk The second is even some bytes smaller and it works. I add them as attachment.
Any ideas?
Nevertheless thanks for -zl121, it helps for some Samsung phones and Nokia 6230i.
Awesoken at
Re: some mobile phones have still problems with pngout
I have no ideas because there is no attachment. If you want to try again, I will look at it. I would be willing to uudecode or de-hex if necessary.
I'm fairly confident that PNGOUT is producing valid PNG files. I feel little compassion for those phone manufacturers who fail to follow specifications. I was willing to do the -zl121 hack only because it was a widespread problem. If I am to do further command line switch hacks, I will be sure to give them less than flattering names : P
timo at
Hi!
Hm, there is already an attachment. Its name is "pngout-problem.zip" and belongs to my first posting. I downloaded it myself there to check it.
Awesoken at
I'm still not seeing your attachment. It looks like it's only visible to you. I looked through the forum help and found this:
I'm not sure if those settings apply to this forum, but if so, it might explain things. I am merely a pawn when it comes to forum administration. Perhaps JonoF can explain what's going on.
Matthias at
Hi there!
Strange, the forum view seems to hide attachments when you are not logged in. Anyway, I've posted Timo's file at this URL as well: http://www.geocities.com/kertis77/pngout-problem.zip
PNGOUT is really a great tool. Maybe there can be an easy work-around (e.g. PNGOUT /stupidmobiles ;)) to get all crunched PNGs working on those LG handsets, too (they are full of Java bugs, so I'm quite sure that it's an issue on the phones and not with PNGOUT).
Thanks, Matthias
Awesoken at
Thanks for the mirror, Matthias.
The main difference between the PNGOUT-compressed file and the other one is: PNGOUT uses dynamic huffman, while the other uses fixed huffman. This explains why the file size of the other one is smaller, because fixed huffman is often better on very small files. PNGOUT does not currently support fixed huffman as output. Another interesting thing is there are no patterns in the file, meaning there are no length or distance codes. I suspect the phones in question are treating this as an error, even though it shouldn't be. This kind of condition would happen on very small PNG files, or on very random PNG files that would happen to have no 3-byte patterns whatsoever. If you're really bored, and wish to understand my answer better, you are free to study this document: http://www.faqs.org/rfcs/rfc1951.html
counting_pine at
Hi. I don't know if JonoF's has since worked his magic, but I found the attachment at the bottom of your post. Maybe the phone is choking because the Distance code table doesn't have enough codes to create a full Huffman tree. (Which is pretty poor.) Does this file work OK? It's almost the same file as the "pngout /zl121" one you posted, except I added another code to complete the Distance tree.
timo at
yes, this new oil file works! Can we have an option for this in pngout? Please :-)
Awesoken at
Counting Pine, it would help if I had a copy of your modified PNG for debugging purposes. As Matthias pointed out, attachments are only visible when you are logged in. I have yet to be so lucky. Would you mind re-posting the file as hex code or something?
The real tragedy here, is that the PNG test suite does not include files that are failing on these crappy phones. That's fine if you test everything with Zlib. My problem is I go by the official PNG specification.
Now, the only question is what should I call this new parameter?
counting_pine at
Not logged in? Not sure I follow, you seem to be logged in to me.
Parameter names that spring to my mind are things like /tree or /fulltree, or /huff, something like that. (/stupidmobiles still sounds tempting though.) Otherwise, I guess the alternative would be to extend the /zl121 behaviour.
timo at
Hi!
Any news regarding a new option for pngout? Can we expect an update for this?
Thanks! Timo
Awesoken at
I have updated PNGOUT on my site, with a new command line option: /mincodes#
/mincodes0 is the same as specifying nothing (default) /mincodes1 is the same as specifying /zl121 /mincodes2 is the new behavior, which generates files similar to the image that Counting Pine posted in this thread.
Please let me know if it works.
timo at
Thanks!
It seems to work :-)
captainfreedom at
I found the same problem with a motorola V3x. Some small images won't load and this mincodes2 thingy does indeed fix the problem. Would it be safe to just to always apply this option for all images (to make the optimisation process easier)? What are your thoughts?
Awesoken at
Yes, it's safe to use /mincodes2 for all images. The downside is the resultant PNG file may be a few bytes more. Since the purpose of PNGOUT is to make the smallest file possible, I made it an option.