Empty images after running imagemin repeatedly

[snowman-repos]

• Freshly installed copy of Grunt 0.4.1 and grunt-contrib-imagemin 0.5.0
• No other tasks in the Gruntfile, just imagemin
• 3 fresh JPGs in the /images folder (1 image is 427kb)
• Running grunt:imagemin or grunt the first time results in over-optimised (blurry) images in the images/optimised folder. The 427kb jpeg reduced to 66kb, although the CLI reports "(saved 426.80 kB)".
• Running subsequent times results in empty (0kb) images. The command line continues to report "(saved 426.80 kB)".

imagemin: {
  dynamic: {
    files: [{
      expand: true,
      cwd: 'images/',
      src: ['*.{png,jpg,gif}'],
      dest: 'images/optimised/'
    }]
  }
}

[Nooshu]

I'm also having the same issue. Same setup as above. Version 0.4.1 works as expected. Version 0.5.0 breaks.

[nigeljohnwade]

I am getting empty images as well. I tried deleteing files in the destination directory before running the command again but I still get empty files on subsequent runs of the command.

[nazimjamil]

I'm experiencing the same issue, as @Nooshu mentions, 0.4.1 works as expected.

[kevva]

Does cache: false work?

[snowman-repos]

yeah that works!

[nazimjamil]

It didn't work for me, I have a feeling I need to clear imagemin cache, where can I find that?

[snowman-repos]

@nazimjamil !!! uncanny to see a fellow Proferian here! what are the chances eh?

[nazimjamil]

@darryl-snow I thought to myself.. 'that couldn't be the darryl-snow I know'! Hope all is well!!

[nigeljohnwade]

Adding cache: false to the files: object did not work, however when I added it to the options: block it works fine again, thanks.

[nazimjamil]

As @nigeljohnwade, adding cache: false to options has worked for me.

[andreyvolokitin]

+1 for issue and cache: false

[flopreynat]

+1 cache:false is working for me too.

[razvanpavel]

+1 cache: false in options fixes this.

[benediktvaldez]

Same issue here, +1 for options: { cache: false } fix

Is this desired behavior though?

[ihr]

+1 options: { cache: false } works for 0.4.1 & 0.5.0, however, make sure that you do not copy the files before the imagemin task, as described in this issue: #69

It's seems like grunt-contrib-imagemin overwrites the default cache: false of image-min library

[franksmule]

Thanks cache:false fixes problem, seemed to start when new file was introduced

[cmegown]

I'm also having this problem. Running Grunt 0.4.2 and grunt-contrib-imagemin 0.5.0 on Win7x64.

imagemin: {
    dynamic: {
        files: [{
            expand: true,
            cwd: 'content/application/images/',
            src: ['**/*.{png,jpg,gif}'],
            dest: 'content/application/images-built/'
        }],
        options: {
            cache: false
        }
    }
}

Adding the cache: false bit prevents there from being any build errors, but processing the images seems to take 3 or 4 times longer and always says the images are already optimized. I've noticed that if I take off the cache option, and --force my way through the build until all the images are processed, things tend to work fine after that.

[fisher-]

cache: false works, thanks @kevva :-)

[Siyfion]

Also getting this issue and it also seems as though setting cache: false worked.

[maboiteaspam]

+1 to the cache:false solution, got exactly the same problem when i upgraded to 0.5.0

[eliranmal]

affects me, too.

[chaselee]

This affects me as well. cache: false works, but it slows down the build substantially, so I wouldn't consider it a long-term solution to this issue.

[mfrye]

Same here. cache: false worked for me too

[maboiteaspam]

@chaselee, did you try tschaub/grunt-newer ? could make the work.

[chaselee]

will definitely look into that. thanks @maboiteaspam!

[chaselee]

using grunt-newer worked great. thanks again @maboiteaspam.

[rawtaz]

Given the config @darryl-snow pasted will make Grunt return a list of files that include the optimized ones. I.e. after the first run, the next time you run imagemin the source files will include the previously created optimized files as well, and that's hardly what you want.

Try changing the config to this:

imagemin: {
  dynamic: {
    files: [{
      expand: true,
      cwd: 'images/',
      src: ['*.{png,jpg,gif}', '!optimised/**'],
      dest: 'images/optimised/'
    }]
  }
}

That should exclude the generated files from the list of source files to process.

[bwinchester]

Yeah, this is weird, I am running 4.1 on windows 7 and haven't had any problems until today. Our CI server does an npm install on every build and ran into build failures ENONET. My local dev box can still use imagemin even after I upgrade to 5.0 version. Taking it out of the build until I can figure out what changed all of a sudden.

[kevva]

I've published new versions today. Could you specify where the problem occur?

[bwinchester]

k, I just deleted my 4.1 imagemin and npm installed save dev of the latest 5.0 version and I get this error on a forced build to try and get a better error status:

Running "imagemin:main" (imagemin) task
Warning: Error: spawn ENOENT Used --force, continuing.
Fatal error: Cannot read property 'diffSizeRaw' of undefined

[vladikoff]

Try version 0.6.0-pre by installing it from GitHub via npm install gruntjs/grunt-contrib-imagemin
Please report any errors you get with a full error log, operating system, version of Node.JS.

[bwinchester]

Using 0.6.0-pre this morning, on Win 7 64 bit, node v 0.10.25 . With these settings in gruntfile

imagemin: {
  main:{
    files: [{
      expand: true, cwd:'dist/',
      src:['**/{*.png,*.jpg}'],
      dest: 'dist/'
    }]
  }
},

and this is its output. On the 5.0 version, when I forced the build, due to the error, it would give more specifics on the imagemin task failure. on the .6-pre version, forcing does not add any details to the failure.

$ grunt build
Running "jshint:main" (jshint) task

23 files lint free.

Running "clean:before" (clean) task
Cleaning dist...OK
Cleaning temp...OK

Running "less:production" (less) task
File temp/app.css created.

Running "dom_munger:readcss" (dom_munger) task

Processing index.html
Wrote link[rel="stylesheet"].href to dom_munger.data.appcss

Running "dom_munger:readscripts" (dom_munger) task

Processing index.html
Wrote script[data-build!="exclude"].src to dom_munger.data.appjs

Running "ngtemplates:main" (ngtemplates) task
File temp/templates.js created.

Running "cssmin:main" (cssmin) task
File dist/css/app.full.min.css created.

Running "concat:main" (concat) task
File "temp/app.full.js" created.

Running "ngmin:main" (ngmin) task
ngminifying temp/app.full.js

Running "uglify:main" (uglify) task
File "dist/app.full.min.js" created.

Running "copy:main" (copy) task
Created 1 directories, copied 20 files

Running "dom_munger:removecss" (dom_munger) task

Processing dist/index.html
Appended to head
Removed link
File dist/index.html created/updated.

Running "dom_munger:addcss" (dom_munger) task

Processing dist/index.html
Appended to head
File dist/index.html created/updated.

Running "dom_munger:removescripts" (dom_munger) task

Processing dist/index.html
Appended to head
Removed script[data-remove!="exclude"]
File dist/index.html created/updated.

Running "dom_munger:addscript" (dom_munger) task

Processing dist/index.html
Appended to body
File dist/index.html created/updated.

Running "htmlmin:main" (htmlmin) task
File dist/index.html created.

Running "imagemin:main" (imagemin) task
Fatal error: spawn ENOENT

[bwinchester]

Found something interesting, this is likely a Windows specific issue on Node and what modules you use for child processes
nodejs/node-v0.x-archive#2318

[CaptainQuirk]

Having the same issue here,

On Ubuntu 12.04
nodejs v0.10.6
npm 1.4.6
grunt-cli v0.1.13
grunt v0.4.4
grunt-contrib-imagemin 0.6.1
load-grunt-config 0.8.0-beta.1

My imagemin config (in a separate imagemin.js file, through load-grunt-config)

module.exports = {
  options: {
    cache: false
  },

  dist: {
    files: [{
      expand: true,
      cwd: 'images',
      src: ['**/*.{png,jpg,gif}'],
      dest: 'images'
    }]
  }
};

A call to grunt -v yields

Initializing
Command-line options: --verbose

Reading "Gruntfile.js" Gruntfile...OK

Registering Gruntfile tasks.
Initializing config...OK

Registering "grunt-contrib-imagemin" local Npm module tasks.
Reading /home/vagrant/public_html/grunt-template/node_modules/grunt-contrib-imagemin/package.json...OK
Parsing /home/vagrant/public_html/grunt-template/node_modules/grunt-contrib-imagemin/package.json...OK
Loading "imagemin.js" tasks...OK
+ imagemin
Loading "Gruntfile.js" tasks...OK
+ default

No tasks specified, running default tasks.
Running tasks: default

Running "default" task

Running "imagemin" task

Running "imagemin:dist" (imagemin) task
Verifying property imagemin.dist exists in config...OK
Files: images/abc-img.jpg -> images/abc-img.jpg
Options: optimizationLevel=7, progressive, cache=false
Fatal error: spawn ENOENT

The file I want to optimize is turned into a 0byte file.

Thanks in advance

[outrightmental]

Having literally the identical issue to @CaptainQuirk right now, also Ubuntu 12.04.

[rafinskipg]

Same issue than @CaptainQuirk , ubuntu 13.10

[rafinskipg]

Seems to be a issue with optipng version, with ubuntu we have optipng 0.6.4 installed, if you update it to 0.7.4 and run imagemin, everything will work fine

Upgrading optipng -> http://kb.imakewebsites.ca/2012/10/16/installing-optipng-0-7-3-on-ubuntu-12-04/

Related issue -> #180

Upgrading optipng solves all the shit

[CaptainQuirk]

No it doesn't.

Downloaded optipng 0.7.4 and I still get the Fatal Error : spawn ENOENT issue

[rafinskipg]

Try upgrading to node v0.10.26 (It's what i have)

And I'm sorry I missread your comment, my problem was with PNG not JPG. Thats why i told about optipng

[rafinskipg]

jpegtran -v
libjpeg-turbo version 1.3.0 (build 20131122)

[CaptainQuirk]

Neither the use of grunt newer nor the installation of optipng 0.7.4 solves this for me. I still get this ENOENT error and any file ends up empty.

[rafinskipg]

For jpeg only, aint it? Check your jpegtran version plis, doland

[dudewad]

Mine dies on png files. The weird thing is that I've been using it for days, without modifying my grunt setup at all it just stopped working. I think this is somehow related to files because I did modify a significant number of files in my image directory.
I feel like it should be testing whether or not it is WRITING to the file it should be READING. That seems obvious. Could be a node issue? Bummer, because by now I could have optimized my files by hand anyways....