- This component was not published to the rpm registry anyway
- We depended on the repo’s master branch which can break things for everyone
- Its repo was not getting much attention which meant
* no tests, no coverage report
* no linting
* no package linting (e.g. had 2 dependencies that weren’t actually used)
It will be simpler to manage this way
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.
- %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 current code doesn't create an output structure for them, so we don't create thumbnails.
This is good since the thumbnail generation would likely fail.
However we still try to render thumbnails in the themes.
The themes could be smart enough to skip invalid files, but it's easier to ignore them from the start.
1. Move from a JSON index to a SQLite database.
- This allows the indexing to be interrupted & resumed
- Updating the index consumes less RAM than loading / saving an entire JSON object
- Loading the index consumes less RAM since it can be streamed, only exacting the properties we need every time (instead of loading all EXIF data in memory, only to discard most of it later)
- These make a big difference when processing 10,000+ photos
2. Switch from <glob> to a manual <readdir>
- Glob would take several hundred or GB of RAM when asked to find several thousand files
- Manual approach with <micromatch> library does the same thing in a fraction of the time / memory usage
3. Exiftool optimisations
- Run 1 exiftool process per CPU, still in batch mode (divide all files to be read into 1 bucket per CPU)
- Stream the exiftool output instead of buffering it in memory
