PNGOUT Changelog

[ShinaRobot]

Hey Ken.

I'm using the Linux port of PNGOUT for a small script to compress images that are downloaded from a server. Your latest version for Windows is dated 02/09/2008 while the Linux port is dated 04/30/2007. Is there any difference in terms of compression between these two versions? What are the differences anyway?

Thanks.

[Awesoken]

The only change to PNGOUT in that time period was a bug fix to my image decoding of PCX files.

[Awesoken]

06/21/2009: Added /kt option, for preserving file date&time. There are no other changes.

[Awesoken]

Aug  9 2009: Rare .GIF files with non-zero "Pixel Aspect Byte" (offset 0xc) now decode. No other changes.

[Awesoken]

Sep 22 2009: Added exit code 3. Here are the possible values:
   0: wrote file
   1: file error
   2: unable to compress further
   3: bad options
In previous versions, "bad options" would give exit code 0. There are no other changes.

[TPS]

I would really appreciate an option that would let the input PNG govern the output flags that PNGOut uses in a bit more granular fashion than /ks allows.  If Example.PNG is already /c3 /f2 /d4 /b128 pre-PNGOut, & I want to keep all the options, (from what I can tell) I can use /ks.

But if I wanted to keep the values for /c & /f (which may or may NOT be PNGOut's own natural defaults), but vary /d &or /b for trials (some random), I would love syntax that allows for the following (the replacement symbol I'm using is 'x', but whatever suits):

PNGOut /cx /fx /d8 /b1024 Example.PNG

This would totally help with post-processing after a tool which optimizes the filters & color-type, but can't match PNGOut's compression.

Thanks for an awesome tool!

[Awesoken]

Mar 23 2010: Added a new command line option: 'l' (or 'L'), which displays the autodetected options from a specified input file and then quits before doing any compression. This may be helpful to batch file optimizers. There are no other changes.

[TPS]

<snip>

I would love syntax that allows for the following (the replacement symbol I'm using is 'x', but whatever suits):

PNGOut /cx /fx /d8 /b1024 Example.PNG

</snip>

Mar 23 2010: Added a new command line option: 'l' (or 'L'), which displays the autodetected options from a specified input file and then quits before doing any compression. This may be helpful to batch file optimizers. There are no other changes.

Thanks for the new option!

Does /ks overide explicit setting of /c# /f# /d# /b#, or vice-versa?

P.S: Another thought: Is there an option equivalent to /d0 for /c#?
[/color]

[Awesoken]

Does /ks overide explicit setting of /c# /f# /d# /b#, or vice-versa?

Yes, /ks overrides other settings.

Is there an option equivalent to /d0 for /c#?

No, but if you omit the /c# option, and PNGOUT thinks the input file was not previously compressed by itself, then it will autodetect the color mode.

[TPS]

Yes, /ks overrides other settings.

I think I found a bug regarding the /ks /c6 combo in the process of converting a /c2 image:

>PNGOut /ks /c6 "D:\ZBackUp\HumBug.PNG"

 In:38940695 bytes               D:\ZBackUp\Compression\PNG\16M\Bah\4HumBug.PNG /c2 /f0
Out:   87989 bytes               D:\ZBackUp\Compression\PNG\16M\Bah\4HumBug.PNG /c6 /f5
(Highlighting mine, of course)


I'm assuming that's not meant to be, & I have replicated it with a number of /c2 images.

Thanks!

[counting_pine]

Looks like when you give a specific color type, PNGOUT goes back to standard heuristics for the rest of the parameters.
I can't vouch for its intentionality, but this isn't an entirely unreasonable decision.  If you convert a /c2 /f5 image to /c3, you'll probably want the filter to default to /f0.  Note that the new /L feature makes it easier to apply your own trial settings in a batch script.

Ken, a small nitpick/bug report: /L will prompt to replace the destination if e.g. you pass foo.bmp and foo.png exists.  /L /y bypasses this.

[TPS]

Looks like when you give a specific color type, PNGOUT goes back to standard heuristics for the rest of the parameters.
I can't vouch for its intentionality, but this isn't an entirely unreasonable decision.  If you convert a /c2 /f5 image to /c3, you'll probably want the filter to default to /f0.  Note that the new /L feature makes it easier to apply your own trial settings in a batch script.

In general, I agree with you, but, as I mentioned, this behavior is together with the /ks switch, as in (/ks /c6).  Ken noted above (& I've verified myself, EXCEPT in this instance) that explicit /c, /f, /d, or /b set after /ks will override both the default behavior AND the input file's own settings, while keeping the rest the same.

Edit: Re-reading Ken's reply, maybe I've misunderstood?  /ks overrides /c, /f, /d, or /b not vice-versa?!

[Awesoken]

Mar 29 2010: Using the /L option should no longer ask to overwrite a file.

To clarify for TPS: when using /ks, /f# is preserved only when /c# is not modified. If you want different logic, then I suggest you write a batch file using the /L option.

[Drarakel]

Hi!

I'm using pngout for some time now. Thanks for that great tool!
Not sure if it's recommended to read from stdin. Personally, I always read from files. But in a thread in the ImageMagick Board, a problem with stdin popped up.

As example, I have taken the logo from JonoF's site:
http://static.jonof.id.au/img/title2.png
With that command, a bit-to-bit copy is generated (just for testing):

pngout title2.png copy1.png /s4
 In:    8296 bytes               title2.png /c6 /f5
Out:   68471 bytes (stored)      copy1.png /c6 /f5
Unable to compress further: copying original file

This of course works. But if I'm piping the output through stdout/stdin, the images don't get read completely sometimes (look at the file sizes):

pngout title2.png - /s4 | pngout - copy2.png /s4
 In:    8296 bytes               title2.png /c6 /f5
Out:   68471 bytes (stored)      (stdout) /c6 /f5
Unable to compress further: copying original file
Read 8192 byte(s) from stdin
 In:    8192 bytes               (stdin) /c6 /f5
Out:   68471 bytes (stored)      copy2.png /c6 /f5
Unable to compress further: copying original file

If I'm trying to read copy2.png with pngout, it crashes - as the file is corrupted.
Writing to stdout is ok - I can pipe it to other programs. But reading from stdin with pngout makes problems (sometimes it works though).

I was using the latest pngout, on Windows XP.

[Awesoken]

There's no easy way to tell when all bytes of stdin have been received, since eof() only tells you when the buffer is empty. The best solution I can think of is to put in a delay, and hope that the stream was fully received when the bytes stop coming in for a while. If there are any large time gaps, then it will still fail. I do not recommend using this option, however the probabily of failure should be much lower now.

Jun  9 2010: Using the '-' option for stdin now tries to read the file for up to 30ms since the last new bytes were received. Nothing else has been changed.