Декодирование exif-блока mpf в файл стереоизображения MPO - PullRequest
1 голос
/ 19 сентября 2010

Я пишу что-то, чтобы получить информацию, содержащуюся в файле мультиизображения MPO, создаваемом камерами, такими как камеры Fuji 3D.

У меня есть предлагаемая спецификация, которая явно написана, чтобы запутать, идоступно здесь: CIPA multi picture spec PDF и переместились на обычные части exif и извлекли информацию MFP.

Раздел 5.2.3, который описывает списки заголовков Списки заголовков:

4 byte endian flag
4 byte offset
-- start of MP Index --
2 byte count
12 byte version
12 byte number of images
12 byte MP entry
12 byte Individual unique ID list
12 byte total number of capture frames
4 byte offset to next IFD.

На диаграмме показан список MP Entry и Unique ID, указывающий на смещение (которое составит 12 байтов).Однако в последующем описании показано, что запись MP должна составлять 16 байтов для каждого изображения (что в моем образце с двумя изображениями), а индивидуальный уникальный идентификатор - 33 байта для каждого изображения (мой образец не 'Это так).

Вплоть до количества изображений, все так, как и должно быть.У меня есть 2 изображения, версия правильная, и там, кажется, 3 блока (количество).Тем не менее, третий блок (который является MP Entry) имеет правильный код, правильное количество байтов и правильный тип, но содержит следующую информацию

32 00 00 00  52 00 00 00  02 00 02 20  40 63  1B 00 
00 00 00 00  00 00 00 00  02 00 02 00  EE 6F  1B 00 

Текст говорит, что содержание этого должно быть

offset   length   name
0x00     4        Individual Image attribute
0x04     4        individual Image Size
0x08     4        Individual image offset
0x10     2        dependant image 1 entry number
0x12     2        dependant image 2 entry number

Понятно, что нет смысла в том, что, если есть два изображения (это, по сути, 10-мегапиксельные JPEG-файлы), они имеют размер 52 байта и 0.

Может ли кто-нибудь взглянуть наэто и проверь, я не схожу с ума в моей интерпретации этого, или кто-нибудь знает, что должно быть здесь?

Извините, я знаю, что это немного сложно, но я действительно не могу понять, где это идет не так.

Ответы [ 2 ]

4 голосов
/ 14 декабря 2010

Я считаю, что с вашим тегом все в порядке.

Глава 5.2 (Расширения MP) спецификаций состояний MP Index IFD выглядит следующим образом:

  • Count (2байт)
  • Поля индекса MP (Общая информация о структуре)
  • Смещение следующего IFD (4 байта)
  • Значение (MP Index IFD)

До количества изображений все в порядке, согласно спецификации.Начиная с тега MP Entry, байты должны быть проанализированы следующим образом: (я буду использовать данные, проанализированные из моего файла MPO)

02 b0 07 00   20 00 00 00   32 00 00 00   52 00 00 00
02 00 02 20   00 13 18 00   00 00 00 00   00 00 00 00
  • 02-b0 - ID тега (запись MP),2 байта
  • 07-00 - тип (7 = неопределено), 2 байта
  • 20-00-00-00 - 32 (16 x NumberOfImages, два изображения в моем файле, это значение былоперед анализом), 4 байта
  • 32-00-00-00 - смещение первого IFD (50 байтов, начиная с тега endianness), 4 байта

Вот где данные ввода MPзаканчивается.Странно, что нет списка уникальных идентификаторов отдельных изображений (b003) или общего количества захваченных кадров (b004) тегов, возможно, они не нужны.В любом случае, следующие 4 байта показывают смещение следующего IFD, то есть:

  • 52-00-00-00 - Смещение следующего IFD (82 байта, начиная с тега endiannesss), 4 байта

Первый IFD (в моем случае) запускается сразу после смещения следующего IFD:

  • 02-00-02-20 - Атрибут отдельного изображения, 4 байта
  • 00-13-18-00 - размер отдельного изображения (в моем случае это 1 577 728 байт данных), 4 байта
  • 00-00-00-00 - смещение данных отдельного изображения (состояния для 0 в случае первого изображения), 4 байта
  • 00-00 - Зависимое изображение 1 (без зависимого изображения), 2 байта
  • 00-00 - Зависимое изображение 2 (без зависимого изображения), 2 байта

В вашем случае данные должны быть проанализированы следующим образом:

32 00 00 00  52 00 00 00  02 00 02 20  40 63  1B 00 
00 00 00 00  00 00 00 00  02 00 02 00  EE 6F  1B 00
  • 32-00-00-00 - Смещение первого IFD (50 байтов, начиная с тега endianness), 4 байта
  • 52-00-00-00 - смещение следующего IFD (82 байта, начиная с тега endiannesss), 4 байта
  • 02-00-02-20 - индивидуальное изображение припис., 4 байтаes
  • 00-13-18-00 - размер отдельного изображения (в котором указывается 1 794 880 байт данных), 4 байта
  • 00-00-00-00 - смещение данных отдельного изображения(состояния для 0 в случае первого изображения), 4 байта
  • 00-00 - Зависимое изображение 1 (без зависимого изображения), 2 байта
  • 00-00 - Зависимое изображение 2 (без зависимостиизображение), 2 байта

и запуск данных следующего изображения:

  • 02-00-02-00 - индивидуальный атрибут изображения, 4 байта
  • EE-6F-1B-00 - индивидуальный размер изображения (в котором указывается 1 798 126 байтов данных), 4 байта и т. Д.


ОБ ИЗОБРАЖЕНИИРАЗМЕР И СМЕЩЕНИЯ

Размер изображения и смещения могут немного сбить с толку.Spec говорит, что:

"Размер изображения - это данные между маркерами SOI и EOI" (гл. 5.2.3.3.2)

и

«Смещение данных (для второго изображения) указывается относительно адреса поля MP Endian в заголовке MP» (гл. 5.2.3.3.3)

Что я понимаюбыть следующим:

SOI---MPF_FIELDS-------------EOI 
      ^
      MP endian field
      XXXXXXXXXXXXXXXXXXXXXXXXXXSOI--------------------------EOI

(первое изображение, скажем, 2164288 байт между маркерами SOI и EOI, включая маркеры. Второе изображение, 2221368 байт между маркерами SOI и EOI, включая маркеры. Состояния XXXXX для смещения)

Смещение второго изображения означает, что маркер SOI начинается через lengthOf(XXXXX) байтов после маркера байтов MP, который находится в поле MP первого изображения.Я подозреваю, что если вы вычтите значение смещения из первого размера изображения, вы должны получить положение маркера MP Endian.

1 голос
/ 11 ноября 2010

Я полагаю, что базовый адрес составляет 8 байтов в заголовке APP2, сразу после «MPF \ 0» и прямо перед «II * \ 0», предполагая, что в порядке байтов не существует. В предоставленном вами шестнадцатеричном дампе нет тега MPO, но я предполагаю, что «32 00 00 00» указывает на смещение MPEntries, а «52 00 00 00» - это смещение следующего IFD. То, на что вы хотите посмотреть, это "02 00 02 20", что, вероятно, является атрибутом первого изображения.

Помните, что если смещение равно "00 00 00 00", оно не относительное, а абсолютное.

...