Reduce image sizes
Shrink photos already stored
Replaces oversized images with smaller versions of the same picture: same shape, same Created By and Modified By. You see what it would save and approve it before anything is replaced. Read the warning above carefully, because this is one of only three places in ShareMaster that deletes permanently by default rather than recycling.
What it does
- Which images are worth shrinking and what each would save, before anything changes.
- What was actually replaced, and what it saved, once the run finishes.
- Why every other image was left alone.
How it runs
- Sign in and pick a scope. Sites, libraries or folders.
- It measures for real. Each candidate is downloaded and re-encoded in memory to find the true saving. An estimate would not be worth approving.
- Approve what to replace. Per image, from the report. Nothing is replaced without your approval.
- It replaces, then reclaims. The smaller image is uploaded as a new version, then every earlier version of that file is permanently deleted (or recycled, if you chose that) so the space is freed the same day. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
Before any file is read, each site is checked for retention that keeps old versions. On a run that will replace files, ShareMaster also tries a small test file of its own on the site, which is recycled afterwards. If a site keeps old versions, you are told before anything changes and asked whether to reduce there anyway or leave that site alone, because replacing an image there frees nothing. A site that refuses the test file because it is over its storage limit is left alone entirely. Hidden and system libraries are skipped unless you include them, the library's Forms folder is never included, and a library that requires check-out, needs content approval, uses Information Rights Management or that you cannot write to is left alone with the reason. Libraries with version history switched off are named up front, because an overwrite there cannot be undone from SharePoint.
Which images qualify is decided from the file's actual content, not its extension. Animated GIFs, images below the minimum size, images with too many pixels to process safely, formats it does not convert, and images that would not get meaningfully smaller are skipped with the reason. Each remaining image is downloaded once and re-encoded in memory, and the smaller version is decoded again and checked for the same dimensions, aspect ratio, colour space and page count before it can go anywhere. Images are only ever scaled down in proportion; the one change of shape allowed is applying the photo's own rotation tag.
Immediately before replacing a file, the run reads its live state again. A file that has changed since the scan, is checked out, is waiting for approval or is declared a record is left alone. A file with a retention label that does not block changes is only replaced after you have been asked about that site. If you asked for local copies, the original is saved to your folder first, and a file whose copy cannot be saved is not replaced. The smaller image is then written to the same file as a new version, carrying the original Created and Modified dates and Created By and Modified By. If SharePoint will not keep those, the original image is put back.
After a successful replacement, the file's version history is read again and every version except the new current one is removed: permanently deleted by default, or moved to the recycle bin if you chose that. Nothing else can be deleted by this feature: no file, folder, list or item. If clearing the old versions fails, the smaller image stays and the row says the old versions were kept; if several replaced files in a row on one site keep their old versions, you are asked about that site. Clearing old versions that an earlier run left behind is a separate opt-in, limited to files named in that earlier run's own record.
A run that only reports downloads and measures but writes nothing to SharePoint. On a run that replaces files, each one is recorded on this computer as about to change before the write and as done or failed after it. A resumed run skips files already done and re-checks any whose outcome is unknown against SharePoint. A file that fails is counted, named and skipped, and the run carries on. The report lists every image, including every skipped one with its reason, and the run is kept in history.
What you need
- Write access to the libraries in scope, and enough rights to delete versions.
What it will not do
- By default the earlier versions are permanently deleted, not recycled: a recycled version still counts against quota until the bin is purged, so recycling frees nothing on the day. Recycling is offered for anyone who would rather keep a way back. Either way it touches only the earlier versions of files this run has just replaced, all of them, never the current version and never anything else.
- Aspect ratio is never changed. Images are only ever scaled down proportionally.
- It downloads every candidate to measure it, so a large scope costs real time and bandwidth.
- The report's before-sizes cannot be recovered any other way once the files are replaced. History keeps a copy.