October 27, 2012, 11:55:29 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: PNGOUT Changelog  (Read 17143 times)
ShinaRobot
Lurker

Posts: 8


View Profile
« on: July 17, 2008, 02:29:15 PM »

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.
Logged
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #1 on: July 18, 2008, 06:09:12 AM »

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

-Ken S.
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #2 on: June 21, 2009, 11:19:56 PM »

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

-Ken S.
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #3 on: August 10, 2009, 01:19:20 AM »

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

-Ken S.
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #4 on: September 23, 2009, 01:09:22 AM »

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.
Logged

-Ken S.
TPS
Lurker

Posts: 5


View Profile
« Reply #5 on: March 23, 2010, 03:08:39 PM »

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! Cheesy
« Last Edit: March 25, 2010, 04:22:21 AM by TPS » Logged
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #6 on: March 24, 2010, 03:58:33 AM »

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.
Logged

-Ken S.
TPS
Lurker

Posts: 5


View Profile
« Reply #7 on: March 25, 2010, 03:28:30 AM »

<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! Smiley

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]
Logged
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #8 on: March 26, 2010, 03:24:02 AM »

Quote
Does /ks overide explicit setting of /c# /f# /d# /b#, or vice-versa?
Yes, /ks overrides other settings.
Quote
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.
Logged

-Ken S.
TPS
Lurker

Posts: 5


View Profile
« Reply #9 on: March 30, 2010, 12:45:22 AM »

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!
Logged
counting_pine
Patron
****
Posts: 208


View Profile
« Reply #10 on: March 30, 2010, 02:02:32 AM »

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.
Logged
TPS
Lurker

Posts: 5


View Profile
« Reply #11 on: March 30, 2010, 10:54:48 AM »

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?!
« Last Edit: March 30, 2010, 10:57:20 AM by TPS » Logged
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #12 on: March 30, 2010, 12:14:16 PM »

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.
Logged

-Ken S.
Drarakel
Lurker

Posts: 2


View Profile
« Reply #13 on: June 10, 2010, 05:24:25 AM »

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):
Quote
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):
Quote
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.
Logged
Awesoken
Global Moderator
Fixture
*
Posts: 915



View Profile WWW
« Reply #14 on: June 10, 2010, 08:13:04 AM »

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.
Logged

-Ken S.
Pages: [1] 2
  Print  
 
Jump to:  

Powered by SMF 1.1.12 | SMF © 2006-2009, Simple Machines LLC