Forum archive

PNGOUTWin Release Candidate

Return to forum index

• David at 2006-03-28 05:20
  The http://www.pngoutwin.com has been updated with the release candidate build of PNGOUTWin.
  
  Release notes for this build:
  
  + Significant performance improvements for
• Maren at 2006-03-28 08:44
  Well, the stop, pause and start buttons do not work if the images are dragged and dropped.
• David at 2006-03-28 14:31

  RE: Stop, Pause not available after drag and drop of file

  Well, the stop, pause and start buttons do not work if the images are dragged and dropped.

  Thank you for finding this.
  The fix is checked in and will be in the next build.
• Martin at 2006-03-28 15:20

  PNGOUTWin Release Candidate

  "Background" priority still doesn't work :(
  
  Edit: Will there be a Linux port?
  Edited at 2006-03-28 22:11
• Maren at 2006-03-28 21:31
  This is probably a rather cosmetic suggestion but, would you add an "All" option for "Color Type" just as in "Filter" and "Bit Depth"?.
  
  Another welcome feature would be being able to get the results sorted out in both descending and ascending order by only clicking the name of the column.
• Thundik81 at 2006-03-28 22:11
  Another requested feature : the possibility to choose a transparent color. I badly need to set a transparent color for a "complex" picture (rather than 256 colors)
  
  Thanks
• Maren at 2006-03-29 00:27
  http://img459.imageshack.us/img459/8923/str6mu.png
  
  I have a question. What does winning job mean?. One of the output files ended up being bigger than the original one and it was given a smiley while many others which actually compressed, were not.
• counting_pine at 2006-03-29 00:58
  If you give PNGOUTWin a BMP, then it has to convert it into a PNG. Since you've asked it to do a conversion, it will output a PNG, regardless of the original BMP size.
  
  If it is set to overwrite the original file, it seems to decide whether or not to write the PNG based on whether there's an existing [filename].png. It will write the file it has produced if it is smaller than the existing [filename].png, or if [filename].png doesn't exist or has a file size of zero.
  
  If you're optimising a PNG file, then it will write a PNG if it produces a smaller file size than the currently existing one.
  
  
  EDIT
  I have another request for PNGOUTWin, that you add some command line support.
  i.e. so that you can type "pngoutwin picture.png" and it will act as if you had selected picture.png through the "New File Conversion" menu option.
• David at 2006-03-29 02:10

  RE: questions

  "Background" priority still doesn't work :(
  
  Edit: Will there be a Linux port?

  Could you please be more specific about this. The GUI process uses very little cpu, and since it manages everything its priority is not decreased.
  When I look at the worker processes with Task Manager, their priorities do change.
  
  We are evaluating other platforms at this time. That said, I'm not convinced the Linux platform is receptive to commercial software on a scale that would allow us to recover our investment. I am still investigating the size of the market, so my position on this may change, but in the short term it doesn't look like there is a business case for a Linux version.
  
  

  I have a question. What does winning job mean?. One of the output files ended up being bigger than the original one and it was given a smiley while many others which actually compressed, were not.

  There is a bug in the RC1 build that is fixed in what will be RC2.
  Right now, all trials where a file gets written end up with a smiley.
  In RC2, a file must be both written and smaller than the source file to get a smiley.
  Also, even if a file is compressed, a previous trial result may have had a smaller result. It is only a winner if at the time of the job completion the existing target file is larger than the result of the trial. This makes it easier to see which trials actually resulted in smaller files.
• David at 2006-03-29 02:20

  Background colors

  Another requested feature : the possibility to choose a transparent color. I badly need to set a transparent color for a "complex" picture (rather than 256 colors)
  
  Thanks

  PNGOUTWin isn't really an image editor. You can use another tool to create a background chunk, and then set up the keep chunks dialog to preserve this chunk.
  [EDIT: See Ken's comment below. I thought you were talking about the optional bKGD chunk.]
  Edited at 2006-03-29 03:20
• Awesoken at 2006-03-29 03:15

  PNGOUTWin Release Candidate

  Actually, transparency/alpha is stored in the 'tRNS' chunk. It's not listed in the "keep chunks" dialog because PNGOUTWin always preserves alpha information. To add or remove alpha from an image, you must use an external image editor.
• counting_pine at 2006-03-29 03:37
  If you know what you're doing, I'd recommend using TweakPNG to add/edit the tRNS chunk.
• Thundik81 at 2006-03-29 05:08
  Thanks you all for your help with transparency
• Kevin_b_er at 2006-03-29 10:16
  Right now noone can test the multiple trials stuff because noone can buy it, and it limits itself to 20 trials. I'm rather curious how Maren got it to do 6000+ trials, because I obviously cannot. If I can't get it to do more than 20+ trials, when can I buy it?
• Martin at 2006-03-29 11:20

  Re: RE: questions

  "Background" priority still doesn't work :(
  
  Edit: Will there be a Linux port?

  Could you please be more specific about this. The GUI process uses very little cpu, and since it manages everything its priority is not decreased.
  When I look at the worker processes with Task Manager, their priorities do change.
  
  We are evaluating other platforms at this time. That said, I'm not convinced the Linux platform is receptive to commercial software on a scale that would allow us to recover our investment. I am still investigating the size of the market, so my position on this may change, but in the short term it doesn't look like there is a business case for a Linux version.

  I set priority to "background", but both processes run with "normal" priority.
  
  Concerning a Linux build, well, I don't need a GUI, but I'd like to use "Xtreme" compression on Linux, too :D
• David at 2006-03-29 13:19

  Release Date

  Right now noone can test the multiple trials stuff because noone can buy it, and it limits itself to 20 trials. I'm rather curious how Maren got it to do 6000+ trials, because I obviously cannot. If I can't get it to do more than 20+ trials, when can I buy it?

  Thank you for your interest in PNGOUTWin.
  
  All I can say about the release date is really soon now. It all depends on the number of bugs found and the severity of the bugs. At this point in time, it looks like very early April will be the ship date if all goes well (You realize by stating this that all hopes of a timely release are now very slim :)). There is a link to a sign-up page to be notified when we go commercial at http://www.ardfry.com/pngoutwin/Shop.htm
  This will not put you on a newsletter list. This is a sign-up form to receive a single message when PNGOUTWin is available for purchase.
  
  Some testers have been given registration codes. Over 400 people downloaded the beta, but less than ten sent comments with suggestions or bug reports. The offer of registration codes was not made up front. These testers did quite a bit of testing and took the time to write in without expecting anything in return. These exceptional folks--numbering much less than 1% of all downloads--deserve it.
• David at 2006-03-29 13:26

  Re: RE: questions

  I set priority to "background", but both processes run with "normal" priority.
  
  [...]

  I can repro this now. If you change the settings in the dialog to Background, then the priority is set to Background. However, the next time you start the app after exiting, it is not set to background.
  
  [Edit: The fix for this is checked in and will be in RC 2.]
• Kevin_b_er at 2006-03-29 15:01

  Re: Release Date

  There is a link to a sign-up page to be notified when we go commercial at http://www.ardfry.com/pngoutwin/Shop.htm
  This will not put you on a newsletter list. This is a sign-up form to receive a single message when PNGOUTWin is available for purchase.

  Been on it :)
  
  Hope to see the final version comming out soon. And... if I'm lucky, see Xtreme mode in the CLI version.
• David at 2006-03-31 04:45

  RC 2 Released

  Release Candidate 2 of PNGOUTWin is now available on http://www.pngoutwin.com
  
  This includes the following bug fixes:
  
  * Fix: Click of Reset Defaults /w all filters chosen leaves all filter checkboxes disabled
  * Fix: Background priority not set at startup
  * Fix: Multiple trials, Initial Huffman Tables, Default always checked
  * Fix: Smiley for Written and Smaller, not just Written
  * Fix: Stop, Pause not available after drop of file
• counting_pine at 2006-04-01 10:35

  PNGOUTWin Release Candidate

  There seems to be a bug when PNGOUTWin writes PNGs that have been deflated with the "No compression" strategy: Sometimes it leaves all the chunk CRCs as 0xffffffff.
• Martin at 2006-04-02 00:05
  2 suggestions:
  - Automatic scrolling following the running job (with a toolbar button to toggle on/off)
  - When clicking "autosize columns", then expand the columns to the widest entry of the whole job list, not only of the visible part. This already seems to work for the status column, but not for the job column.
• David at 2006-04-02 05:49

  Release Candidate 3

  Release Candidate 3 has been released to http://www.pngoutwin.com
  
  + New strategy, Infinite, which provides one-way compression to zero bytes
  * Fix: Initialize CRC block for
• Awesoken at 2006-04-02 07:40

  PNGOUTWin Release Candidate

  1-way compression? Very funny : ) FYI, the smallest VALID PNG file is 67 bytes. A few years ago, I spent some time trying to generate the most interesting 67-byte PNG file possible. This is what I ended up with:
  

  89504E470D0A1A0A0000000D49484452000000300000002501000000002C6257
  
  020000000A49444154785E631A0500081E0207CD9624250000000049454E44AE
  
  426082

  
  
  File info: 48x37, color type:0 (Gray), filter:2 (Up / delta y), bitdepth:1, Fixed Huffman. It's a lovely binary pattern.
• Maren at 2006-04-02 08:47
  Looking good! 8), but now I'm a lil confused.
  
  1. What are the differences between "done", "written with a smiley" and "written without smiley"?.
  
  2. How does the Infinite strategy work and how do I access it from the GUI in case it's possible?.
• Awesoken at 2006-04-02 11:25
  Done = Unable to compress further
  Written with smiley = Able to compress further
  Written without smiley = Unable to compress further; but since input file was not PNG format, writing anyway
  Infinite strategy = joke
• David at 2006-04-02 11:28

  RE: Questions

  Looking good! 8), but now I'm a lil confused.
  
  1. What are the differences between "done", "written with a smiley" and "written without smiley"?.
  
  2. How does the Infinite strategy work and how do I access it from the GUI in case it's possible?.

  1. The three states are
  Done = a target file with the same name already existed and the current trial was unable to generate a file that was smaller than the existing file.
  
  Written, no smiley = no target file existed, but the result was not smaller than the original. The simplest case of this is going from JPG to PNG, which usually results in a file that is larger than the JPG.
  
  Written w/ smiley -- PNGOUT was able to generate a file that was smaller than the original and smaller than the destination if it existed already.
  
  2. In the U.S., April 1st is a national day for practical jokes. See Google's "Google Romance" for a similar kind of joke.
  A one-way compression to zero bytes would be a file that couldn't possibly be decompressed.
  I could resist doing this with a build and release on April Fool's Day.
• counting_pine at 2006-04-02 13:13

  PNGOUTWin Release Candidate

  It will also write without smiley if the output size is bigger, but the options are set to write the file in a given folder or the same folder, but not overwrite the original PNG.
  (@David: nice joke, @Ken: nice PNG :) )
• David at 2006-04-02 13:33

  Smiley

  It will also write without smiley if the output size is bigger, but the options are set to write the file in a given folder or the same folder, but not overwrite the original PNG.
  (@David: nice joke, @Ken: nice PNG :) )

  This was the case in RC 1, but this shouldn't be happening as of RC 2.
• counting_pine at 2006-04-02 23:47

  PNGOUTWin Release Candidate

  My bad. OK, I've tested a bit more conscientiously, and this is what I understand happens:
  
  If PNGOUTWin is compressing a PNG, it will only write a larger file if it is set to "Put output files in the same folder as source". In this case it writes every trial with a number in brackets after the filename (e.g. myfile(0).png, myfile(1).png, ...) Trials that are smaller will get the smiley face.
  
  If you set it to output in a specified folder, it will write myfile.png there, provided it doesn't already exist, or the output is smaller than the existing myfile.png.
  
  If you set it to overwrite the original, it will only do so if the output is smaller than the original.
• Thundik81 at 2006-04-03 02:32
  Some suggestions :
  - a language file for translators
  - PNGOUT Time should only be the time of compression (and not the time between when job starts and when it finishes -including time of pause)
  - move up/down files in queue
  - pause only one file
  
  Thanks
• David at 2006-04-03 07:02

  Translation

  >> a language file for translators

  Thank you for the suggestions.
  After 1.0 ships and the marketing push is complete, I will be posting information for localization "volunteers." They won't really be volunteers, because those who help us with translations will get a free license and an acknowledgement in the localized version of the help. In order to qualify, you will need to be a native speaker.
  The target languages will be EFIGS.
  Spanish is already covered: Makinolo, mi amigo en Mardrid, va a ayudarme traducirlo a espanol.
  We will need help in other languages.
  
  Stay tuned here for details that will follow in the coming weeks.
• Martin at 2006-04-03 08:03

  PNGOUTWin Release Candidate

  PNGOUTWin has problems with filenames like 1.2.jpg. The .png extension won't be added, so it generates 1.2 instead.
• David at 2006-04-04 00:47

  RC 4 released

  PNGOUTWin has problems with filenames like 1.2.jpg. The .png extension won't be added, so it generates 1.2 instead.

  I put RC 4 on http://www.pngoutwin.com
  
  Change for this build:
  
  * Fix: Extension not added to some filenames that contain more than one "."
• Kevin_b_er at 2006-04-04 08:50

  PNGOUTWin Release Candidate

  Could we get some more information about the Error'ed ones. Sometimes I'm curious as to why a particular file failed. (What bit depth did it try to use that caused the fail?)
  EDIT: More information, as in, a properties dialog for it
  
  
  Also, I can't test this on the new version, but I doubt its changed. When doing lots of smaller (2 kb or less usually), multiple processes bottleneck themselves against file I/O. Does each process check the resulting file size against the file size on disk?
• David at 2006-04-04 09:13

  RE: error codes, blocking

  Could we get some more information about the Error'ed ones. Sometimes I'm curious as to why a particular file failed. (What bit depth did it try to use that caused the fail?)
  EDIT: More information, as in, a properties dialog for it
  
  
  Also, I can't test this on the new version, but I doubt its changed. When doing lots of smaller (2 kb or less usually), multiple processes bottleneck themselves against file I/O. Does each process check the resulting file size against the file size on disk?

  In future versions the error messages will be much more specific. There are some technical issues that need to be addressed. It's not that the detail is there and it's not getting shown: the detail of the error code isn't made available to higher layers.
  
  Yes, the behavior you describe is expected. The only way to reliably ensure in a multithreaded environment that a smaller result isn't overwritten is to block--there is no way around this. The blocking is done based on the name of the file, so if two i/o threads are processing different files, then they won't block each other.
  Even in the case where there is no contention for the same file, the file size must be checked before the write because the file size may have changed between when the file was first read and when the compression completes.
• zooloo at 2006-04-04 12:44

  Re: Translation

  >> a language file for translators

  Thank you for the suggestions.
  After 1.0 ships and the marketing push is complete, I will be posting information for localization "volunteers." They won't really be volunteers, because those who help us with translations will get a free license and an acknowledgement in the localized version of the help. In order to qualify, you will need to be a native speaker.
  The target languages will be EFIGS.
  Spanish is already covered: Makinolo, mi amigo en Mardrid, va a ayudarme traducirlo a espanol.
  We will need help in other languages.
  
  Stay tuned here for details that will follow in the coming weeks.

  My mother tongue is German and I suppose to be sufficiently language aware. Just let me know when a translator is needed.
  
  cheers,
  zooloo
• Kevin_b_er at 2006-04-04 17:31

  Re: RE: error codes, blocking

  Could we get some more information about the Error'ed ones. Sometimes I'm curious as to why a particular file failed. (What bit depth did it try to use that caused the fail?)
  EDIT: More information, as in, a properties dialog for it
  
  
  Also, I can't test this on the new version, but I doubt its changed. When doing lots of smaller (2 kb or less usually), multiple processes bottleneck themselves against file I/O. Does each process check the resulting file size against the file size on disk?

  In future versions the error messages will be much more specific. There are some technical issues that need to be addressed. It's not that the detail is there and it's not getting shown: the detail of the error code isn't made available to higher layers.
  
  Yes, the behavior you describe is expected. The only way to reliably ensure in a multithreaded environment that a smaller result isn't overwritten is to block--there is no way around this. The blocking is done based on the name of the file, so if two i/o threads are processing different files, then they won't block each other.
  Even in the case where there is no contention for the same file, the file size must be checked before the write because the file size may have changed between when the file was first read and when the compression completes.

  Yeah you're thinking of the smaller-than-case of the need to check the file each time since you're aren't keeping a running total of the smallest-size, but what of the bigger-than case? I looked at pngoutwin's file operations, and RC4 retrieves the file info reguardless of the resulting file size.
  
  If the filesize it produces is larger than the size that we knew from the start, shouldn't it be safe to assume that you don't need to bother with checking the file size. If from the results of compression, the file's going to be bigger, then checking the file isn't neccessary as its a toss-away case.
  
  That is, if the "PNGOUT Size" is bigger than or equal to "Size", and we're doing in-place overwriting("Overwrite original file" on PNG files), then there's no need to do any file I/O operations.
  
  I'm not sure how its currently working. There were mumblings that make me think prefiltering is being done to save time, so why not pass (or if it retrieves the file as it runs even) the original size in so a less-than check can be done before it goes to file i/o.
  
  It'll help me alot when I run through 1000+ trials per file on 50 1500 byte files if it didn't always do file i/o checks on every single trial.
• David at 2006-04-05 01:07

  Optimization for small files case w/ overwrite

  [...]
  
  If the filesize it produces is larger than the size that we knew from the start, shouldn't it be safe to assume that you don't need to bother with checking the file size. If from the results of compression, the file's going to be bigger, then checking the file isn't neccessary as its a toss-away case.
  
  That is, if the "PNGOUT Size" is bigger than or equal to "Size", and we're doing in-place overwriting("Overwrite original file" on PNG files), then there's no need to do any file I/O operations.
  
  [...]

  This is a really good point. In the next day or so I'll be in touch with you.
• Kevin_b_er at 2006-04-05 10:08

  PNGOUTWin Release Candidate

  So is it released? The purchase page is up.
• David at 2006-04-05 10:52

  PNGOUTWin 1.0

  So is it released? The purchase page is up.

  Yes, it was released early this morning.
• zooloo at 2006-04-06 03:16

  Re: PNGOUTWin 1.0

  So is it released? The purchase page is up.

  Yes, it was released early this morning.

  Looks, and even works, great so far. :-) The gained speed is a particularly nice surprise to me (thinking of PNGOUT.dll for IrfanView).
  
  Two minor issues:
  
  1. It would be cool to permit spaces in the block split threshold list like
  
  {64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, 512}
  
  or just
  
  64 96 128 160 192 224 256 288 320 352 384 416 448 480 512
  
  instead of
  
  {64,96,128,160,192,224,256,288,320,352,384,416,448,480,512}
  
  in order to facilitate further refinements by finding the Nth number more easily (Ctrl+Right N times).
  
  Even better would be to explicitely state the actually used settings in each trial, e. g. by additional (optional?) table columns, one per degree of freedom in the settings. Aside from helping the user to better understand the effects of certain options, that would allow to spot unpromising combinations quickly. But that`s supposed to be a bigger task, hence my suggestion about the space delimiters. ;-)
  
  2. See the attached screenshot. At first glance, the second smiley is slightly bewildering. As I infer, the status of a trial currently is determined by nothing but that trial`s performance alone (i. e. regardless of preceding ones). Anyway, I guess you see my point.
  
  
  zooloo
  
  
  http://x10.putfile.com/4/9412124162-thumb.png
  (hosted by http://www.putfile.com)
• David at 2006-04-06 04:24

  [...]
  2. See the attached screenshot. At first glance, the second smiley is slightly bewildering. As I infer, the status of a trial currently is determined by nothing but that trial`s performance alone (i. e. regardless of preceding ones). Anyway, I guess you see my point.
  
  [...]

  Thank you for the suggestions.
  PNGOUTWin is a multithreaded application. I can't see the job times, I would guess that job two finished before job one. When job two was done, it had the smallest result up to that time. When job one finished (after job 2), job one had a result that was smaller than job 2's result. The status of the trial is determined by what was the case at the instant that the job completed.
• zooloo at 2006-04-06 06:11

  Re: Release Candidate 3

  I have set the threads count to 1 because of lacking hyperthreading (let alone multiple CPUs), but I don`t know if I had done this at that time already. Probably you are right.
  
  

  Release Candidate 3 has been released to http://www.pngoutwin.com
  
  + New strategy, Infinite, which provides one-way compression to zero bytes
  * Fix: Initialize CRC block for “No compression” strategy

  Reading through this forum backwards, I guess I am a little late. Anyway, for the ones who don`t know it yet (supposedly you both do), here`s suggested a curious two way compression technique that leads down to one byte per file:
  http://cs.fit.edu/~mmahoney/compression/barf.html
• psychorosti at 2006-04-06 15:33

  [...]Anyway, for the ones who don`t know it yet (supposedly you both do), here`s suggested a curious two way compression technique that leads down to one byte per file:
  http://cs.fit.edu/~mmahoney/compression/barf.html

  :lol: n1 April joke. But i feel like the "compressor" is simply putting the removed byte simply in the filename... odd but nice idea to impress non-technical people.
• zooloo at 2006-04-08 02:05

  crash

  When trying to compress the high resolution version of http://de.wikipedia.org/wiki/Bild:Wappen_meckenheim.png (1936
  Edited at 2006-04-09 00:44
• David at 2006-04-08 03:10

  Re: crash

  When trying to compress the high resolution version of http://de.wikipedia.org/wiki/Bild:Wappen_meckenheim.png (1936

  Edited at 2006-04-08 04:37
• counting_pine at 2006-04-08 04:08

  PNGOUTWin Release Candidate

  With the default settings, I get a slightly corrupted image on "Longest Match" compression. The other methods seemed to work OK. I'm going to rerun the "Longest Match" test, to see if it corrupts again.
  
  (In my test PNGOUTWin's memory usage, though quite high, should have been OK on a 256MB machine if not too much else was running. Just for the record, I'm using XP-SP2 on 512MB RAM and a Pentium 4)
  
  EDIT: Exactly the same results again with "Longest Match".
  
  Just to clarify, all the other results seemed fine on the first run through, and I haven't had any crashes.
• zooloo at 2006-04-08 07:08

  Re: crash

  Thank you for your interest in PNGOUTWin.
  I'm testing right now with this file and the default settings. Were you using the default settings? If not, then let me know and I can test on my machine.
  
  [Edit] I was able to compress the file by 10% using the default settings. My memory usage was about 50 MB per compression thread. It could also be a platform difference. The only officially supported platform at this point is XP. In the future more platforms may be supported, but right now we don't develop or test on anything other than XP.

  Thanks for the info. The crash appears to be independent of the settings (including default), at least I couldn`t find a combination which takes that file. It happens immediately after pressing OK in the multiple trials setup, even in the "No compression (Fastest)" mode. The main GUI then states "Reading" and the original size and remains this way until I close it.
  
  If the big version (rather than the 561 x 600 one shown at the image description page) works at XP, it looks like a platform difference indeed. Anyway, the whole issue is no biggie. In fact, that pic is the only one I have encountered so far triggering this problem. I could feed it to pngout.dll instead, although, of course, I`d miss quite some speed as well as the multiple trials thingy there.
  
  [EDIT]: Could the trouble, by any chance, be caused by my gdiplus.dll version 5.01.3102.1360? I remember that PNGOUTWin didn`t start right away after installing because it was missing that library. I searched for it and copied the newer of the two versions I found into the PNGOUTWin directory. Actually, PNGOUTWin has liked it since then.
  Edited at 2006-04-08 09:28
• David at 2006-04-08 07:18

  [...]
  I could feed it to pngout.dll instead, although, of course, I miss quite some speed as well as the multiple trials thingy there.

  I sent you a PM with a location where you can download the file I was able to create with PNGOUTWin.
• counting_pine at 2006-04-08 11:54
  This probably isn't much help, but I tried it on a Win2K computer (512MB) with that version of gdiplus.dll, and didn't get any crashing.
  
  I'm consistently getting the "Longest Match" image corruption though, and I'm pretty sure it's a bug in the compressor. It's possible to take a much smaller section of the large PNG (a row that gets corrupted, with a few rows either side) and it will still get corrupted.
  
  The easiest way to verify this corruption is by using TweakPNG, since it won't display an image if the Adler32 checksum is wrong. It's often possible to see it in an image viewer as well, since if a row filter byte gets corrupted then the whole row can stand out.
  
  I can post an example if required, but I'm pretty sure anyone else will be able to reproduce it for themselves.
• Awesoken at 2006-04-08 12:19

  PNGOUTWin Release Candidate

  I can reproduce the longest match bug. It's a fault in my compressor but I'm not sure what it is yet. Thanks for the tips.
• zooloo at 2006-04-09 00:42

  The crashing file was the cause - sorry!

  I sent you a PM with a location where you can download the file I was able to create with PNGOUTWin.

  Thanks for your help, David.
  
  When playing around a little further with the result file you provided to me, I found out that it worked just fine with PNGOUTWin. That made my original file rather suspicious, and in fact, when I checked it with TweakPNG (thanks to counting_pine for the pointer), that file turned out to be corrupted. Please, see the comment in my original post: http://jonof.edgenetwork.org/forum/viewtopic.php?p=5858#5858
  Edited at 2006-04-09 03:27
• counting_pine at 2006-04-09 01:45

  PNGOUTWin Release Candidate

  It sounds like the file didn't fully download or something. I've just tried downloading it, chopping off a few KB with a hex editor and running it through PNGOUTWin, and I managed to get it to crash.
  
  Does the corrupted file have the same size as the one one the web?
• zooloo at 2006-04-09 03:19
  No, the file was not exactly as big as was stated at the website. I just failed to notice the difference. :?
  
  I have tested a few arbitrary png fragments now. Apparently, size doesn`t matter, as long as the invalid/corrupted file starts with
  

  89 50 4E 47 0D 0A 1A 0A

  
  (which is the smallest crasher I could find).
  
  
  zooloo
• counting_pine at 2006-04-09 03:52
  That makes sense.
  

  89 50 4E 47 0D 0A 1A 0A

  
  That's the 8-byte PNG Header. Any PNG reader should automatically return an error if it doesn't find those. After that, I think PNGOUT is quite lenient on PNG integrity. I've occasionally found that useful, although I guess PNGOUT could do with enough sanity checks to prevent itself from actually crashing.
  
  (In any case, well done for inadvertently bringing a compressor bug to light : )
• David at 2006-04-11 14:26

  new build released

  I released 1.0 Build 60411 to http://www.pngoutwin.com
  
  This has one change:
  
  * Fix: Corrupt files created with longest match strategy
• David at 2006-04-21 06:53
  1.0 Build 60417 released to http://www.pngoutwin.com
  
  Changes for this build:
  
  * Fix: Use new file open dialog box
  * Fix: Drag and drop for some third-party file managers
  * Fix: Can't delete a folder after file is chosen until app is closed
• Maren at 2006-04-21 14:28

  PNGOUTWin Release Candidate

  Great!, now it works with ACDSEE Classic :)
  
  Now a question. Why do clipboard images (pasted into PNGOUTWIN with Ctrl-V) compress less than the same opened or dragged & dropped?.
• David at 2006-04-22 00:08

  Paste behavior

  [...]
  Now a question. Why do clipboard images (pasted into PNGOUTWIN with Ctrl-V) compress less than the same opened or dragged & dropped?.

  When the image is pasted, it is saved out with GDI+ before it is processed by the compression code, and GDI+ is saving the image in RGB+Alpha format. The reason this was done was that it was smaller than the closest fast algorithm available to pngout.
  As a workaround, use the multiple trials dialog and change the color type to RGB and set the block split size to 256 to get the same result.
  
  I'll add this to the list to get fixed in a future build. It would be better to sacrifice a bit in having a larger file initially if the end result will be smaller.
• Maren at 2006-04-22 07:40

  PNGOUTWin Release Candidate

  Thanks for the hint.
• counting_pine at 2006-04-23 00:33
  It would be good if PNGOUT could have an intelligent colour type reduction option, which can tell whether an image can be converted to a smaller colour type, by removing an alpha channel, or converting to greyscale or a plaette image.
  
  Please, would it be possible to get PNGOUTWin to add images specified as command line parameters? It would be nice to be able to add PNGOUTWin to the Send To or Open With menus.
• David at 2006-05-08 23:40

  support for "Send To"

  [...]
  Please, would it be possible to get PNGOUTWin to add images specified as command line parameters? It would be nice to be able to add PNGOUTWin to the Send To or Open With menus.

  This has been checked in and will be in the next build.