PNG00 not working

[glennrp]

I understand the benefit of the size reduction, which is cool. But I don't understand why it would be forced. Ideally the tool should specify something like -optimize to allow it to do the format change for the best fitting format.
There could be many reasons why you want to keep the original format especially in a game pipeline, and it's totally unexpected that applying a simple size reduction would cause the file format to change IMO.

It was a design choice made years ago. The PNG specification requires all PNG-compliant decoders to be able to read all of the PNG subformats. We chose to permit people to choose the output subformat to accommodate some big players (e.g., Microsoft) who don't (or didn't) comply with that spec requirement. Here's the relevant extract from the PNG spec, http://www.w3.org/TR/PNG

• 15.2.3 Conformance of PNG decoders
  
  A PNG decoder conforms to this International Standard if it satisfies the following conditions.
  
  It is able to read any PNG datastream that conforms to this International Standard, including both public and private chunks whose types may not be recognized.

[auday]

Yes, but that's my point, I know it's not the resizing, even if you do nothing the file-format still changes, which is my point. I don't think it's the right behavior.

If you do something like: convert test.png test2.png, you should get the exact same file byte to byte.

If you want to optimize it, you should do:

convert test.png -optimize OPTIONS test2.png

if you want to resize and optimize:

convert test.png -resize 50% -optimize OPTIONS test2.png

OPTIONS could be something like:
keepColorDepth
keepColorType
or something similar.

The point is, I don't want ImageMagick to over do what it's asked to do. Or at least if I specifically ask it to keep the format (PNG00) then it should respect that, and if I ask it to use trueColor it should respect that.
The way it is right now, is not useable in my case, which I understand is a very rare case, but still a valid case with a valid expectations IMO.

[glennrp]

Yes, but that's my point, I know it's not the resizing, even if you do nothing the file-format still changes, which is my point. I don't think it's the right behavior.

If you do something like: convert test.png test2.png, you should get the exact same file byte to byte.

You certainly won't get that, even after PNG00 is fixed. PNG (and therefore ImageMagick) does not keep a record of the compression
settings that were used in producing the file, so it can't reproduce them. In your test.png, apparently you used really
poor settings because even the test.png -> png32:test32.png results in a new file that is half the size of the
original. But anyhow, as I said in an earlier message, I agree that PNG00 is buggy with respect to png32 input, but
the fix is not trivial.

If you want to optimize it, you should do:

convert test.png -optimize OPTIONS test2.png

if you want to resize and optimize:

convert test.png -resize 50% -optimize OPTIONS test2.png

OPTIONS could be something like:
keepColorDepth
keepColorType
or something similar.

Well, we've tried that, and eventually I'll get it working. That's what PNG00 is supposed to do.
I don't think it will keep the interlacing at the moment, but I'm not sure.... OK I just tested and
it does *not* preserve the interlacing. Perhaps it should.

The point is, I don't want ImageMagick to over do what it's asked to do. Or at least if I specifically ask it to keep the format (PNG00) then it should respect that, and if I ask it to use trueColor it should respect that.
The way it is right now, is not useable in my case, which I understand is a very rare case, but still a valid case with a valid expectations IMO.

[auday]

Glenn and Fred, thanks for the quick and detailed replies. I made some changes to my pipeline and forced everything to be PNG32 for now and that is kind of working for me at the moment. It's not ideal but it's ok.

Looking forward to PNG00 fix. After I ship the project I'm working, I could also offer help if you guys need it.

Cheers,

Auday

[glennrp]

Fix is checked in to SVN revision 15529 for IM6 and IM7. I can't test IM7 because there are a lot of unrelated compile errors.