In the ever-so-slow process of optimizing images I am trying a lot of software, primarily to make life easier. Trimage is the second-best so far.
The whole point of a nice gui for image optimization is to manage the process of getting the smallest file size with the least amount of fuss. Generically, Trimage – modeled on the Mac application ImageOptim – is a shim between users and complex/arcane command-line cantrips for a variety of image tools. It basically tries many different ways to compress an image, using multiple tools, and selects the best results. And it does a great job, but with too much fuss.
Because it works with the libraries and softwares installed on your machine, the results are somewhat dependent on you and your set-up. But no matter what it will be faster/simpler than you manually doing the same thing at the CLI, and most likely more efficient with computer cycles because of how it multi-threads the process.
Which is one of my two complaints about the software.
Once a pile of images are selected to optimize, it appears Trimage counts how many CPUs are available and runs that many shell threads. Naturally each of these intensive processes sucks up 100% (or as near as possible) of the available cycles, even if they are niced[en.WP] down. This is super-efficient of time, putting every last Hz of your computer to work on your project… but also means the machine is a slug until it gets done.
This would be perfect if Trimage were a command line script itself. You could run it on a headless machine (by ‘headless’ in this case I mean a non-graphical operating system) and Bob’s your uncle[en.WT]. But it is a graphical user interface, which means you are sitting there in front of the box twiddling your thumbs for the insane amounts of time this is going to take, going nucking futs because you cannot do anything on the box beyond, maybe, typing a blog entry about how slow your machine is running.
However, the ultimate issue with the software is its memory leak[en.WP]. After a few hours there will be a noticeable chunk of RAM in use. After a day or two it is ginormous, and progress has slowed to almost nothing. Shutting down the program and restarting it magically releases everything and, after re-selecting the files to be compressed, it happily eats your CPUs again.
Which means, in practice, I am a manual load balancer. I load up the program and a small number of files on a machine and go do something else. I come back every couple hours to see if it has finished/locked up, kill and restart the app and load a few more. Wash, rinse, recycle. On several boxen.
What I would like to do is break the task into several pieces for the several machines (I have more than 5 000 images in this inbox, and about twice that many in the other inboxes,) load them all up once, and walk away from them knowing it will take a week or a month or whatever, but it will just work. The memory leak means I cannot.
I would also like to be able to decide how many threads it runs, how much of the CPU it grabs. Half would be fine, even 75%, for the machine I am sitting in front of. It can eat 100% of the other boxen, but I need something responsive so I can continue working on something else, something more intensive than word processing. Like, say, listening to audio streams while browsing news sites, or maybe watching cat videos.
On the other hand, Trimage is the second-best image optimizer I have found on performance and output measures, so long as it has enough RAM available.