- 按 5 分钟可执行顺序检查：文件状态 → 元数据 → 网上其他版本 → 肉眼异常 → 信号与溯源信息。
- 把元数据、压缩、几何变化、信号和来源信息放在一起看。
- 区分观察、解释和真正能够证明的范围。
先别看答案：哪一张是我们最初拍下的照片？
在看元数据和压缩痕迹之前，先比较一下 A 到 D。它们都来自同一个咖啡馆场景。其中一张是拍摄后作为起点的照片，其余三张分别经历了常规调色后重新导出 JPEG、裁剪并缩放后再次压缩，以及屏幕截图。如果只能看画面，你会选哪一张？
上面的四张图分别以独立文件显示，方便放大和对比。这里要看的不是这篇网页本身的元数据，而是每个图像文件实际经历过的处理过程。
查看答案和各版本的变化
A 是我们用作起点的拍摄照片。 B 只做了常见的亮度、对比度和饱和度调整，然后重新导出为 JPEG。C 经过轻微裁剪和缩放后，再次保存为 JPEG。D 来自横屏状态下的屏幕截图。单看画面，这四张都可能显得很“正常”。
这个练习想说明的并不是谁眼力更好。视觉上的把握感，不等于取证证据。真正值得检查的是文件结构、尺寸、元数据、重复压缩等可以观察和核对的信息。
“被编辑过”其实不是一个足够精确的问题
调整亮度、裁剪边缘、缩小分辨率、重新导出JPEG，甚至平台自动压缩，都可能让文件发生变化。截图则会把屏幕显示结果重新生成成一张新的图片。
因此，图像取证更适合从一个具体问题开始：现在这份文件里，实际能观察到哪些处理线索？
“这张JPEG存在与二次压缩一致的特征”是一种观察；“所以它是伪造图片”则需要更多证据。
5 分钟就能完成的第一轮检查
如果能拿到源文件，就优先查看它，而不是截图或再次下载的副本。先记下文件格式、像素尺寸和文件大小，弄清手里的文件到底是什么。
查看相机、时间、软件和工作流字段，但不要把它们当成不可更改的完整履历。没有元数据也不等于“没有编辑过”。
比起反复研究同一份压缩文件，更早出现或分辨率更高的版本往往更有帮助。比较裁剪范围、尺寸、文字、物体位置和发布语境。
留意边缘、重复纹理、文字、直线、透视、阴影和反射。把异常当作下一步需要检查的位置，而不是结论。
特定水印信号、Content Credentials 和系统专用标记分别回答更窄的问题。要和文件状态一起解读，不要让单一结果决定全部判断。
顺序很重要：先确认现在拿到的是什么文件，再收集相互独立的线索，最后只把结论推进到这些线索真正能支持的位置。
如果图片已经公开，和网上其他版本比一比
反向图片搜索能补充仅看文件本身得不到的上下文。Google Lens 可以找到相同或相似图片，以及使用这些图片的网页。Google 的“了解此图片”功能只在部分地区提供，在可用时还可能显示 Google 大约何时首次发现类似图片，以及更早出现的使用场景。
搜索结果里最早出现的页面，并不会自动成为“原图”。更适合比较不同版本的裁剪、分辨率、文字、物体位置和发布语境，再判断到底哪里发生了变化。如果照片涉及个人隐私、敏感信息或保密内容，除非你愿意把图片提交给外部搜索服务，否则可以跳过这一步；本地文件检查仍然可以继续。
可以放大找异常，但不要把“异常”直接当成“造假”
- 边缘与光晕：观察某些边界是否比周围细节明显更锐利或更模糊。
- 重复纹理：树叶、皮肤、云层或背景图案是否出现不自然的复制。
- 文字与几何：文字扭曲、直线断裂或透视关系不一致，都值得进一步查看。
- 光线、阴影与反射：检查方向和形状在整个场景里是否彼此协调。
这些都不是通用的篡改检测器。压缩、锐化、HDR、人像虚化、全景拼接、截图和普通编辑都可能产生相似现象。肉眼发现的异常更适合用来决定下一步检查哪里，而不是直接得出“假图”或“AI 生成”的结论。
元数据可以提供上下文，但不是完整履历
EXIF、XMP、IPTC以及应用自己的字段，可能记录拍摄参数、时间、设备、软件名称或工作流信息。如果某个软件声明存在，它可以帮助我们推测文件曾经过哪些环节。
但元数据可以被清除、改写、复制或保留。社交平台、聊天软件、截图、格式转换和隐私导出都可能让元数据消失。因此“没有元数据”并不能证明“没有编辑”。更多内容可参见 图片元数据到底能告诉我们什么？
JPEG重压缩会改变文件内部状态
JPEG采用有损压缩。一张已经压缩过的JPEG再次保存时，会重新进行量化和编码。肉眼看起来可能几乎一样，但量化表、块结构或局部压缩特征可能发生变化。
这些特征可以支持“文件可能经历了额外编码”的判断，却通常不能告诉你为什么发生了编码。编辑器、社交平台、云相册和普通导出流程都可能重新编码图片。
缩放与裁剪会改变图像几何
缩放通过插值建立新的像素网格；裁剪则直接删除边界之外的像素。这样的变化不仅影响图像取证测量，也可能影响依赖几何位置的隐形水印检测。
某些信号在缩放后仍可能部分存在，但检测器需要重新恢复同步关系。因此“没检测到”不能自动等同于“从未存在”。
软件名称更适合作为“声明信息”阅读
不少编辑工具会在保存时写入软件名称或流程记录。多个独立线索相互吻合时，信息价值会更高。但仅凭一个字段无法确定原始作者、最初生成工具或全部编辑步骤。
AI生成与AI编辑更不能依赖单一万能判断
目前没有一个统一标记能够覆盖所有生成式AI生态。某些平台提供自己的验证方式。Google使用SynthID检查由Google AI工具生成或编辑的内容，同时也明确说明：未检测到SynthID，并不能排除图片由其他AI系统生成的可能。
这说明系统专用信号可以对“这个系统是否参与”提供有价值的证据，但不应被扩大解释为通用AI检测。
C2PA Content Credentials属于另一类证据
C2PA通过签名manifest以及与资产的绑定来承载可验证的溯源声明。验证成功可以说明某些声明和当前资产之间存在受保护的关联。C2PA的设计原则同时强调，它并不负责对内容本身做“好/坏”或一般真实性判断。
溯源机制也不一定只依赖嵌入式元数据。Adobe说明，在支持的流程中，云端保存的Content Credentials即使面对截图，也可能通过匹配机制被找回。
更可靠的做法，是让多类线索互相验证
格式和尺寸、元数据结构、压缩状态、软件声明、可见编辑迹象、特定水印信号以及可用的溯源信息，分别回答不同问题。真正有价值的是这些观察之间是否一致，而不是强迫某一个字段回答所有问题。
| 观察结果 | 可能支持的结论 | 单独不能证明的内容 |
|---|---|---|
| 发现软件元数据 | 当前文件带有相关软件声明 | 原始作者和全部编辑历史 |
| 发现重压缩特征 | 文件可能经历过额外JPEG编码 | 处理动机或是否存在欺骗 |
| 缩放/裁剪特征 | 图像几何可能发生变化 | 作者身份或所有权 |
| 检测到特定隐形信号 | 与该信号体系相关的证据 | 通用溯源或法律所有权 |
| 存在Content Credentials | 可验证的溯源声明 | 对内容整体真实性的万能判断 |
把分散的线索放到 SIGNA Inspect 里一起看
当前已发布的SIGNA Android应用把可见水印、隐形SIGNA信号和设备端图像检查放在同一个流程中。SIGNA Inspect可以显示与SIGNA信号、可用元数据以及图像状态和处理相关的信息。
与其在不同工具之间来回切换，SIGNA Inspect 可以在设备端把支持的元数据、图片状态信息和 SIGNA 信号放在一起查看。重压缩、缩放、裁剪、截图等操作会改变文件里留下的线索，因此从多个角度看手上的这张图片更有实际价值。
更重要的是确认当前文件里真实存在什么证据，以及每一条证据最多能支持到哪里。
用 SIGNA Inspect 打开它，就能在手机本地一起查看当前文件中可用的元数据、图片状态与处理相关信息，以及 SIGNA 信号信息。常规图片检查在设备端完成，所选照片无需上传到 SIGNA AI Lab 的服务器。
主要参考资料
Google Gemini — Verify AI-generated images, videos, and audio
看看这张照片现在能告诉你什么
SIGNA Android 版把图片检查和分享前处理放在手机本地完成。你可以查看可用的元数据和图片状态信息、检查 SIGNA 信号，也可以在分享前为照片加入可见水印和不可见的 SIGNA 信号。所选照片无需上传到 SIGNA 的图片处理服务器。
