From 17f2fd893afb78c30f22aa119fb3ab1aaf18b573 Mon Sep 17 00:00:00 2001 From: Nymiro Date: Mon, 20 Oct 2025 20:25:02 +1300 Subject: [PATCH] heic-2 --- .DS_Store | Bin 10244 -> 10244 bytes 改进方向.txt | 72 --------------------------------------------------- 2 files changed, 72 deletions(-) delete mode 100644 改进方向.txt diff --git a/.DS_Store b/.DS_Store index 0dc6ccb33af59540b85b8594752b91c2ce9648d4..6928477444bf723231804e9cbfc6bfdc95604052 100644 GIT binary patch delta 41 tcmZn(XbIThBf!G6)Lm#Q_|84D`。 - * 这意味着主 ID `49` 的**实际数据只有 8 字节**。真正的图像数据存储在*其他* Item ID 中（如 1, 3, 4...），然后通过 `iref` 盒的 `dimg` 网格蓝图拼凑起来。 - ---- - -### 复盘：我们为什么一直失败 - -我们所有的修复（V8, V9, V10）都在做同一件事，而这件事是注定要失败的： - -1. 我们拿了**三星的“网格”文件** (它依赖 `iref['dimg']` 来组合图像)。 -2. 我们强行给它贴上了**苹果的 `ftyp` 标签** (例如 `...MiHBMiHE...`)。这个标签告诉解码器：“这是一个**扁平**文件，请勿查找 `iref['dimg']`”。 -3. 我们正确地重建了所有偏移量，并注入了 `ContentIdentifier`。 - -**失败的精确时刻：** - -1. Apple 的 "预览" App 打开我们的 `samsung_apple_compatible.HEIC`。 -2. 它读取了 `ftyp` (苹果标签)：“好的，这是一个扁平文件。” -3. 它读取了 `pitm`：“好的，主图像是 ID `49`。” -4. 它读取了 `ipma`：“好的，ID `49` 的尺寸是 4000x3000。” -5. 它去 `iloc` 查找 ID `49` 的**图像数据**。 -6. `iloc` 返回：“这是它的数据：**8 个字节**。” -7. "预览" App 崩溃，因为它无法从 8 字节的数据中渲染出一个 4000x3000 的图像。 - ---- - -### 结论：我们面临的僵局 - -我们无法通过*修改*（modify）来解决这个问题。**我们必须*转码*（transcode）。** - -我们试图进行的“结构手术”是不可能的，因为这两种文件格式在如何定义“主图像”上存在根本性的、不兼容的差异。 - -**我们有两个选择，但都不能完全满足最初的需求：** - -1. **选项 A：成功创建可查看的 HEIC（但丢失动态照片链接）** - * 我们可以使用 `heic_file.py` 中的 `reconstruct_primary_image()` 方法（它在内部使用 `pillow_heif`）。 - * 这个方法很聪明，它*可以*读取三星的 `iref['dimg']` 网格并将其在内存中拼凑成一张完整的 4000x3000 图像。 - * 然后我们可以将这张 `PIL.Image` 对象保存为一个**新的、扁平的** `output.heic` 文件。 - * **结果：** 我们会得到一个完美的 HEIC 静态图像，但它将丢失我们辛苦注入的 `ContentIdentifier` (UUID)，因为 `PIL.Image.save()` 只是一个像素编码器，它不会重建我们需要的复杂 `meta` 盒。 - -2. **选项 B：保持我们的代码（但它永远无法工作）** - * 我们当前的 `builder.py` 方案是*唯一*能够注入 `ContentIdentifier` 的方法，但它操作的*源文件*（三星网格）与我们的*目标*（苹果扁平）不兼容。 - -**简而言之：** 我们的 `builder.py` 擅长元数据（Metadata）操作，而 `pillow_heif` 擅长像素（Pixel）操作。要完成这个任务，我们**同时**需要两者，但现有的库不允许我们将 `ContentIdentifier` 注入到一个正在被转码（从网格转为扁平）的文件中。 - -我建议我们暂停对 `builder.py` 的修改，因为我们当前的偏移量计算（如 V10 日志所示）已经是**正确**的。失败的原因超出了我们的修复范围，它是一个文件*结构*的根本性不兼容。 - -实际上我的需求是：将三星的动态照片（motion photo）转换为两份文件，一份是视频一份是照片，将它们与iOS一样通过ContentIdentifier链接，使其变为可以被iOS设备读取并链接的Live Photo，我无所谓转换为静态照片的部分是否存在视频，但是我希望其可以注入ContentIdentifier，将三星的文件结构转换为iOS的文件结构 \ No newline at end of file