JPEG原始Blob中的“元数据”边界到底在哪里？

Question

我了解JPEG图像中有许多类型的“元数据”：

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

但是我必须在哪里切割字节数组以将Blob拆分为常规元数据部分和其余实际图像数据部分？

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

魔术分隔符字节序列或位置是什么？

谢谢

Answer 1

简短的答案是“取决于...” :)

这里有几件事情要考虑：

1. 严格来说，“ jpeg”是实际图像数据的编码，并不像我所希望的那样指定文件格式。 常见的文件格式是JFIF或Exif，每种格式都允许使用不同类型的元数据
2. JFIF和Exif文件格式在元数据和图像数据之间没有完整的界限。 例如，JFIF文件由许多段组成。 几乎所有这些数据后面都有一些数据。 Exif比较复杂，但是遵循相同的原理。 例如，有几个标记定义为APP0 ... APPn。 许多程序/公司使用这些段来编码某种形式的元数据。 每个段标记之后是两个字节的长度字段，然后是最多64K的数据（以长度字段的两个字节为界）。
3. 这些字段可以有任意多个用于指定元数据
4. 从技术上讲，这些字段可以出现在文件中的任何位置，尽管它们通常仅在“图像数据”之前找到
5. 术语“图像数据”非常宽松。 我相信您所说的“图像数据”实际上也分布在许多不同类型的细分中。 作为一个简单的示例，有霍夫曼编码表段（以段标记0xFFC4开头）和实际扫描数据段（以段标记0xFFDA开头）。 我认为，有充分的理由将这些段都视为“图像数据”

我不是这些格式的专家，但不幸的是，我认为答案比您希望的要复杂得多。 如果要读取所有非图像数据信息，则确实需要解析整个图像文件。 好消息是，我确定必须有库来执行此操作（尽管我不了解JS库）。

简而言之，这太过简单了，但这只是为了让您了解需要研究的内容

-编辑-一些参考：

http://zh.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文件规格

Answer 2

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

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

我说的主要是因为仅存在JFIF APP0标记就告诉解码器图像是灰度图像或YCbCr格式，未经伽玛校正。 实际上，JFIF中的元数据很少（缩略图，像素密度）。

JFIF和EXIF流的结构仅在定义格式的APPn标记的格式上有所不同。 由于APPn标记包含一个长度，因此解码器可以跳过标记而无需读取任何元数据。 换句话说，JPEG解码器仅真正需要知道它遇到了JFIF APP0标记或EXIF APP1标记即可解码图像，而无需读取这些标记中的数据。

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

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

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

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