Thumbsup used to stop at the first problem processing a file.
This was a problem on large galleries where you’d need to run it again and again, fixing files as you went.
This change:
- skips problematic files and shows a summary at the end
- logs all warnings/errors to <thumbsup.log> when running the default output
Also refactor and cleanup of the logging logic.
GraphicsMagick can’t process animated GIFs well unless all frames are coalesced, which creates very large files.
This means there is a new dependency on Gifsicle which is very good at working with animated GIFs.
- Thumbnails are still processed through GraphicsMagick (more options, e.g. centre-crop)
- Large previews of animated GIFs go through Gifsicle
The startup checks are updated to check for the Gifsicle binary.
Fixes#96.
The index is still updated, and the media folder is still scanned to log how many tasks are required.
This is useful to know what thumbsup is about to do, without actually running the expensive tasks.
- %path expands to the path of the photo/video
- %keywords expands to the IPTC keywords of the photo
- {format} expands to the photo's EXIF date, e.g. {YYYY MM}
The `debug` package reads DEBUG on first require to configure itself.
So far `log.js` is the first file to require it so it works, but if `yargs` started using `debug`
then setting `process.env.DEBUG` would do nothing here.
Instead we can use `debug.enable()` method to set the filter dynamically.
This will help understand usage patterns to know what to focus on, e.g.
- are many people using thumbsup on Windows?
- are there many galleries with > 10,000 photos?
The main changes are
- this introduces relative paths, since some HTML files have to go ".." to get to public/media
- it also introduces the difference between album.path (OS dependent) and album.url (forward slashes)