Processing a folder of images

The queue is on the right. Add images, choose where they go, press Start, and leave it.

Building the queue

Add images…, or drag several files onto the window at once. Items take whatever settings are showing when they are added, so set up the enhancement first if you want it to apply.

Reorder with the arrows, remove one with Remove, empty it with Clear. The queue survives closing the application, so a batch interrupted by a restart is still there.

Saved edits are picked up automatically

If you have saved an edit beside a photograph — same folder, same name, with .lsenhance on the end — queueing that photograph carries the edit with it, and the status line tells you how many of the images you just added have one. All of it applies: the crop, the orientation, the settings, which faces you chose, and the areas you painted as protected.

Each image carries its own edit. There is deliberately no way to apply one set of protected areas to a whole folder, because protection is stored for each pixel of one particular photograph: painting over a mole on one face and then laying those same pixels over forty other pictures would protect whatever happened to be in that spot, which is worse than doing nothing.

Apply current settings to all and the per-image equivalent change the strengths and the size. They leave each item's saved edit alone.

Two things a queue cannot do that you can do at the window:

• If the photograph is not the one the edit was made on, the image is left alone rather than enhanced. At the window Litesum can ask you whether to use it anyway; nobody is watching a queue, so it does not guess. The report says which images were skipped and why. This is on purpose: a file enhanced without its protected areas looks finished, and you would have no way to see that the thing you painted over had been rebuilt after all.
• An edit saved before Litesum recorded a fingerprint of the photograph is applied, and the item finishes with a warning saying so. The size and date still matched, but nothing can confirm it is the same picture. Saving that edit again at the window records a fingerprint and the warning stops.

Applying settings to everything

Apply current settings to all copies the image type, enlargement and all three strengths onto every queued item — and turns automatic settings off for them, because otherwise the queue would measure each image and discard what you just applied. The status line says exactly what was applied.

Leave it alone if you want per-image measurement instead. That is usually the better choice for a folder of holiday photographs, which is rarely uniform: some are clean, some are compressed phone shots, and one set of strengths applied to all of them over-processes half.

Where the results go

Save enhanced images to — choose the folder. Originals are never modified and never written to.

Output format — one format for the whole batch:

• PNG (the default) and TIFF are lossless.
• WebP and JPEG are smaller. JPEG is lossy.
• Keep each image's own format is available, and the interface warns you what it means: any JPEG in the queue comes back as a JPEG, re-encoded, which discards some of the detail the model just reconstructed.

The default is PNG deliberately. Silently re-encoding a photographer's JPEGs after twenty seconds of AI reconstruction is the sort of thing that is only discovered by comparing file sizes a month later.

Keep source folder structure recreates the folders your images came from under the destination, rather than putting a hundred images from twelve folders into one.

File names get a suffix — holiday_enhanced_4x.png — and collisions are avoided rather than overwritten.

While it runs

One image at a time. That is deliberate: the graphics card is the limit, so two at once mostly compete for the same hardware while doubling the memory needed.

• Pause finishes the current image and then holds. It never abandons one half-processed.
• Skip abandons the current image and moves to the next.
• Stop ends the run. Anything not yet reached is marked cancelled, and you still get a report of what did get done.

A failure never stops the queue. A corrupt file, an unsupported format, an image too large for the memory available — each is recorded against that item and the run continues. Coming back to find it stopped on the second of fifty images would defeat the purpose.

Every item shows its state in words: waiting, processing, completed, failed, cancelled, with the reason.

Memory

Before each image, Litesum Enhance estimates what the job needs against the memory actually free. Anything that would not fit is skipped with a reason rather than started and allowed to exhaust the machine half-way through a night's work.

Every finished image is read back

When an image has been written, Litesum Enhance opens it again and checks it is the picture that was asked for — the right size, the right format, and decodable from beginning to end. An image that fails is marked as failed with the reason, and the file is left where it is rather than deleted: it is yours, and it is also the evidence of what went wrong.

This is not fussiness. A queue left running overnight can fill the disk, lose a network drive, or meet an encoder that gives up part way, and all three leave a file behind. Coming back to a folder of fifty names, there is nothing to tell a finished image from one whose pixels ran out half way down — and the header of a half-written file still says the right size, so a quick look would not catch it either. Reading the whole file is what catches it.

What this does not do is compare the file's pixels with what was on screen. Writing a file legitimately changes them a little where a colour profile is involved, so a check demanding they match exactly would fail on every correct image. The promise is narrower and true: the file opens, and it is the picture you asked for at the size you asked for.

The report

A text file is written beside the results listing, for every image:

• the source and output file names
• the dimensions in and out, and the scale
• the image type used, and whether it was chosen automatically
• the three strengths that actually ran
• what a saved edit did: the crop, and how many pixels were protected
• the size of the file after it was read back and checked
• the format written and how long it took
• any warning or failure, in plain language

It also records how much the AI actually contributed to each image, the same figure the window shows. Across fifty images that line is what tells you one of them came back as little more than a resize.

On an image with protected areas, that figure describes the enhancement, not the file on disk — the protection is put back afterwards, and the protected part of the file had no AI contribution at all. The report says so on the line underneath rather than leaving you to work it out.

It records what was done, not what was asked for — the two differ whenever automatic settings are on. It contains file names and settings only; no image content, ever.