JPEG原始塊中的「元數據」邊界究竟在哪裏？

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. 術語「圖像數據」之前發現的是很寬鬆。我相信你的意思是「圖像數據」實際上也分佈在許多不同類型的細分市場。作爲一個簡單的例子，有Huffman編碼表段（以段標記0xFFC4開始）和實際掃描數據段（以段標記0xFFDA開始）。我認爲有一個強有力的例子來說明這些細分市場都被認爲是「圖像數據」

我遠離這些格式的專家，但不幸的是我認爲答案比你複雜得多希望。如果你想讀取所有的非圖像數據信息，你真的需要解析整個圖像文件。好消息是，我確信必須有庫來做到這一點（儘管我不知道JS庫）。

這是嚴重過度簡化，但它只是爲了給你的，你需要尋找到

CNC中一些引用什麼的想法：

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

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

The actual JFIF file spec

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

The actual Exif file spec

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不適用。您可以將圖像大小編碼爲也在SOF標記中編碼的APP1標記。如果這些價值觀不同，我不知道會發生什麼。解碼器可能會使用SOF標記中的值並忽略APP1標記中的值。但是，有些應用程序可能不喜歡不同的值。

標記級別的JPEG流結構非常簡單。 EXIF標頭過於複雜。