没人注意到 GPT Images 2.0 的“编辑”功能其实是全图重新生成吗？

本报告仅整理用户在 ChatGPT 应用中观察到的关于所谓“图像编辑”流程的事实。结论十分明确：该流程并未对用户上传的原图进行局部编辑。实际调用的流程是 `image_gen.text2im`。在返回结果中显示的是 DALL-E 生成元数据；即使出现 `edit_op: "inpainting"`，输出也并非局部编辑，而是全帧重新生成。此外，在更早的阶段，原始图像文件本身并未以原样传输、保留或引用。因此，在此对话中观察到的“图像编辑”并非对原始图像的编辑。它是以经过压缩和转换的衍生图像作为参考输入，进行文本到图像（Text-to-Image）的全帧重新生成。用户上传的原始图像文件并未按原样处理。在上传阶段，ChatGPT 处理的是与原始图像不同的、经过压缩和转换的衍生图像。图像处理期间调用的工具是 `image_gen.text2im`。每一个返回结果都显示 DALL-E 生成元数据。即使显示 `edit_op: "inpainting"`，实际输出也不是局部编辑，而是全帧重新生成。即使明确指定了修正区域，流程也基于蒙版的前提进行，并显示为修补（inpainting），但整个图像——包括指定区域之外的区域——在像素级别上均发生了变化。输出图像的哈希值也与原始图像完全不同。因此，这不是“图像编辑”。也不是基于原始图像的编辑。它是使用压缩和转换后的衍生图像作为输入的 `image_gen.text2im` / T2I 全帧重新生成。原始图像文件本身并未按原样传输。用户使用的一项图像上传功能被描述为允许上传高达 20 MB 的文件。然而，实际网络监控显示，即使选择并上传了大尺寸图像，传输的数据量也仅为约 300 KB。这一点具有决定性意义。如果 20 MB 级别甚至几 MB 的原始图像文件是按原样发送到服务器的，则应产生相应数量的网络流量。由于仅传输了约 300 KB 的数据，原始图像文件本身并未按原样发送。此时，“原始图像按原样上传，随后对该原始图像进行编辑”的前提便不攻自破。用户端的原始图像与 ChatGPT 端处理的图像是不同的对象。用户端的原始图像信息如下： 文件名：1000045047_x4_drawing.png 格式：PNG 分辨率：2048 × 2048 大小：5.58 MB SHA-1：69ba09b9718bc43947e0f6510bab65319e3e0a42 SHA-256：2d6a15d7deb517c5e8885512ec73d79bd2535d5d5311a8e76a793fed391ec114 相比之下，在此对话中助理可访问的图像信息如下： 格式：JPEG 分辨率：1536 × 1536 大小：420,655 字节 SHA-1：deff635b673de90cbadf603ce81c548cb2a805a9 SHA-256：0239d63859547149e61e5c987897291713593da222a63f7f0635e3bc0bce4d53 格式、分辨率、文件大小和哈希值均不匹配。换言之，助理和图像处理侧引用的并非用户的原始图像文件本身。而是在上传阶段或内部扩展阶段创建的、经过压缩和转换的衍生图像。关于图像“为了传输而暂时压缩，随后恢复为原始状态”的解释是无法成立的。声称一个 20 MB 甚至几 MB 的图像被压缩至约 300 KB 进行传输，随后又被完美恢复并作为原始图像使用，这是不可信的。要使这种解释成立，必须满足以下条件：原始图像必须能够从传输的数据中无损恢复；恢复后的图像必须包含与原始图像相同的像素；哈希值也必须与原始图像匹配。然而实际上，助理可访问的图像在格式、分辨率、文件大小或哈希值方面均与原始图像不匹配。因此，这并非“暂时压缩”。原始图像既未按原样发送，也未恢复为原始状态。创建了一个衍生图像，该衍生图像成为处理的对象。没有任何迹象表明在图像编辑过程中重新获取或重新扩展了原始图像文件。有人可能会争辩说，即使在上传时只发送轻量级衍生图像，系统也会在图像编辑操作期间检索原始图像文件或同等原始质量的数据，并以高质量进行处理。这一论点同样站不住脚。当实际执行图像编辑时：调用的工具是 `image_gen.text2im`。返回的图像约为两百万像素。在操作前后，均未观察到与该尺寸图像文件相对应的网络流量增加。似乎只有轻量级的控制或文本输出流量。生成后下载的图像同样也是约为两百万像素的图像。如果在编辑过程中重新获取或重新扩展了原始图像文件，则应发生与图像尺寸相对应的网络流量。但事实并非如此。因此，即使在图像编辑阶段，也未使用原始图像文件。编辑过程中使用的是在聊天中处理的衍生图像。调用的工具是 `image_gen.text2im`，而非图像编辑工具。虽然该功能被用作图像编辑，但助理实际调用的工具是 `image_gen.text2im`。这是一个文本到图像（Text-to-Image）流程的名称。因此，至少根据用户可观察到的执行信息，调用的流程并非“图像编辑”，而是“文本到图像”。这一点至关重要。如果操作是局部编辑或修补，流程名称或流程结构应与此功能相对应。然而实际上，调用的流程是 `text2im`。每一个返回结果都显示 DALL-E 生成元数据。通过检查此对话中作为生成结果返回的图像，在确认的 16 个案例中，全部显示了 DALL-E 生成元数据。换言之，尽管该功能是在 ChatGPT 应用程序内的 GPT Images / ChatGPT Images 2.0 图像编辑上下文中使用的，但返回的元数据始终是 DALL-E 生成元数据。此处的重点并非猜测 DALL·E 是否真正在内部运行。可观察到的事实是，用户可见的元数据始终一致为 DALL-E 生成元数据。显示的上下文与返回的元数据不一致。流程被调用为 `text2im`，返回为 `inpainting`，并产生全帧重新生成。在某些返回的元数据中显示了 `edit_op: "inpainting"`。然而，实际调用的工具是 `image_gen.text2im`。因此，可观察到的对应关系如下： 调用流程名称：`image_gen.text2im` 返回元数据：`edit_op: "inpainting"` 实际输出：全帧重新生成 这从根本上不一致。一个被调用为文本到图像的进程，在返回时被标记为修补（inpainting），而输出并非局部编辑，而是整个帧在像素级别上均发生变化的图像。因此，流程名称、返回元数据和实际结果并不一致。至少在此次观察中，这并非用户期望意义上的修补。修正区域被明确指定。问题并不在于“用户给出了模糊的指令”。事实上，在多次尝试中，用户明确指定了以下内容： 应修正哪些区域 应保留哪些区域 仅下半身 仅从腰部以下 保留面部、头发、上半身和背景 保留衣物 不更改指定区域之外的任何内容 使用蒙版 基于修补的前提进行 换言之，编辑的目标区域并不模糊。