Иголка в яйце, яйцо в утке, утка в зайце, заяц - в шоке
lexa - 17/Авг/2015 20:04
Вот есть такой DNG, который я не люблю.
В частности по вот какой причине, следите за руками
- Теги DNG - это не все возможные метаданные. Всякие camera-specific вещи, вроде "активных точек автофокуса" туда не вписываются (ну и невозможно запихать в стандарт всю фантазию camera makers).
- Эти же теги не вписываются и в EXIF, поэтому их пишут в вендор-специфичный блок Makernotes (или много блоков, фантазия, повторяю, бесконечна).
- OK, говорят авторы стандарта DNG, мы этот блок целиком вот и фиганем в тег MakerNotesSafety. И даже сопровождают описание этого тега таким вот комментарием:
The MakerNote data must be self-contained. All offsets within the MakerNote must beoffsets relative to the start of the MakerNote, and must not point to bytes outside theMakerNote. - Правда вот непонятно что делать дальше. Допустим, у нас MakerNote Data в исходном файле - не self-contained, а (как и принято в TIFF-like форматах) смещения указывают наружу.
Править смещения? Ну, казалось бы. Только в этом случае софт, создающий DNG - должен структуру Makernotes понимать полностью, на практике этого не происходит, ибо не документированы эти камерные данные полностью нигде и никак, догадываемся всем миром, контрибьютим в exiftool. - И правят даже. С ошибками. Или не правят - и тогда смещения показывают в космос.
- И ладно бы всякий левый софт, но и 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, с той поправкой что там вообще неизвестно какие поля - смещения.