[Ugoyo]

What does this change?

Closes #1353. The four "Compress" tools can ask for the level each time. Dropping files on one opens a small "Choose the compression" window, built like "Choose pages" (#981). It shows the preset editor's own setting for each kind of file dropped (picture quality slider, video quality, audio bitrate, PDF level) and the size the files will roughly come to: "About 30.0 MB (70% smaller)". The window says it is an estimate. Enter compresses at that setting, which the preset keeps for next time. Esc starts nothing.

• Preset.AskCompression is off by default, so there is no settings migration (same approach as AskPageRange). It is on for compress-image, compress-video, compress-audio and compress-pdf in a new install only. Existing users turn it on in the preset editor: "Ask every time" sits under the setting it asks for, with a hint, and is not offered for merges. Watch folders and the CLI use the preset's own values.
• Files with nothing to choose (a PNG on "Compress image", a document) convert without the window. Merges keep the preset's values.
• It reuses what exists: the editor's controls and strings, MediaQuality, PdfCompression, AudioBitrateKbps. The image MaxSizeMb and video MaxSizeMb / MaxSizePercent limits cap the estimate, as they cap the result. No new compression settings.

How the size is estimated (Filee.Engines/CompressionEstimator.cs):

Kind	Estimate	How close
Audio	encoder bitrate × length (ffprobe)	within a few % in the tests
Video	the bitrate Filee already uses to give a GPU encoder the same quality as x264's CRF (HardwareVideo.BitrateKbps) + audio, × length. A video that would be copied keeps its size.	rough: depends on the picture, and the window says so
Picture	a full-resolution tile (≤ 640×640) from the middle is really encoded at the chosen quality, then scaled to the whole picture's pixels. Encoding all of it on every slider step is too slow, and a downscaled copy overestimates.	within 25 % of the real output in the tests
PDF	the built-in PdfCompressor really runs into a byte-counting stream, once per level	≈ exact for the PDFsharp route (Ghostscript can only make it smaller)

"Only keep if smaller" and the size limits cap the estimate. Only the first files of each kind are read (12 pictures, 4 PDFs, 40 media files); the rest count at the same ratio.

Type of change

• Bug fix
• New feature or improvement
• New format or engine
• Translation
• Documentation
• Build, CI or dependencies

How was it tested?

• dotnet format Filee.slnx --verify-no-changes --severity warn, and dotnet build Filee.slnx -c Release (0 errors)
• dotnet test, in a Linux container:
  • New: AskedCompressionTests (Core), CompressionEstimatorTests (Engines), AskCompressionTests (App). They hold the estimate against real conversions: picture, PDF, audio and video. The audio and video tests ran with the distro's FFmpeg. The App test drives the real donut → window → Enter/Esc → compressed file.
  • Core: all pass except FolderCopyTests.Original_that_cannot_be_deleted…, which also fails on main here (the container runs as root).
  • App: 2280 passed, 8 failed out of 2335. Seven of the failures also fail on main in this container (glyph tests for CJK, emoji and Bengali, the Engines page). The eighth, RenderTests.Reset_to_default_sits_beside_delete… (ar), passes when run on its own: it is flaky in the full run, like AskPagesTests (ja, dark) on main.
  • Engines: the new tests pass. The full Engines suite was not run again: on main it already has 18 failures here, because Pandoc and LibreOffice are missing.
• Tried it in the app: not done. Only headless rendering was checked, no real desktop session and no Windows or macOS.

Screenshots (UI changes)

The window, from the headless render tests. The sizes come from a fixed fake estimate (100 MB → 30 MB) used only for the render; the full Windows path is how the test feeds a file name on Linux.

Picture (light)	Video (dark, French)	PDF (French)

"Ask every time" in the preset editor, under the setting it asks for:

Compress image	Compress video (dark, French)

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md (none added)
• The PR does one thing (unrelated changes go in a separate PR)

[KnifeLemon]

Thank you, this is a careful take on #1353. It reuses the editor's own settings, follows "Choose pages" closely, and the estimate is checked against real conversions. The screenshots helped a lot.

One thing to fix before we merge:

1. Files that can't be estimated drop out of the total. In CompressionEstimator.Estimate, a sampled file whose EstimateOne returns null is skipped. It isn't added to sourceKnown, and it isn't scaled at the ratio like the unsampled files, so its bytes disappear from the total. The window's "size now" still counts them, so the estimate reads too small and "% smaller" too large.
   The common case is HEIC. LossyImageTargets includes heic, but ImageMagick can't encode HEIC here (Filee writes it through FFmpeg), so ImageBytes throws on ToByteArray(MagickFormat.Heic) and returns null. A JPG + HEIC drop from a phone leaves the HEIC out of the estimate, and HEIC alone shows "can't estimate". A video file without a video stream on "Compress video" behaves the same way.
   Could you count such files at their kind's ratio, as the unsampled ones are? For HEIC, either estimate it another way or leave it out of KindOf until it can be estimated. A test with one file that can't be estimated next to one that can would pin it down.

2. Keep the choice to this run. Right now a level picked in the window is saved into the preset, and watch folders and the command line use that preset too, so a one-off choice on the donut quietly changes them. Please apply it to this conversion only, the way Choose pages does. If you'd like a way to keep it, a Remember for this preset checkbox (off by default) is fine.

We'll start CI: first-time PRs need a maintainer to approve the workflow run.

[Ugoyo]

Thanks for the review! Both points are addressed:

• Files that can’t be estimated now count at their kind’s ratio instead of dropping out of the total (new test: a damaged JPG next to a good one). HEIC is left out of KindOf until it can be estimated; such files (and PNGs) convert in their own run with the preset as it is, so a level chosen for the JPGs never reaches them.
• The choice now applies to this conversion only. A “Remember for this preset” checkbox (off by default) keeps it.

[KnifeLemon]

Thanks for the quick turnaround, both points are done well: the files that can't be estimated now count at their kind's ratio, and the choice stays with this conversion unless "Remember for this preset" is ticked.

Two small things came with splitting the drop into two runs:

1. "Ask every time" asks twice. When the preset asks where to save, a mixed drop (say JPGs and a PNG on "Compress image") now calls AskThenConvertAsync once per run, so the save dialog opens twice for one drop and the two parts can end up in different folders. Could you ask for the location once and use it for both runs (or keep them in one job with the setting per file)? Without "Ask every time", two jobs are fine.
2. The checkbox still shows for HEIC. ShowAskCompressionImage uses the editor's LossyTargets, which still has heic, but AskedCompression.KindOf no longer does. So a custom "→ HEIC" preset offers "Ask every time" for the compression, saves it, and then never opens the window. Could you show the checkbox only for "same as source" and the targets in AskedCompression.LossyImageTargets? The quality slider can stay for HEIC.

Main has moved on since: #1370 and #1389 touched Preset.cs and PresetEditorViewModel.cs, so the branch conflicts now. You don't need to resolve that. We'll merge main when we merge. If you'd rather do it with these fixes, that's fine too.

[Ugoyo]

Thanks! Both are fixed:

1. With “Ask every time”, the save location is now asked once for the whole drop and used for every run (AskedCompression.Runs takes it), so a mixed drop gets one dialog and one folder.
2. The “Ask every time” checkbox now shows only for “same as source” and AskedCompression.LossyImageTargets; a HEIC target keeps its quality slider without it.

I also merged main (#1370, #1389) to clear the conflicts.

[KnifeLemon]

Thanks, @Ugoyo! Both points from the last round are in:

• a mixed drop now asks for the save location once, and every run uses it
• "Ask every time" only shows for targets the window can estimate, so HEIC keeps its slider without it

We pushed one small commit on top that changes the new Korean strings to the polite 해요체 used across the app. Nothing else changed.