Forum archive

PNGOUTWin Beta 2 Invitation

Return to forum index

• David at 2006-03-13 12:33
  http://www.pngoutwin.com has been updated with Beta 2.
  
  If you have the time, please give the new build a try. If you have any feedback, then please send it to customer-service at ardfry.com.
  We hope to post a release candidate in two weeks, so if you can evaluate the new build in the next week or so, then we may be able to incorporate your feedback into the release candidate. Many of the items in the list below were requested by participants in Beta 1.
  
  The following list details what's new in the build:
  
  + Multiple trials w/ image cache
  + Option to preserve file times
  + Default strategy property page
  + Preserve chunks property page
  + Full row select style added to listview
  + All image types pick in dialogs
  + Store result of choices and display to the user
  + Remember file type setting in dialog box
  + Drag and drop of file or folder on main window
  + Subdirectories checkbox to folder browser
  + Properties dialog box for completed items so that you can see what settings products the file
  + Delete key cancels selected job
  + Paste image from clipboard
  + Context menu to open containing folder of the result or to open the resulting image
• Awesoken at 2006-03-13 14:35
  I'm happy to report that all features of the command line version (PNGOUT.EXE) are now implemented in PNGOUTWIN.EXE (Beta 2).
  
  Here are some new features of the PNGOUT engine that are included with Beta 2:
  * Autodetection of filter type and block split threshold; default settings now work much better.
  * Option to use randomized initial huffman tables. If you run lots of trials using this, you can often save a few extra bytes.
  * Slightly more efficient (on average) storage of Huffman tables.
  * Fixed bug with processing of "bKGD" chunk.
• Maren at 2006-03-14 07:27
  The "Xtreme" mode is just amazing, I didn't know further PNG compression was techinically possible. Good work :mrgreen:
• ace_dent at 2006-03-14 19:50

  Congratulations!

  Nice work guys. I think this will form a neat product that should do well.
  I was excited to try out the new crunching abilities against the 7,000+ icons that make up OpenOffice. I've had a quick play, and here are my initial findings:
  - Compression is indeed slightly better than my previous brute force method (~1-2% for some icons).
  - The greatest strength is the reduction in time to achieve this (~1/2 the time for my script- and with better results!)
  - However... I've experienced a few corrupt images (could be my computer- I will investigate further as time allows).
  - More annoying is the limitations of the GUI. I would like to just select the whole directory (of 7k images) and let 'P.O.W.' do its thing. However, following progress in TaskManager I could see memory usage climbing- until I had to kill the software when it hit ~2GB. It seems the memory (leak?) is due to populating the job list in GUI. (7k images x 100 trials...). I think if people are to run this against a whole website, then there might well be 1000's of images.
  - Before final release the GUI (and website!) could do with some polish. It is currently not up to a commercial standard IMHO.
  
  Please feel free to test POW against my image sets here:
  http://students.bath.ac.uk/ea2aced/OOo/default_images02.tar.gz
  http://students.bath.ac.uk/ea2aced/OOo/industrial01.tar.gz
  http://students.bath.ac.uk/ea2aced/OOo/crystal01.tar.gz
  
  Regards,
  Andrew
  
  PS- Please provide more documentation about the multiple-trial options, and how the combinations work together. i.e. What does 'Xtreme' mode do differently? How does 'Auto' block theshold work?
• David at 2006-03-15 02:24

  Re: Congratulations!

  [...] However... I've experienced a few corrupt images (could be my computer- I will investigate further as time allows).
  - More annoying is the limitations of the GUI. I would like to just select the whole directory (of 7k images) and let 'P.O.W.' do its thing. However, following progress in TaskManager I could see memory usage climbing- until I had to kill the software when it hit ~2GB. It seems the memory (leak?) is due to populating the job list in GUI. (7k images x 100 trials...). I think if people are to run this against a whole website, then there might well be 1000's of images.
  [...]
  
  PS- Please provide more documentation about the multiple-trial options, and how the combinations work together. i.e. What does 'Xtreme' mode do differently? How does 'Auto' block theshold work?

  Thank you for your interest in PNGOUTWin.
  I will run through your test images to see if I can repro the corrupt image issue.
  I plan on reviewing the memory and GDI usage today and tomorrow. If I find anything significant, I'll update the site with a new build and post a note here. Populating the listview shouldn't use anywhere near 2GB even with leaks. There must be an image leak in the worker threads to reach this amount.
  As for polish, we're bootstrapping Ardfry, so I don't expect all that much to happen polish-wise to either the app or the site until we have some cash flow. As soon as is possible, I plan on updating the UI to look more Vista-like. The site will get some updates as well, but we're pretty focused on shipping 1.0. Ardfry is more of an independent label than a high flying, VC funded wonder boy.
  I will be documenting the advanced options as well by the time we go commercial, but I doubt that we will reveal the details of the algorithms. All I can say about Xtreme is that it tries harder and takes longer, often with better results.
  
  [update 3/14/2006 2:30 PM EST]
  I looked into the memory usage and it is possible to use a lot of memory. I don't believe the current design handles the case of 700,000 trials, although this useS much less than the 2 GB scenario that was described. The only scalable solution would be to store this many trials in a temporary database. I did find a way to use a little be less space, but it's not the ultimate solution, which will have to wait until after 1.0.
  Edited at 2006-03-15 05:46
• Martin at 2006-03-15 05:40

  PNGOUTWin Beta 2 Invitation

  Here are some things I've noticed during a short test:
  - There is no context menu for files which haven't been processed yet
  - The setting for how many threads should be used requires a restart of the whole program
  - I'd prefer to see the properties in a tooltip instead of in a message box, that would be easier, especially for multiple files
  - If I open the open folder dialogue, the previously selected folder isn't selected anymore
  - There's no possibility to remove individual jobs
  - Automatic resizing of the path column by double-clicking the slider does not work
  - The column size isn't saved
  - When I have the multiple trials option activated and add a file to be processed, the custom block split threshold is always activated, regardless of the previously used setting
  - There is no error description (maybe there are just too many colours to fit in some palettes, but who knows?)
  - Xtreme compression is amazing :D
  Edited at 2006-03-15 05:50
• David at 2006-03-15 05:49

  RE: tooltips

  - I'd prefer to see the properties in a tooltip instead of in a message box, that would be easier, especially for multiple files
  - Automatic resizing of the path column by double-clicking the slider does not work

  If you hover over the icon of a completed job, then the properties should show in a tool tip.
  The double click behavior you describe is VB/.NET behavior, but it's not default behavior for a native app. I'll try to add it if there is time and the Win32 API supports this through moderate trickery.
  Edited at 2006-03-15 05:54
• Martin at 2006-03-15 05:54

  PNGOUTWin Beta 2 Invitation

  Indeed. I failed to spot that :)
  Maybe you could also add automatic scrolling to the running job :)
  
  // Edit:
  It seems to forget the priority sometimes :( I've set it to "background", but now it runs with "normal" priority :( At the 1665th job at least ...
• David at 2006-03-15 06:30

  RE: Thread priorities

  It seems to forget the priority sometimes :( I've set it to "background", but now it runs with "normal" priority :( At the 1665th job at least ...

  The priority shouldn't change. Is the dialog showing that the priority isn't set to what you expected, or is there a task manager tool that shows you that the PNGOUTWin worker threads are no longer at a lower priority? How are you determining that this has happened?
• Martin at 2006-03-15 06:59

  PNGOUTWin Beta 2 Invitation

  The setting in PNGOUTWin is still set to background, but the Windows (XP Professional SP2) task manager (Ctrl+Shift+Esc or Ctrl+Alt+Del) shows "normal" priority.
• David at 2006-03-15 07:13

  RE: Priorities

  The setting in PNGOUTWin is still set to background, but the Windows (XP Professional SP2) task manager (Ctrl+Shift+Esc or Ctrl+Alt+Del) shows "normal" priority.

  This shows the priority of the process. The background priority is set at the thread level. In order to see the priority changes, a tool that shows the thread priorities of the threads associated with the process is needed.
• Martin at 2006-03-15 07:35

  PNGOUTWin Beta 2 Invitation

  Process Explorer shows base priority of 8 for every PNGOUTWin thread. When I set the process priority to low using the Windows task manager, the thread priority goes down to 4.
• David at 2006-03-15 07:46

  Thread priorities

  Process Explorer shows base priority of 8 for every PNGOUTWin thread. When I set the process priority to low using the Windows task manager, the thread priority goes down to 4.

  Something weird is going on.
  According to this, the base should be 1 (process priority normal w/ thread priority idle).
  
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/scheduling_priorities.asp
  
  I can set a breakpoint and see the successful call to lower the priority. Perhaps SetThreadPriority is fibbing when it says it succeeded. I can definitely notice a difference in the responsiveness of my pc when I change the priorities, but it doesn't match up with what the tools say--I see the same thing in PerfMon.
  
  I'll add this to the bug list.
  [edit after some testing]
  If you do the following test with the process explorer, you will see that it is working correctly.
  1. Open a large png file.
  2. Go to the PNGOUTWin thread that's using the most CPU.
  3. Examine the priority of this thread.
  It is 1 when the app is minimized w/ smart or when the priority is set to background.
  
  To make this less confusing and more apparent to end users, I'm going to go ahead and make the child processes run at below normal when the worker thread is set to idle priority.
• Maren at 2006-03-15 14:40

  PNGOUTWin Beta 2 Invitation

  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://img217.imageshack.us/img217/2158/pw8fi.png - 148 KB (151,803 bytes)
  The second image recompressed using PNGOUTWIN (Xtreme + no chunks)
  
  Question: why is the fourth image slightly bigger than the third one?.
• Awesoken at 2006-03-15 15:44
  Maren, I looked at your images:
  
  

  1.  ????.??? RGB     ???          (1152054 bytes)
  
  2.  p3yw.png RGB     Mixed filter ( 241550 bytes)
  
  3.  w1rd.png Palette No filter    ( 126500 bytes)
  
  4. pw8fi.png Palette Mixed filter ( 151803 bytes)

  
  
  This looks like a problem with PNGOUTWIN's automatic filter logic. It looks like image #4 re-used the filter of image #2. When the color type changes, it is better to use the default for the new color type. For Palette mode, that would be "No filter". I'll make sure this is fixed for the next version.
  Edited at 2006-03-15 15:47
• Maren at 2006-03-15 15:46
  Thank you :)
• ace_dent at 2006-03-15 19:58

  Still hitting problems

  I'm still getting corrupt images when trying out POW with OpenOffice icons. My system is not O/C and is rock solid. The set I'm working with is the 'default' theme (download link n my last post). It seems the High Contrast (HC) icons are far more likely to cause problems for some reason. Try-out 'avmedia' folder of icons.
  My Settings:
  - Colour type: All ticked (except auto)
  - Filter: All
  - Palette Order: Optimize
  - Block Split: Auto, {0,8,16,32,64,128,256,512,1024,2048}
  - Huffman Tabs: Default (always stays checked?), Randomize
  - Bit depth: All
  -KSFlate : All
  
  Of course just to add to the fun, this issue is not reproducible consistently...
  
  Cheers,
  Andrew
• counting_pine at 2006-03-16 03:44

  PNGOUTWin Beta 2 Invitation

  You couldn't post a corrupted image, could you? That would probably be helpful.
• ace_dent at 2006-03-16 23:40

  Download

  You can download an archive with before and After POW versions; This shows the corruption...
  http://students.bath.ac.uk/ea2aced/OOo/POWissue.zip
  
  Settings used as stated in last post. It seems I only get this problem when processing the whole directory at once. It doesn't occur when processing single images. If there is some memory leak / issue, maybe it could be causing this corruption?
  
  Cheers,
  Andrew
• Awesoken at 2006-03-17 03:42

  PNGOUTWin Beta 2 Invitation

  Ace_dent, thanks for your input. From your corrupt images, it looks like the problem might be related to the palette of the image cache and handling of multiple threads. Unfortuantely, I can't seem to reproduce your problem. Is your machine Hyperthread/Dual Core? Does the problem still happen if:
  * You select only "Keep palette" under the Palette Order options?
  * Select "1 thread" in the PNGOUT advanced settings? (be sure to restart POW for this setting to take effect)
  
  --------------
  I have some general advice on using the Multiple Trials dialog (This is unrelated to the bug above):
  * 8,16,32 are bad choices of values for the Block Split Threshold. They will almost always produce a much larger file. Most images under 2KB work best with just 1 block (which can be selected with Custom:{0})
  * It would be in your interest to choose all 3 Palette Order options. "Optimize" isn't necessarily better than the other 2 options.
• ace_dent at 2006-03-17 06:09
  Thanks Ken for the advice (I will play with those settings as time allows).
  I have a HT P4 but have been using just 1x thread, since POW is such a beast when it comes to hitting RAM and CPU. I will try using just the 'Keep Palette' option to eliminate that variable.
  Cheers.
• ace_dent at 2006-03-17 06:35
  Ok, even with 'Keep Palette' I'm still getting corrupt images. However, this no longer effects the small 16x16 icons just the larger sizes. These are the three trials from around the time one image (avlh02052.png) was corrupted:
  * C=Pal, Filt=0, 4bpp, Huff Blocks=1, Huff Only, Pal entries=15, Rand tables=No. 200->206bytes -3%
  * C=Pal, Filt=0, 4bpp, Huff Blocks=1, Longest Match, Pal entries=15, Rand tables=No. 200->167b 16%
  * C=Pal, Filt=0, 4bpp, Huff Blocks=1, PNGOUT default, Pal entries=15, Rand tables=No. 200->165b 17%
  
  The palette entries are showing as 15 but should be 7. Inspecting the corrupted image it had the palette from 'avl02054.png', which was optimized ~4-5 images earlier!...