Get a copy of the latest build of ImageOptim from http://cloud.zoooot.com/PFJk and try out the AppleScripting: do queuecount command - compare against countProcesses(). Also test tell application "ImageOptim" to quit

- @jamesstout

JPEGmini: http://www.jpegmini.com/

New versions of ImageOptim and ImageAlpha have come out since the tests were last run.

Using this as a precommit hook git diff --cached --name-only --diff-filter=ACM | imageOptim -a It looks like the commit happens before the program exits

Hi,

I'm wondering what imageAlpha steps does because its so slow. I've ran it on 19000 files for 8 hours and wasn't finished and with only a quarter processed. My mac is a 4,15 Ghz one (mackintosh)

It seems to me that if theres a lot of file, a lot of time is spent on cataloguing perhaps

ImageAlpha: http://pngmini.com/

Change the open command to include the -g param, so that it's not brought to the foreground.

open -g -a ImageOptim.app "$img”

Mac build of pngquant uses Cocoa to read images, and therefore supports any bitmap image format that Cocoa does.

If you run:

pngquant jpeg_streepjes.jpg

you'll get jpeg_streepjes.jpg-fs8.png that is 369 bytes large, down from 179661 :)

Consider adding conversion to WebP

Hi,

Sometimes JpegMini complains it can'r be quit because it's processing files. That's because ImageOptim-CLI thinks Jpeg mini finished and wants tio quit it. Worse, it then launch the ImageOptim process on files not finished by JpegMini.

So it's critical to make sure ImageOptim correctly determine if jpegs mini is done.

Currently it seems ImageOptim_Cli monitors the CPU load of jpeg mini. But facts shows that this deosn't always works.

So I took a look.

1. Improving the current CPU monitoring loop.

It samples the CPU load of Jpeg mini every 2 seconds, and if it's near zero it thinks it's done.
The problem I see with that approach is that the CPU percentage is only sampled once evey 12 seconds. If by bad luck, at the excat moment it samples it, Jpegmini use near zero cpu (maybe because the os starved it's ressources), then the loop is exited, even though in the very next moment the cpu use went up. So very short iddle time can lead to false done message.

To fix this I propose to put the 2 second loop inside a 5 repeats loop, and only exit the main loop if the sum of the 5 repeats cpu percentage is 0.

So we'll have 5 time less chances of bad reports.

But it's still prone to erors, though much less.

1. Examining file usage.

Using opensnoop and iosnoop, you can actually measure file usage of a process.
So I think it's possible to loop till JpegMini file usage returns nothing.

The only problem with that is that it requires the zdmin password, which may be passed in parameter of optimimage_cli

Hi,

I noticed thet when the ImageOptim is ran, it's forced by ImageOptim_CLI, to be on the foregound. Is that normal ?

I think ImageOptim_CLI sends each files top ImageOptim, rather than just the folder. Sometime it fails

LSOpenURLsWithRole() failed for the application /Applications/ImageOptim.app with error -1712 for the file /Volumes/clone FMS/imgs/Jpegs/Group_02/ZZZZZ0007/ZZZZZX0007_list_CZ_5.png.

If having ImageOptim on the foregrpound could be avoided that'd be nice because it can mess with other process on the machine

As mentioned by @joeldbirch in grunt-imageoptim issue 2;

It seems like it simply sets 256 colours, which is safe, but I'd love to be able to set the default options to 32 colours.

ImageAlpha currently doesn't persist overridden default options. Each time you run a file the default values you changed previously will be back in their original state.

Ideally if this were to be implemented, the best place for it would be the core ImageAlpha app's Preferences pane imo (/cc @pornel). It could be possible to do in this project via GUIScripting but that would be quite brittle and again the core app could benefit from this.

Look into using @technopagan's imagesampler.sh to "retrieve a statistically representative number of images from sites indexed by HTTP Archive".

Use that sample to assess whether and by how much the order which ImageAlpha, ImageOptim and JPEGmini are run affects optimisation.

See also: http://tobias.is/geeky/webperf/progressive-jpeg-performance-optimization/

Display file size reduction in and % savings.

Consider keep a record of processed images and their last modified dates in order to not reprocess unchanged images on subsequent runs.

Hi,

I'm using latest everything 190.8.5, Jpeg mini 1.8.1, ImageOptim 1.6.9

often jpeg mini will want to quit

but there's worse, the cli will output an error like can't transform 4,2 in real when jpeg mini runs. The worst part is that ImageOptim-CLI after encountering this error will immediately launch imageoptim, even though jepgmini is still processing files.

That's too bad because imageoptim is to be done after jpeg mini.

Moreover, I thing after a Jpegmini error "4,2", the CLI should stop and return an error so we are warned about it.

Processing 56 images...
ImageAlpha...
JPEGmini...
/Applications/ImageOptim-CLI-1.6.19/bin/imageOptimAppleScriptLib:3422:3459: execution error: System Events got an error: Can’t make "4,2" into type real. (-1700)
ImageOptim
✔ Finished in 21 seconds

As the error isn't stopping the cli, there's no way to be sure all was processed ok.

P.S : I'm using a french OS. In french language decimal number are separated with a comma rather than a dot. Maybe that's a localization issue. I tried to change language and number setting, but it didn't do anything better (I can't logout/restart for now, so I'm not sure it doesn't fixes it)

If -j or --jpeg-mini are provided, also optimise JPGs using JPEGmini

Dear developer,

first, thank you for this great tool! This tool was the only reason why I bought JPEGMini.

I found a bug:

Terminal:
/Users/madrian/image-optim/imageoptim-cli/bin/imageOptim --jpeg-mini --quit --directory /Users/madrian/Desktop/wat/

Immediately after imageOptim starts the JPEGMini I got this popup and error in the terminal:

http://d.pr/i/qWmQ+

Paths containing spaces currently result in errors, these will need escaping or quoting

See http://imageoptim.com/xcode.html and http://imageoptim.com/tweetbot.html

On my machine

$ date
Wed May 22 13:41:09 BST 2013

On a colleague's machine

$ date
Wed 22 May 2013 13:41:40 BST

When running imageOptim-CLI on the latter machine, the following error is encountered as this format does not match our now method.

Failed conversion of ``Wed 22 May 2013 13:39:57 BST'' using format ``%a %b %d %T %Z %Y''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

/cc @jamesstout

I've noticed you're calling pngquant without --quality option. For some images 256 colors may not be enough.

Consider adding --quality=75-100 to pngquant options. This will make it skip conversion if it's not possible to achieve at least "75%" (JPEG equivalent) quality.

Kraken.io's JPEG optimization isn't anything special, it achieves small files sizes by reducing quality heavily.

From the comparison:

JpegMini:
35028 bytes
80.84% saving
10% loss

Kraken.io:
35001 bytes
80.86% saving
68.59% loss

Kraken.io basically ruined the file to save 27 bytes.

You can mark winner only if both size and quality is better (that's clear Pareto improvement).

If quality and file sizes vary it's difficult and subjective. At very least you should use loss/saving ratio to pick the winner, and ideally either quality or file size should be close.

I love the Guard and I love ImageOptim.
Would be perfect to join them.

https://github.com/guard/guard

I'm getting this error: "JPEGmini.app is not installed (https://itunes.apple.com/us/app/jpegmini/id498944723)" although i have the app installed in my Applications folder. It's not installed through App Store, though, maybe that's the issue?

Unlike ImageOptim.app, each call to open -g -a ImageAlpha.app opens a new window.

When I run the following in the command line, ImageOptim is launched as expected, but the System Preferences pane in OS X is also launched. The install was done via npm with sudo and I used the -g flag.

A very good point made on Twitter about running ImageOptim-CLI in a pre-commit hook instead of as part of a deployment build against an entire folder, which is comparatively slow and inefficient.

To support this and #19 "Please consider making a plugin for Guard", we need to support running the CLI against short lists of files.

ImageOptim-CLI has no dependency on Node but is currently only published to npm. Look into also releasing a RubyGem.

Run some tests to see whether existing tools convert images to progressive or not, and whether this can be controlled.

Progressive images are likely to be slower/larger in actual terms but perceptually faster/smaller.

Don't exit shell script until ImageOptim.app has finished optimising all images.

The table column sorting is no longer working at http://jamiemason.github.io/ImageOptim-CLI

If there are subdirectories that have names ending in .jpg or .png then ImageOptim CLI tries to process them and then errors out.

http://pastebin.com/MBmXD4Fw

A better solution would be to add "-type f" to the find command wherever you are using it, so that directories don't get into the queue in the first place.

I realize this is in direct conflict with this issue, but I'd love the capability to skip images that have already been processed. I use this as part of my build process, and it would save a ton of time to skip the files that have been processed before ImageOptim tries to re-optimize them. I would even be happy with this being an option that you would have to pass a flag (such as --skip-processed or -s) to activate.

Generally when I run ImageOptim, the Again button makes it easy to make sure that maximum savings have been achieved. For some images, it can take two or three hits of the Again button to achieve the optimum image.

Can the shell script run ImageOptim repeatedly? This may be slightly tricky because we don't want to run it repeatedly on all files but just the files that had big savings (say >5%) in the previous run. So we may have to keep track of which files had big savings, quit ImageOptim, and then reopen it and only add those files to the queue.

It appears that the number of threads in use by ImageOptim.app can drop below our threshold periodically while processing an extremely large number of files. This results in the CLI exiting too early.

Possible cause may be either large queues of images, or multiple ImageOptim processes.

/cc @jamesstout

Handle case where ImageOptim.app has been quit before it's finished processing our queue.

https://kraken.io

As mentioned by @joeldbirch in grunt-imageoptim issue 2, passing options in (the commonly expected format) of imageOptim -da 'assets/img' is not currently supported.

This will be addressed but in the meantime here is how to combine options.

Combining options

Run ImageOptim

• imageOptim -d path/to/images
• imageOptim --directory path/to/images

Run ImageOptim then quit it when finished

• imageOptim -q -d path/to/images
• imageOptim --quit --directory path/to/images

Run ImageAlpha then ImageOptim

• imageOptim -a -d path/to/images
• imageOptim --image-alpha --directory path/to/images

Run ImageAlpha then ImageOptim then quit ImageOptim when finished

• imageOptim -q -a -d path/to/images
• imageOptim --quit --image-alpha --directory path/to/images

Not yet supported

Until this issue is closed, the following formats are not supported;

Run ImageOptim then quit it when finished

• imageOptim -qd path/to/images

Run ImageAlpha then ImageOptim

• imageOptim -ad path/to/images

Run ImageAlpha then ImageOptim then Quit ImageOptim when finished

• imageOptim -qad path/to/images

Calling from the command line starts off the process, but it does not complete even when the GUI indicates that the image(s) are done processing.

ImageOptim-CLI has no dependency on Node but is currently only published to npm. Look into also releasing a Homebrew package.

When all queued images have finished processing, optionally quit ImageOptim.app.

Document how the stats comparision table data was gathered, and how to reproduce that test yourself if you wanted to test on another result set.

The installation instructions refer to tag 1.6.8, which doesn't exist; attempting this download gives a 404 error.

JPEGMini and TinyPNG are lossy optimizers, so comparing them with lossless optimizers isn't quite apples to apples.

e.g. if you included convert -quality 10 in the test it would probably win in all cases.

At very least I'd suggest highlighting this issue in the table, maybe with additional info about how much quality* was lost, so the reader can judge whether filesize gain was worth the loss.

*) "how much" is hard to quantify. Quality difference is usually measured in PSNR/dB/MSE or (D)SSIM, but those numbers are hard to interpret (e.g. people would think that SSIM 0.995 and 0.98 are almost the same, while in fact that's 4x difference).

To show something like "reduced file size by 20%, but quality by 30%" needs establishing what "100% quality lost" means:

1. Create reference image for what is the "worst possible quality", e.g. compress image as JPEG in 10% quality (quality setting in compressors is also completely arbitrary, so whether that's 1%/5%/20% setting it doesn't matter, it just has to be quality at which you'd call image ruined and unusable).

   convert -quality 10 source.jpg worst.jpg
   

   or 16-color-or-less PNG:

   pngquant 16 --quality=0-10 - < source.png > worst.png
   

2. Measure difference between "worst" image and the original: (compare is from ImageMagick)

   compare -metric MSE source.jpg worst.jpg /dev/null
   

   or better with dssim:

   dssim source.png worst.png
   

3. Measure difference between optimized file and the original

   compare -metric MSE source.jpg optimized.jpg /dev/null
   

   or

   dssim source.png optimized.png
   

4. Calculate: $optimized_difference / $worst_difference * 100 to get how much "% quality" was lost.

Regarding compressor comparison: it's a bit unfair to show sea of red in TinyPNG column for JPEG and GIF optimizations when the tool is strictly for PNG only.

Showing a more neutral "N/A" IMHO would be more appropriate.

Thanks for the project, Jamie. Unfortunately, it is much slower than the original ImageOptim app as it only uses a single core.

In it's current state ImageOptim-CLI looks like a lossy tool because both tests were run with the --image-alpha flag.

Run other tests which do not include this, for better comparison.

You know the drill

countProcesses() probably doesn't need the fancy subscripting. Can probably be replaced with printf $(ps -x -o command | grep '[I]mage[Optim|Alpha]' | wc -l)

- @jamesstout