Forum archive

PNGOUTWin Beta 2 Refresh

Return to forum index

• David at 2006-03-18 09:18
  www.pngoutwin.com has been updated with a new build of Beta 2.
  The following list details the updates.
  
  + Significant performance improvements for "Xtreme" strategy
  + Info tips for pending jobs
  + Improve automatic filter logic
  + Virtual list view yields roughly 50% less memory usage by main UI
  + No restart required to change the number of worker threads
  + Save last opened directory in open folder dialog box
  + Resize column on header double click
  * Multiple Trials Dialog: auto block split was always selected
  * Fix for corrupted palette when compressing multiple files
  * Memory leak fix for cancel during early image compression
  * Memory leak fix for non PNG images with palettes
  
  And now it's time for some Guinness and corned beef & cabbage.
• TX at 2006-03-18 11:57
  Mm.. why is this a new build of beta 2 and not just "beta 3?"
  
  Thanks for the updated build.
• David at 2006-03-18 13:03

  RE: Build names

  Mm.. why is this a new build of beta 2 and not just "beta 3?"
  
  Thanks for the updated build.

  Beta 1 to Beta 2 was a significant jump in content.
  The refresh is mostly bug fixes and enhancements based on items found this week. It's not nearly as much content in terms of new features to justify calling it Beta 3.
• Maren at 2006-03-18 17:03

  PNGOUTWin Beta 2 Refresh

  The same problem I mentioned in the "PNGOUTWin Beta 2 Invitation" thread has just worsened, take a look:
  
  1. http://rapidshare.de/files/15528995/O.rar.html - 1.09 MB (1,152,054 bytes)
  Original Image.
  
  2. http://img217.imageshack.us/img217/749/p3yw.png - 235 KB (241,550 bytes)
  Compressed using PNGOUT (simple drag and drop, no extra commands)
  
  3. http://img123.imageshack.us/img123/1321/w1rd.png - 123 KB (126,500 bytes)
  Compressed using PNGOUTWIN (Xtreme + no chunks)
  
  4. http://img127.imageshack.us/img127/8814/pw1mb.png - 235 KB (240,721 bytes)
  The second image recompressed using PNGOUTWIN (Xtreme + no chunks)
  
  
  PD: it really is faster :shock:
• David at 2006-03-19 00:58

  RE: Compression behavior

  The same problem I mentioned in the "PNGOUTWin Beta 2 Invitation" thread has just worsened, take a look:
  
  1. http://rapidshare.de/files/15528995/O.rar.html - 1.09 MB (1,152,054 bytes)
  Original Image.
  
  2. http://img217.imageshack.us/img217/749/p3yw.png - 235 KB (241,550 bytes)
  Compressed using PNGOUT (simple drag and drop, no extra commands)
  
  3. http://img123.imageshack.us/img123/1321/w1rd.png - 123 KB (126,500 bytes)
  Compressed using PNGOUTWIN (Xtreme + no chunks)
  
  4. http://img127.imageshack.us/img127/8814/pw1mb.png - 235 KB (240,721 bytes)
  The second image recompressed using PNGOUTWIN (Xtreme + no chunks)
  
  
  PD: it really is faster :shock:

  Are there some other settings that you haven't listed?
  With the beta 2 refresh, these are the numbers I get.
  2. O.bmp w/ simple D&D or with multiple trials and defaults: 126914
  3. O.bmp w/ Xtreme w/ simple D&D or with multiple trials defaults, strategy = Xtreme: 126500
  4: Image from 2 compressed w/ defaults and strategy = Xtreme: 126500
  
  [edit: I missed that 2 is from pngout.exe. I'll test this now.]
• Awesoken at 2006-03-19 05:06

  PNGOUTWin Beta 2 Refresh

  Once again, here's a summary (for my own future reference):
  

  1.bmp: 1152054 bytes /c2 /f-1
  
  2.png:  241550 bytes /c2 /f5, in:#1, PNGOUT (defaults)
  
  3.png:  126500 bytes /c3 /f0, in:#1, PNGOUTWIN (defaults using Extreme, all versions)
  
  4.png:  240721 bytes /c2 /f5, in:#2, PNGOUTWIN (defaults using Extreme, beta 2 refresh)

  
  
  The "auto" logic is designed to re-use the input settings if the input is PNG format. I am not planning to change this. The reason is: if you run a million trials, and some non-obvious format turns out to be smallest, then you'll want to re-use these settings for future trials. Obviously, this logic is bad when the original settings are bad to begin with. That's what trials are for. No algorithm is going to find the best settings in just 1 trial.
  
  If the input is not PNG format, then (ideally) it should reduce the image to palette mode if it can fit in 256 colors. PNGOUTWIN does this. PNGOUT does not (yet), and this is where (I define) things went wrong for you.
• Maren at 2006-03-19 07:03
  Does that mean a workaround would be converting the image to BMP prior to compression?.
• David at 2006-03-19 07:14

  RE: Optimal Image Compression

  Does that mean a workaround would be converting the image to BMP prior to compression?.

  I'm not sure "workaround" is the right word here.
  The simple UI (that is, with multiple trials turned off in the advanced settings) will try to do its best for a single trial.
  As Ken said, no algorithm can find the best solution in one trial. The solution is to turn on multiple trials in the advanced settings and run trials with different sets of options. There is no need to convert the PNG to a BMP file.
• Awesoken at 2006-03-19 07:32

  PNGOUTWin Beta 2 Refresh

  A more sensible 'workaround' would be to use the multiple trials dialog of PNGOUTWIN. Under Settings.. Advanced, select "Show multiple trials dialog after folder/file operation". For p3yw.png, select Palette under Color Type. Or if you don't want to think, just select them all. : ) You can usually gain a lot by playing around with the other settings.
  
  I realize it's not practical to run a file through every possible setting. It's also not realistic to expect people to learn the pros and cons of each setting in the trials dialog. In the future, I plan to add scripting support. The goal would be to design scripts that think like an experienced PNGOUT user. The script would choose trial options based on the results of previous trials. It might even be programmed to abort a run if it didn't look promising after the first few passes. The point is: a script would give newbies the ability to compress a PNG file just as effectively as I could do it manually - in about the same amount of time. All you would have to do is pick your favorite script : )
• Maren at 2006-03-19 19:33

  I realize it's not practical to run a file through every possible setting

  Actually I wouldn't mind going through this process, so...if possible, what should I change/do to make PNGOUTWIN try every possible setting?.
  
  http://img301.imageshack.us/img301/8621/settings5iy.png
  
  By the way, an option for sorting columns would be welcome :)
• Awesoken at 2006-03-20 05:54
  So you have time to kill, eh? : )
  
  * For color type, deselect auto and select everything else.
  * For filter, deselect auto and select all.
  * Select all 3 palette order options.
  * Select all 3 initial huffman tables options.
  * For block split threshold, select auto and custom. Under custom, manually write in a lot of values. For example: {0,60,70,80,90,100,120,140,170,200,240,280,360,500,700,1100,1600,3000} Of course you can always write more if you have the time. Also, if you use randomized initial huffman tables, it doesn't hurt to write the same block split threshold values several times : )
  * For bit depth, deselect auto and select all.
  * Select all KSFlate strategies.
• psychorosti at 2006-03-20 07:19
  Or graphical :
  
  http://img377.imageshack.us/img377/8499/jonofpngoutwinselectalloptions.png
  
  
  BEWARE: Those Settings as listed above (with 18 split-block treshold values) creates 37.620 JOB's per FILE!!!
  Even if not all options will apply for each file and therefore causing an error making the job not to be executed (incorrect bit-depth/filetype etc.) still remember, if you want to convert only 200-files with this settings it will create a list of 7.4 million JOBs. Suggesting that it will take 42 seconds for all jobs in average and half of all jobs not even to be executed, the compression progress would take about 5 YEARS :arrow: THAT's really crazy insane!
  Edited at 2006-03-20 07:48
• Maren at 2006-03-20 07:46
  Thank you, but actually I don't have that much of time, just 3 computers :mrgreen:
  
  Another good thing to have would be a text report telling you which combination of settings led to the smallest file, so you can try it with similar images.
• David at 2006-03-20 13:12

  RE: Multiple Trial heuristics

  There is a balance between the number of trials and the complexity of the image. The smaller the image, the more sense it makes to run multiple trials. If it's a larger image, then the cost/benefit ratio of compressing the file probably doesn't justify spending a long time computing the absolute smallest image unless it's something like the main logo for your site. One of the major uses of PNGOUT is for Java MIDP games, which have very small images and incredibly tight space constraints. Their games are downloaded tens of thousands of times and must fit into a small jar file with a hard limit on the size. For them, running even hundreds of thousands of trials does not take very long, and there is a definite business case for spending the computing time, which usually numbers in the hours or in some cases even less than an hour.
  If the image is larger, then you will probably get the most return on computing time by choosing all color types and all filters with just a few block split sizes and Xtreme (maybe PNGOUT default, but it's usually beaten by Xtreme) compression. This won't work in all cases and all applications, but if I had 200 images to process that were of moderate size, then those would be the settings that I would choose.
• Maren at 2006-03-20 13:52

  PNGOUTWin Beta 2 Refresh

  I've been using PNGOUT mainly for compressing very LARGE files. I'm spending my spare time working as a freelancer graphic designer.
  
  The resulting images of my work are often as big as 250/300 mb's, but recently the guy who gets them plottered told me I could start using PNG's if I wanted (for a reason or another, he never managed to make the damn thing work with anything but tiff's before). Now, thanks PNGOUTWIN, I can usually fit several pics in my 128mb pendrive :)
  
  As for smaller images, well, my website is hosted on a free server, hence every single byte counts at the end.
• counting_pine at 2006-03-21 10:46
  This is shaping up to be a really great program :)
  
  

  Also, if you use randomized initial huffman tables, it doesn't hurt to write the same block split threshold values several times : )

  That's quite a hackish method of doing it. It also means that if "Default" (in the "Initial Huffman Tables" section) is checked, it will repeat those trials, even though (I think) they'll produce the same results each time.
  
  If I could make a suggestion: That you put in a box to specify the number of randomizations, and save the user having to artificially inflate the number of options.
  
  This will also allow PNGOUTWin to do some trial reductions, like discarding multiple instances of a specific block split threshold.
  
  PNGOUTWin could also save some trials, by not doing multiple trials when the options aren't applicable. For example, if the output colour type is RGB, you don't need to do multiple trials for different settings of the palette order, Or, for some KSFlate strategies, you can ignore multiple "Initial Huffman Table" or "Block Split Threshold" trials.
  Edited at 2006-03-21 11:55
• David at 2006-03-21 11:10

  RE: Removing Trials

  [...]
  PNGOUTWin could also save some trials
  [...]

  It does some of this already. Multiple bit depth trials only apply to /c3 or /c0.
  It's probably not hard to add more as long as the decision doesn't require knowledge about the format of the image: the trials are generated before the image is read in.
• Martin at 2006-03-21 12:11

  PNGOUTWin Beta 2 Refresh

  Beta 2 refresh keeps crashing when I close it while converting JPEGs. No problem with PNGs.
• David at 2006-03-22 02:50

  RE: Crash during shutdown

  Beta 2 refresh keeps crashing when I close it while converting JPEGs. No problem with PNGs.

  Thanks for finding this. The fix is checked in and will be in the next build.
• ace_dent at 2006-03-22 10:00

  PNGOUTWin Beta 2 Refresh

  Nice to see the last round of fixes... and now a request...
  I only want to have an image updated when the resulting png is actually smaller (ie. 1byte difference or smaller). Currently if the new image is equal in size it is saved. This makes it very hard (by just using timestamps alone), to determine which images have *actually* been further optimized. This in turn makes updating images which are part of a versioning system (CVS, etc). difficult.
  
  Regards,
  Andrew
• David at 2006-03-22 12:08

  RE: overwrite only when result is smaller

  Nice to see the last round of fixes... and now a request...
  I only want to have an image updated when the resulting png is actually smaller (ie. 1byte difference or smaller). Currently if the new image is equal in size it is saved. This makes it very hard (by just using timestamps alone), to determine which images have *actually* been further optimized. This in turn makes updating images which are part of a versioning system (CVS, etc). difficult.
  
  Regards,
  Andrew

  This wasn't the way I coded it, but it's what I was thinking when I designed it. The fix has been checked in and will be in the next build.
• counting_pine at 2006-03-22 12:51

  Re: RE: Removing Trials

  It's probably not hard to add more as long as the decision doesn't require knowledge about the format of the image: the trials are generated before the image is read in.

  Yeah, don't worry, I appreciate the way the trials are generated beforehand, so the things I suggested are compatible with this.
  
  If you don't mind, I have another request, that you change the Ratio column to report the ratio of PNGOUT Size to Size (i,e, floor(100 * PNGOUTSize / Size) ), rather than the percentage of the size reduction.
  
  The main reason I ask this, is so that an decrease of at least one byte will make the ratio column display 99% or lower, and if the size doesn't decrease the ratio will be 100% or higher. And you would easily be able to tell whether the file has shrunk or not by checking the ratio column. At the minute, if the file size is the same to within +/-1%, then the ratio will just be 0%, and you have to compare the size with the PNGOUT size to see whether it's any smaller.
• Martin at 2006-03-26 19:48

  PNGOUTWin Beta 2 Refresh

  PNGOUTWin keeps displaying "Running" after all jobs are finished (some of them had errors, I think because the colours didn't fit in the palette, it would be nice to be able to see why an error occured).
  
  And I'd like to be able to hide columns and to add columns showing the used compression options.
  
  Automatic resizing by double-clicking the column slider still doesn't work properly for the path column.
• David at 2006-03-28 02:14

  PNGOUTWin States

  PNGOUTWin keeps displaying "Running" after all jobs are finished (some of them had errors, I think because the colours didn't fit in the palette, it would be nice to be able to see why an error occured).
  [...]

  This is by design. The states are Running, Paused, and Stopped. If there are jobs running, then this is displayed as well.
  
  Correct autosizing of the path column is in the next build.
  
  The ability to choose columns is on our road map for post 1.0.
• Martin at 2006-03-28 12:41

  Re: PNGOUTWin States

  The ability to choose columns is on our road map for post 1.0.

  Sorting would also be useful :)