Трудовые будни

lexa - 21/Окт/2017 10:54

А вот вы знали, что Adobe XMP SDK может в некоторых случаях при записи XMP модифицировать еще и EXIF у файла?

И я не знал.

А поскольку случаи - некоторые, то в наших тестах оно как-то не вылезло (дальше нецензурно).

Разборки показали, что это, смешно сказать, рекомендованное поведение:

When the file format supports both Exif and XMP, a Changer SHOULD update both forms of a value. If only one form is updated, an existing value in the other form MUST be removed.

(источник: http://www.metadataworkinggroup.com/pdf/mwg_guidance.pdf, ссылка на него нашлась в документации XMP SDK).

Но в коде XMP SDK есть fast path, обновление XMP прямо в файле (если оно там есть и новая запись влезает), без полной перезаписи. В этом случае EXIF не обновляется и плевать на рекомендации.

Если честно, то я полностью фалломорфировал. Как-то вот привык уже, что метадата - это самое дорогое что есть в файле, не менее важно, чем сами данные, а тут Metadata Working Group говорит всем: да переписывайте, хрен с ними всеми.

P.S. А, да, смешно сказать, но Adobe Bridge такой херней не занимается, при записи XMP весь EXIF остается на месте. Потому что не теоретики писали, а практики (или практики надавали люлей теоретикам). Хотя их же XMP SDK там, скорее всего, используется.

P.P.S. А касается это многих программ, кои используют Adobe XMP SDK для записи XMP унутрь файла. Как сами используют, так и через прокладки вроде exempi (но не относится к exiv2, там писалка в JPEG своя).

Comments

anonim (not verified) - 21/Окт/2017 16:36

Тут проблема не только с ценностью метадаты, но и с бэкапом изменённых RAW, а они немаленькие.

lexa - 21/Окт/2017 17:25

А кстати да.

lexa - 21/Окт/2017 17:26

Тем не менее - лайтрум (например) не берет метадату для JPEG из XMP (для RAW - берет). Что заставляет.

blacklion - 22/Окт/2017 18:50

Любой вменяемый современный бэкап делает дедупликацию на уровне блоков. Нет, tar так не умеет, но не надо бэкапится tar'ом.
Я делал тесты — взял 52 гигабайта DNG'шек (прямо из камеры, у меня камера DNG пишет). Забэкапил. Прописал (с помощью exiftool) GPS-теги из треков. Забэкапил ещё раз. Пробовал 6 разных тулов — нормальные бэкапят в такой ситуации от 200 мегабайт до гигабайта. Т.е. не больше 2%.

lexa - 24/Окт/2017 09:25

Вот с JPEG (и XMP SDK) история такая:
- если XMP уже есть и размер APP-блока в JPEG достаточен, чтобы уместился новый XMP-блок, то новый блок пишется на место старого (в хвосте, если осталось место - добавляются пробелы). В этой ситуации блоки fs остаются, по большей части, нетронутыми.
- если XMP-блока нет, то он добавляется и все что было в файле после EXIF-блока (XMP добавляется сразу после EXIF) - сдвигается "на несколько сантиметров". В таком случае поблоковая дедупликация не поможет.

Думаю что с DNG/EXIF(GPS) и Exiftool ситуация похожая.

blacklion - 24/Окт/2017 10:51

А при чём тут блоки FS? Все эти бэкапилки используют rolling hash (идея, придуманная автором rsync'а), режут данные на блоки переменной длины контекстно-зависимо, и в случае сдвига данных бэкапят два блока и к третьему уже снова синхронизируются. От среднего размера блока (размера хэша по сути) зависит сколько это будет в байтах, почти у всех настраивается. У некоторых настройки по умолчанию очень велики (скажем, 4MiB), и они бэкапят много в такой ситуации, но стоит выставит средний рзамер блока килобайт в 128-256KiB и всё становится хорошо.

Смотри:

tarsnap — первый такой, самый вылизанный алгоритм, плох тем, что не программа в сервис и очень дорогой по нынешним временам — на картинках разоришься. 660MiB второй бэкап.

Остальное программы умеющие разные бэкенды, и sftp и облака, хочешь к себе на вторую NAS бэкапься, хочешь в облако за деньги:
duplicacy — большой блок по умолчанию (25GiB второй бэкап) , но при грамотных настройках 813MiB.
Attic — 749MiB второй бэкап, очень медленный.
restic — 8.3GiB, настроек не нашёл
Borg — 13GiB by default, 917MiB при правильных настройках.

При этом у всех этих тулов нет понятия full/incremental, а есть понятие сборки мусора. Что мне кажется очень удобным, идею full/incremental надо забыть как страшный сон.

Есть ещё duplicity работающий так же в смысле блоков но всё ещё мыслящий понятиями full/incremental, у него incremental тут 337MiB

И есть duplicati который требует такой .NET которого нет на FreeBSD (mono 5.2+) поэтому я не попробовал.

Напомню, что общий объём данных — 52GiB файлами по 16MiB.

blacklion - 24/Окт/2017 10:52

Это я к закрытию CrashPlan готовлюсь.

lexa - 24/Окт/2017 11:26

Я вот внезапно осознал (давно), что не готов отдавать в облако нешифрованое.

Инкременты для облака поэтому готовлю руками (в каком-то смысле, скриптом конечно) и обновляю их редко.

blacklion - 24/Окт/2017 15:48

Разумеется каждый блок в такой схеме шифруется отдельно. Облако видит только SHA256 (которое у них у всех — имя блока).
Из всего перечисленного шифруют все.

shadowfoto - 22/Окт/2017 01:32

д, б!

а есть список программ, которыми точно не стоит на эту тему пользоваться?

lexa - 22/Окт/2017 08:50

Речь идет о записи XMP внутрь JPEG, я бы вообще рекомендовал бы этим не пользоваться без нужды