Иголка в яйце, яйцо в утке, утка в зайце, заяц - в шоке

Вот есть такой DNG, который я не люблю.

В частности по вот какой причине, следите за руками

  1. Теги DNG - это не все возможные метаданные. Всякие camera-specific вещи, вроде "активных точек автофокуса" туда не вписываются (ну и невозможно запихать в стандарт всю фантазию camera makers).
  2. Эти же теги не вписываются и в EXIF, поэтому их пишут в вендор-специфичный блок Makernotes (или много блоков, фантазия, повторяю, бесконечна).
  3. OK, говорят авторы стандарта DNG, мы этот блок целиком вот и фиганем в тег MakerNotesSafety. И даже сопровождают описание этого тега таким вот комментарием:
    The MakerNote data must be self-contained. All offsets within the MakerNote must be
    offsets relative to the start of the MakerNote, and must not point to bytes outside the
    MakerNote.
  4. Правда вот непонятно что делать дальше. Допустим, у нас MakerNote Data в исходном файле - не self-contained, а (как и принято в TIFF-like форматах) смещения указывают наружу.
    Править смещения? Ну, казалось бы. Только в этом случае софт, создающий DNG - должен структуру Makernotes понимать полностью, на практике этого не происходит, ибо не документированы эти камерные данные полностью нигде и никак, догадываемся всем миром, контрибьютим в exiftool.
  5. И правят даже. С ошибками. Или не правят - и тогда смещения показывают в космос.
  6. И ладно бы всякий левый софт, но и Adobe DNG Converter - тоже портит метаданные регулярно.

Риторический вопрос: может ли формат, который портит метаданные называться "архивным"?

Вишенка на торте: камерные JPEG от Лейки регулярно имеют битый блок Makernotes. Его пересаживают из DNG as is, не меняя смещения, которые начинают показывать в космос. Помню вот правил парсер EXIF/Makernotes для JPEG-а по весне в FRV.

Обратного, правда, чтобы камерный DNG имел сходу битую структуру - пока не видел.

(да, пишу этот текст я - в очередной раз пройдя по этим граблям. В конкретном случае виноват не Adobe, а HDRMerge)
P.S. Смешно сказать, но такой заголовок уже был, причем ровно на эту тему

Comments

А что мешает пихать в MakerNotesSafety все теги целиком, чтобы смещения точно были корректны?

Ну то есть разобрать Makernotes целиком, полностью их понимая, скопировать все внешние (относительно IFD если там IFD/бинарного блока если там бинарный блок) данные и поправить все смещения?

Теоретически - ничего. Практически - нужно полное понимание makernotes: где там смещения, где там чего. На практике - не наблюдается.

Там же еще производители камер дают угля. Например, у панасоника (если не путаю) внутри TIFF/EP (RAW) файла в кодировке (порядке байт) Intel - запросто может быть makernotes в кодировке моторолы. А может не быть. Exiftool с этим разбирается клево: считывает длину (количество записей) в IFD и если получилось слишком дохрена - значит порядок байт другой.

Как раз таки не разбирать и не поправлять, копировать одним куском всё, разве что размер записи получившейся поправить. Таким образом внешние ссылки (вроде как) станут внутренними.

Так нельзя куском.
Вот для случая TIFF-IFD-Like: все данные, которые больше 4 байт - расположены вне IFD. И могут быть произвольно раскиданы по файлу, часть скажем до RAW-данных, часть - после.

Эту тарелку с макаронами можно собрать и куда-то еще записать, но смещения поправить придется т.к. сохранить исходные смещения невозможно.

Аналогичная история с бинарными makernotes, с той поправкой что там вообще неизвестно какие поля - смещения.

Add new comment