“;元数据”;JPEG原始blob中的边界

Where exactly is the "metadata" boundary in a JPEG raw blob?

本文关键字：边界 blob JPEG 元数据 原始      更新时间：2023-09-26

我知道JPEG图像中有很多类型的"元数据"：

http://fotoforensics.com/tutorial-meta.php

但是，我必须在哪里剪切字节数组才能将blob拆分为通用元数据部分和剩余的实际图像数据部分？

我想保留所有元数据，调整图像大小，然后再次添加以前存储的元数据。

神奇的分隔符字节序列或位置是什么？

感谢

简短的回答是"取决于…"：）

这里有几件事需要考虑：

  1. 严格来说，"jpeg"是对实际图像数据的编码，并没有按照我相信你想要的那样指定文件格式。常见的文件格式有JFIF或Exif，每种格式都允许不同类型的元数据
  2. JFIF和Exif文件格式在元数据和图像数据之间没有一个完整的硬边界。例如，JFIF文件由许多段组成；几乎所有这些之后都有一定数量的数据。Exif更为复杂，但遵循相同的原则。例如，有几个标签被定义为APP0…APPn。许多程序/公司使用这些片段来编码某种形式的元数据。在每个段标记之后是两个字节长度的字段，后面是最多64K的数据（以长度字段的两个字节为界）
  3. 可以有任意数量的这些字段用于指定元数据
  4. 从技术上讲，这些字段可以出现在文件中的任何位置，尽管它们通常只在"图像数据"之前找到
  5. "图像数据"一词非常松散。我相信你所说的"图像数据"实际上也分布在许多不同类型的片段中。作为一个简单的例子，存在霍夫曼编码表分段（以分段标记0xFFC4开始）和实际扫描数据分段（以段标记0xFFDA开始）。我认为有充分的理由证明这些片段都被认为是"图像数据"

我不是这些格式的专家，但不幸的是，我认为答案比你希望的要复杂得多。如果你想读取所有的非图像数据信息，你真的需要解析整个图像文件。好消息是，我确信必须有库才能做到这一点（尽管我不知道JS库）。

这是一个严重的过度简化，但它只是为了让你知道你需要了解

-编辑-一些参考：

http://en.wikibooks.org/wiki/JPEG_-_Idea_and_Practice/The_header_part

http://en.wikipedia.org/wiki/JPEG#JPEG_files

实际JFIF文件规范

http://en.wikipedia.org/wiki/Exchangeable_image_file_format

实际Exif文件规范

我的回应是为了澄清一些事情。JPEG标准无法实现。例如，它定义了如何对组件进行编码和解码，但没有定义它是什么组件。JFIF是第一种常用的JPEG文件格式，用于填补空白。

如果我们将元数据定义为解码压缩图像所不需要的所有描述性数据；数据和元数据之间有一个相当清晰的边界。在大多数情况下，任何APPn或COM标记都是元数据。

我之所以这么说，在很大程度上是因为JFIF APP0标记的存在告诉解码器图像是灰度或YCbCr格式的，未经伽玛校正。实际上JFIF中几乎没有元数据（缩略图、像素密度）。

JFIF和EXIF流的结构不同之处仅在于定义格式的APPn标记的格式。由于APPn标记包括长度，解码器可以跳过该标记而不读取任何元数据。换句话说，JPEG解码器只需要知道它遇到了JFIF APP0标记或EXIF APP1标记来解码图像，并且不需要读取那些标记内的数据。

EXIF比JFIF更大的复杂性仅出现在APPn标记中。同样，解码器可以通过简单地跳过标记来忽略这种复杂性。

JFIF要求流以SOI标记开始，然后是APP1 JFIF标记。之后，您可以按任何顺序包含所需的任何APPn或COM标记。唯一的限制是标记数据不能以JFIF或JFXX开头。

JFIF APP0标记中没有任何链接到压缩数据的内容。EXIF并非如此。您可以在APP1标记中对图像大小进行编码，该标记也在SOF标记中进行编码。我不知道如果这些价值观不同会发生什么。解码器可能会使用SOF标记中的值，而忽略APP1标记中的那些值。然而，有些应用程序可能不喜欢不同的值。

在标记级别的JPEG流的结构非常简单。EXIF标头过于复杂。

相关文章：