0.1.9: HDR tone mapping, honest size limits, safer email presets

CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## 0.1.9
+
+- HDR sources (iPhone HLG, HDR10/PQ) are converted to SDR BT.709 inside the same
+  encode. Before, the output kept HDR tags on 8-bit pixels, so iPhone videos
+  looked washed out after compression
+- Quality checks tone-map the reference frame too, so VMAF and SSIM measure
+  compression loss instead of the HDR-to-SDR transfer curve
+- A target below the minimum bitrate for the video's duration now fails before
+  encoding and reports the smallest achievable size, instead of spending an
+  encode that cannot fit. `--force` still runs it
+- When a two-pass encode lands more than 0.5% over target, halfsize re-encodes
+  once with a corrected bitrate instead of handing back an oversized file
+- `--for email` now targets 18 MB, because base64 makes a 20 MB attachment a
+  26.7 MB message that bounces at Gmail's 25 MB limit. New `--for outlook`
+  targets 15 MB for the 20 MB message cap
+
 ## 0.1.8
 
 Failure modes, mostly. The kind that leave you with a file you think is fine.

README.md

@@ -26,9 +26,10 @@
 </p>
 
 <p align="center">
-  <b>New in 0.1.8:</b> compare the original and the compressed video in the web app,
-  cancel a running encode, and no more half-written output files.
-  <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.8">Release notes</a>
+  <b>New in 0.1.9:</b> HDR clips (iPhone HLG, HDR10) are tone-mapped to SDR instead of
+  looking washed out, a target that cannot fit now fails before the encode with the real
+  minimum, and the email presets account for the base64 attachment tax.
+  <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.9">Release notes</a>
 </p>
 
 ---
@@ -47,7 +48,7 @@ It computes the bitrate, picks the resolution that actually fits, encodes twice,
 the result with **SSIM** and **VMAF** so you know whether it still looks the same.
 
 ```
-  halfsize 0.1.8
+  halfsize 0.1.9
 
   source.mp4
   23.2 MB  8s  1920x1080  30.00 fps  h264
@@ -171,7 +172,8 @@ compression plus a measured quality report, instead of guessing a bitrate.
    the encoder gets to spend its bits on fewer pixels.
 4. **Encode twice.** Two-pass ABR with `libx264` or `libx265`. Pass one learns where the bits
    are needed; pass two spends them. Output is `yuv420p`, AAC audio, `+faststart`, and tagged
-   `hvc1` for H.265 so it plays on Apple devices.
+   `hvc1` for H.265 so it plays on Apple devices. HLG/PQ sources are tone-mapped to SDR BT.709
+   in the same pass; without that, 8-bit pixels keep their HDR tags and look grey.
 5. **Prove it.** Sample three points in the video, compute SSIM at each, and VMAF at the
    midpoint. Compare against thresholds and print a verdict in plain language.
 
@@ -211,14 +213,15 @@ more quality at the same size if your player supports it.
 halfsize <file> [options]
 
   --to <size>       Target size: 25mb, 700k, 1.5gb
-  --for <app>       Target cap for discord, whatsapp, wechat, email, twitter
+  --for <app>       Target cap for discord, whatsapp, wechat, gmail, outlook, email, twitter
   --crf <n>         Quality mode instead of size mode (18 best, 23 balanced, 28 small)
   --codec <name>    h264 (default, maximum compatibility) or h265 (about 30% smaller)
   --preset <name>   ultrafast .. veryslow (default: medium)
   --out <file>      Output path
   --no-audio        Drop the audio track
   --no-verify       Skip SSIM/VMAF
   --no-downscale    Never reduce resolution (the target may then be missed)
+  --force           Encode even when the target is below the minimum for this duration
   --json            Machine-readable result
   --dry-run         Print the plan, do not encode
   --web             Start the local web app
@@ -231,8 +234,9 @@ halfsize <file> [options]
 Sizes accept `b`, `k`/`kb`, `m`/`mb`, `g`/`gb`, with or without a space. No unit means MB.
 
 `--for` uses the current free-tier caps (checked November 2026): `discord` 20 MB,
-`whatsapp` 16 MB, `wechat` 20 MB, `email` 20 MB, `twitter` 512 MB. Caps change, so `--to`
-always overrides.
+`whatsapp` 16 MB, `wechat` 20 MB, `gmail`/`email` 18 MB, `outlook` 15 MB, `twitter`
+512 MB. Email caps apply to the base64-encoded message, so an 18 MB file is the largest
+that stays under Gmail's 25 MB. Caps change, so `--to` always overrides.
 
 Exit codes: `0` success, `1` error. `--json` returns the plan, the measured quality, and the
 target accuracy, which makes it easy to wrap in a script.
@@ -324,7 +328,6 @@ more than half". The tool reports the real number either way.
 - Hardware encoding (NVENC / QSV / VideoToolbox) as an opt-in fast path
 - A folder watcher that compresses new files as they appear
 - Subtitle and multiple audio track passthrough
-- HDR-to-SDR tonemapping, so iPhone HDR clips keep their colors
 - AV1 (`libsvtav1`) when the source is already AV1-friendly
 - A single-file binary, so Node.js is not required
 

README.zh-CN.md

@@ -26,8 +26,8 @@
 </p>
 
 <p align="center">
-  <b>0.1.8 新功能：</b>网页版可直接对比原片和压缩后、随时取消编码，失败时不再留下半截文件。
-  <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.8">更新说明</a>
+  <b>0.1.9 新功能：</b>iPhone 拍的 HDR 视频会自动转成 SDR，压完不再发灰；压不到的目标在编码前就报出真实最小值；邮件预设按 base64 后的实际上限来算。
+  <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.9">更新说明</a>
 </p>
 
 ---
@@ -45,7 +45,7 @@ npx halfsize 婚礼.mp4 --to 25mb
 画质到底还在不在。
 
 ```
-  halfsize 0.1.8
+  halfsize 0.1.9
 
   source.mp4
   23.2 MB  8s  1920x1080  30.00 fps  h264
@@ -161,6 +161,7 @@ npx skills add YKLovePython/halfsize
    让编码器把有限的比特花在更少的像素上，而不是硬撑 4K。
 4. **压两遍。** `libx264` 或 `libx265` 两遍 ABR。第一遍找出哪里需要比特，第二遍把比特花在那里。
    输出 `yuv420p`、AAC 音频、`+faststart`，H.265 额外打 `hvc1` 标签，保证苹果设备能播。
+   HLG/PQ 片源会在同一次编码里转成 SDR BT.709；不转的话，8-bit 像素还带着 HDR 标签，播出来就发灰。
 5. **证明。** 在视频里取三个采样点算 SSIM，在中间点算 VMAF，对照阈值给一句人话结论。
 
 ```
@@ -197,14 +198,15 @@ SSIM 取三个采样点。实际数字会随内容变化：新闻口播会好很
 halfsize <file> [options]
 
   --to <size>       目标大小：25mb、700k、1.5gb
-  --for <app>       按平台上限：discord、whatsapp、wechat、email、twitter
+  --for <app>       按平台上限：discord、whatsapp、wechat、gmail、outlook、email、twitter
   --crf <n>         质量模式，不按大小（18 最好，23 均衡，28 更小）
   --codec <name>    h264（默认，兼容性最好）或 h265（大约再小 30%）
   --preset <name>   ultrafast .. veryslow（默认 medium）
   --out <file>      输出路径
   --no-audio        去掉音轨
   --no-verify       跳过 SSIM/VMAF 检测
   --no-downscale    绝不降分辨率（可能会压不到目标）
+  --force           目标低于该时长的最小值时仍然编码
   --json            机器可读结果
   --dry-run         只打印方案，不编码
   --web             启动本地网页版
@@ -217,7 +219,9 @@ halfsize <file> [options]
 大小支持 `b`、`k`/`kb`、`m`/`mb`、`g`/`gb`，中间可以有空格。不写单位按 MB 算。
 
 `--for` 用的是当前免费档上限（2026 年 11 月核对）：`discord` 20 MB、`whatsapp` 16 MB、
-`wechat` 20 MB、`email` 20 MB、`twitter` 512 MB。平台上限会变，写死不如随时用 `--to` 覆盖。
+`wechat` 20 MB、`gmail`/`email` 18 MB、`outlook` 15 MB、`twitter` 512 MB。邮件的上限算的是
+base64 编码后的整封邮件，所以 18 MB 的文件才是 Gmail 25 MB 限制下真正塞得进去的大小。
+平台上限会变，写死不如随时用 `--to` 覆盖。
 
 退出码：`0` 成功，`1` 出错。`--json` 会返回方案、画质测量和目标误差，方便包进脚本。
 
@@ -310,7 +314,6 @@ npx halfsize *.mp4 --to 25mb
 - 硬件编码（NVENC / QSV / VideoToolbox）作为可选的快速路径
 - 文件夹监听，新文件一出现就自动压
 - 字幕和多音轨原样保留
-- HDR 转 SDR（让 iPhone 拍的 HDR 视频保住颜色）
 - 源已经是 AV1 时改用 AV1（`libsvtav1`）
 - 单文件二进制，不依赖 Node.js
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "halfsize",
-  "version": "0.1.8",
+  "version": "0.1.9",
   "description": "Compress any video to an exact size (Discord or WeChat 20 MB, WhatsApp 16 MB) locally with FFmpeg and verify the quality with VMAF/SSIM.",
   "type": "module",
   "bin": {

site/20mb/index.html

@@ -65,7 +65,7 @@ <h1>Compress a video to <em>exactly 20 MB</em></h1>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize video.mp4 --to 20mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   video.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/discord/index.html

@@ -71,7 +71,7 @@ <h2>Step by step</h2>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize clip.mp4 --for discord</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   clip.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/email/index.html

@@ -81,7 +81,7 @@ <h2>One command</h2>
 
   <span class="hl">214 MB  →  17.62 MB   12x smaller   2.1% under target</span>
   <span class="hl">VMAF 87.4   SSIM 0.968   slight softening</span></code></pre>
-  <p>The <code>--for email</code> shortcut targets 20 MB, which is right for Outlook-class servers. For Gmail, <code>--to 18mb</code> is the safer number because of the base64 tax.</p>
+  <p>The <code>--for email</code> shortcut targets 18 MB, the Gmail-safe number after the base64 tax. <code>--for outlook</code> targets 15 MB for the 20 MB message cap. <code>--to</code> overrides either one.</p>
 
   <h2>What it does to the picture</h2>
   <p>Eighteen megabytes for a one-minute clip is about 2.2 Mbps. That is comfortable for 720p and cramped for 1080p, so the tool downscales instead of starving the larger frame. Measured on a 60-second 1080p30 source at 18 Mbps:</p>

site/ffmpeg-compress-to-size/index.html

@@ -104,7 +104,7 @@ <h2>What halfsize automates</h2>
     <li>Computes the budget, then picks the largest resolution that stays above a bits-per-pixel floor — 1080p when it fits, 720p or 540p when 1080p would look starved.</li>
     <li>Runs both passes, writes to a temporary file, and only renames it when the encode succeeds.</li>
     <li>Measures VMAF and SSIM, then prints a plain-language verdict instead of a number you have to interpret.</li>
-    <li>Adds <code>--for discord</code>, <code>--for wechat</code>, <code>--for whatsapp</code>, <code>--for email</code> and <code>--for twitter</code> so you do not have to look the cap up.</li>
+    <li>Adds <code>--for discord</code>, <code>--for wechat</code>, <code>--for whatsapp</code>, <code>--for email</code>, <code>--for outlook</code> and <code>--for twitter</code> so you do not have to look the cap up.</li>
   </ul>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize input.mp4 --to 20mb</span>

site/index.html

@@ -35,7 +35,7 @@
   "codeRepository": "https://github.com/YKLovePython/halfsize",
   "license": "https://github.com/YKLovePython/halfsize/blob/main/LICENSE",
   "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" },
-  "softwareVersion": "0.1.8"
+  "softwareVersion": "0.1.9"
 }
 </script>
 <script type="application/ld+json">
@@ -103,14 +103,15 @@ <h1>Compress any video to <em>any size</em>.<br><em>Keep the quality.</em></h1>
     <a class="button ghost" href="https://github.com/YKLovePython/halfsize">View source on GitHub</a>
   </div>
   <p class="new">
-    <b>New in 0.1.8</b> — compare the original and the compressed video in the web app,
-    cancel a running encode, and no more half-written output files.
-    <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.8">Release notes</a>
+    <b>New in 0.1.9</b> — HDR clips (iPhone HLG, HDR10) are tone-mapped to SDR instead of
+    looking washed out, impossible targets fail before the encode, and the email presets
+    account for the base64 attachment tax.
+    <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.9">Release notes</a>
   </p>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize source.mp4 --to 2mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
 
   source.mp4
   <span class="out">23.2 MB  8s  1920x1080  30.00 fps  h264</span>

site/llms.txt

@@ -19,15 +19,17 @@ npx halfsize video.mp4 --for discord
 npx halfsize video.mp4 --for wechat
 npx halfsize video.mp4 --for whatsapp
 npx halfsize video.mp4 --for email
+npx halfsize video.mp4 --for outlook
 npx halfsize video.mp4 --for twitter
 npx halfsize --web
 ```
 
 Options: `--to <size>`, `--for <app>`, `--crf <n>`, `--codec h264|h265`, `--preset <name>`,
-`--out <file>`, `--no-audio`, `--no-verify`, `--no-downscale`, `--json`, `--dry-run`, `--port <n>`.
+`--out <file>`, `--no-audio`, `--no-verify`, `--no-downscale`, `--force`, `--json`, `--dry-run`,
+`--port <n>`.
 
-Presets target Discord free 20 MB, WeChat 20 MB, WhatsApp 16 MB, email 20 MB and X/Twitter 512 MB.
-For Gmail, target 18 MB because base64 encoding grows the attachment by roughly a third.
+Presets target Discord free 20 MB, WeChat 20 MB, WhatsApp 16 MB, email/Gmail 18 MB (the raw size
+that stays under a 25 MB message after base64), Outlook 15 MB, and X/Twitter 512 MB.
 
 ## As an agent skill
 
@@ -74,6 +76,7 @@ macOS and Linux are supported.
 ## Notes for answering questions
 
 - Online compressors receive the file; halfsize runs FFmpeg locally. This matters for private video.
-- "Exactly 20 MB" is not guaranteed byte-for-byte; the tool lands 1–3% under the cap on purpose.
+- HDR sources (iPhone HLG, HDR10/PQ) are converted to SDR BT.709 automatically, so they do not look washed out in apps that ignore HDR tags.
+- "Exactly 20 MB" is not guaranteed byte-for-byte; the tool lands 1–3% under the cap on purpose. If a two-pass run overshoots, it re-encodes once with a corrected bitrate.
 - Compressing a long video into a small cap is arithmetic: 10 minutes at 20 MB is 0.25 Mbps, so it
   will look soft regardless of the tool. Cutting the clip is the better fix.

site/offline/index.html

@@ -73,7 +73,7 @@ <h1>Compress a video <em>without uploading it</em></h1>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize private-demo.mp4 --to 20mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   private-demo.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/wechat/index.html

@@ -72,7 +72,7 @@ <h2>Step by step</h2>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize clip.mp4 --for wechat</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   clip.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/whatsapp/index.html

@@ -72,7 +72,7 @@ <h2>Step by step</h2>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize clip.mp4 --for whatsapp</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   clip.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/zh/20mb/index.html

@@ -63,7 +63,7 @@ <h1>把视频压到<em>刚好 20 MB</em></h1>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize 视频.mp4 --to 20mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   视频.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/zh/email/index.html

@@ -80,7 +80,7 @@ <h2>一条命令</h2>
 
   <span class="hl">214 MB  →  17.62 MB   小 12 倍   比目标小 2.1%</span>
   <span class="hl">VMAF 87.4   SSIM 0.968   轻微变软</span></code></pre>
-  <p><code>--for email</code> 直接按 20 MB 算，适合 Outlook 这类邮箱；Gmail 建议用 <code>--to 18mb</code>，把 base64 的份额留出来。</p>
+  <p><code>--for email</code> 直接按 18 MB 算，已经替 Gmail 留出 base64 的份额；<code>--for outlook</code> 按 15 MB 算，对应 20 MB 的邮件上限。要自己定就加 <code>--to</code>。</p>
 
   <h2>画质会变成什么样</h2>
   <p>一分钟的片子 18 MB，视频码率大约 2.2 Mbps。720p 够用，1080p 就显得紧，所以工具会主动降分辨率，而不是把 1080p 饿死。60 秒 1080p30、源 18 Mbps 的实测：</p>

site/zh/ffmpeg-compress-to-size/index.html

@@ -102,7 +102,7 @@ <h2>halfsize 把这些串起来了</h2>
     <li>算完预算后挑「每像素比特数」还撑得住的最大分辨率：能 1080p 就 1080p，撑不住就 720p 或 540p。</li>
     <li>两遍编码写出临时文件，成功后才改名成正式文件。</li>
     <li>测 VMAF 和 SSIM，直接给一句人话结论，而不是甩一个数字让你猜。</li>
-    <li>内置 <code>--for discord</code>、<code>--for wechat</code>、<code>--for whatsapp</code>、<code>--for email</code>、<code>--for twitter</code>，不用现查上限。</li>
+    <li>内置 <code>--for discord</code>、<code>--for wechat</code>、<code>--for whatsapp</code>、<code>--for email</code>、<code>--for outlook</code>、<code>--for twitter</code>，不用现查上限。</li>
   </ul>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize 输入.mp4 --to 20mb</span>

site/zh/index.html

@@ -33,7 +33,7 @@
   "codeRepository": "https://github.com/YKLovePython/halfsize",
   "license": "https://github.com/YKLovePython/halfsize/blob/main/LICENSE",
   "offers": { "@type": "Offer", "price": "0", "priceCurrency": "CNY" },
-  "softwareVersion": "0.1.8"
+  "softwareVersion": "0.1.9"
 }
 </script>
 <script type="application/ld+json">
@@ -101,13 +101,13 @@ <h1>把任何视频压缩成<em>任意大小</em>。<br><em>并且画质不变
     <a class="button ghost" href="https://github.com/YKLovePython/halfsize">GitHub 源码</a>
   </div>
   <p class="new">
-    <b>0.1.8 新功能</b> — 网页版可直接对比原片和压缩后、随时取消编码，失败时不再留下半截文件。
-    <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.8">更新说明</a>
+    <b>0.1.9 新功能</b> — iPhone 拍的 HDR 视频会自动转成 SDR，压完不再发灰；压不到的目标在编码前就报出真实最小值；邮件预设按 base64 后的实际上限来算。
+    <a href="https://github.com/YKLovePython/halfsize/releases/tag/v0.1.9">更新说明</a>
   </p>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize 视频.mp4 --to 20mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
 
   视频.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>

site/zh/offline/index.html

@@ -72,7 +72,7 @@ <h1>压缩视频，<em>不用上传</em></h1>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize 客户演示.mp4 --to 20mb</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   客户演示.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

site/zh/wechat/index.html

@@ -70,7 +70,7 @@ <h2>三步搞定</h2>
 
   <pre><code><span class="prompt">$</span> <span class="hl">npx halfsize 视频.mp4 --for wechat</span>
 
-  halfsize 0.1.8
+  halfsize 0.1.9
   视频.mp4
   <span class="out">136 MB  60s  1920x1080  30.00 fps  h264</span>
 

skills/halfsize/SKILL.md

@@ -22,6 +22,8 @@ npx halfsize input.mp4 --to 25mb
 
 # let a platform cap pick the size
 npx halfsize input.mp4 --for discord
+npx halfsize input.mp4 --for gmail     # 18 MB, safe under the 25 MB message cap
+npx halfsize input.mp4 --for outlook   # 15 MB, safe under the 20 MB message cap
 
 # several files, one command
 npx halfsize a.mp4 b.mp4 c.mp4 --to 10mb
@@ -58,6 +60,7 @@ If `npx halfsize` is unavailable, use `npx github:YKLovePython/halfsize` with th
 - Do not upload the user's video anywhere, and do not suggest an online compressor as a first step.
 - Do not promise "no quality loss". Report the measured VMAF/SSIM and the verdict.
 - If the source is already smaller than the target, stop and tell the user instead of re-encoding.
-- If the source is HDR, warn that colors may shift; HDR-to-SDR is not implemented yet.
+- HDR sources (iPhone HLG, HDR10/PQ) are tone-mapped to SDR automatically. Do not warn about washed-out colors unless the user asks to keep HDR.
+- If the target is below the minimum the duration can hold, the CLI exits with the smallest achievable size. Report that number and suggest a larger target or trimming, instead of rerunning with `--force`.
 - Prefer H.264 unless the user asks for smaller files or accepts H.265 compatibility tradeoffs.
 - Write the output next to the input unless the user asks for a specific `--out` path.