Forum archive

PNGOUT Changelog

Return to forum index

• ShinaRobot at 2008-07-17 14:29
  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 at 2008-07-18 06:09

  Re: PNGOUT Changelog

  The only change to PNGOUT in that time period was a bug fix to my image decoding of PCX files.
• Awesoken at 2009-06-21 23:19
  06/21/2009: Added /kt option, for preserving file date&time. There are no other changes.
• Awesoken at 2009-08-10 01:19
  Aug  9 2009: Rare .GIF files with non-zero "Pixel Aspect Byte" (offset 0xc) now decode. No other changes.
• Awesoken at 2009-09-23 01:09
  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.
• TSamuel at 2010-03-23 14:08

  Suggestion for slight addition to PNGOut input->output options

  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! :D
  Edited by TPS at 2010-03-25 03:22
• Awesoken at 2010-03-24 02:58

  Re: PNGOUT Changelog

  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.
• TSamuel at 2010-03-25 02:28

  <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#?
  
• Awesoken at 2010-03-26 02:24

  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.
• TSamuel at 2010-03-30 00:45

  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 at 2010-03-30 02:02
  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.
• TSamuel at 2010-03-30 10:54

  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?!
  Edited by TPS at 2010-03-30 10:57
• Awesoken at 2010-03-30 12:14
  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 at 2010-06-10 05:24

  PNGOUT: Problem when reading from stdin

  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 at 2010-06-10 08:13

  Re: PNGOUT Changelog

  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.
• Drarakel at 2010-06-10 22:56
  Most of the time, reading from stdin is indeed working well now. Thanks!
  
  I understand that it's not recommended. In some cases, when I'm using another tool (like ImageMagick) for piping the output to pngout, pngout still crashes. I can't recreate it with pngout alone though... And I'm having problems getting pngout to write to stdout when reading from the clipboard. But, well, these are pretty exotic cases. ;D