JHead: работа с EXIF, датами и ориентацией JPEG

JHead решает узкий, но практичный набор задач вокруг EXIF и служебных сегментов фотографий: показывает параметры съёмки, пакетно исправляет дату и время, переименовывает файлы по времени кадра, управляет встроенными миниатюрами и комментариями, удаляет метаданные и приводит JPEG к правильной ориентации. Программа полезна фотографам, архивистам, системным администраторам и тем, кто обрабатывает большие каталоги снимков скриптами и предпочитает воспроизводимые команды вместо ручного редактирования каждого файла.

Как устроена работа JHead

У JHead нет окна с панелями, списком файлов и кнопкой «Сохранить». Это не интерактивный редактор, а команда: ей передают один или несколько файлов и, при необходимости, ключ операции. Если запустить программу только с именем JPEG, она читает заголовок и печатает найденные сведения. Если добавить изменяющий ключ, программа выполняет соответствующую операцию и заканчивает работу. Такая модель особенно удобна, когда один и тот же шаг нужно повторить для десятков или тысяч кадров.

Другие инструменты для работы с фотографиями: ФотоМАСТЕР.

Основная область JHead — служебные данные, а не ретушь изображения. Программа разбирает EXIF и ряд других секций JPEG, умеет работать с JPEG-комментарием, IPTC и XMP в части удаления, а также обращается к полям, связанным с датой, ориентацией и встроенной EXIF-миниатюрой. Пиксельную коррекцию цвета, удаление объектов, слои, маски и RAW-проявку она не выполняет. Это важно понимать до начала работы: JHead исправляет описание и организацию файла, а не заменяет фоторедактор.

В актуальном исходном дереве появились ограниченные операции с EXIF, находящимся в PNG и WebP, однако распространённые пакетные сборки JHead могут относиться к JPEG-ориентированным выпускам. Поэтому формат файла нельзя определять только по общей документации в интернете. Сначала стоит выполнить jhead -V, затем jhead -h и проверить набор ключей именно в установленной сборке. Для JPEG описанные ниже базовые сценарии являются основной и наиболее зрелой областью применения программы.

JHead не пытается превратить EXIF в универсальную базу произвольных тегов. Редактирование намеренно ограничено полями и операциями, для которых в программе есть специальная логика: временем, частью комментариев, ориентацией, миниатюрой и секциями целиком. Если задача звучит как «создать произвольный GPS-тег», «массово записать авторские поля XMP» или «перенести сложный набор тегов между десятками форматов», для неё практичнее ExifTool или Exiv2. Сильная сторона JHead — короткие предсказуемые команды для типовых JPEG-задач.

Установка и начало работы

После установки прежде всего проверьте, что исполняемый файл доступен из текущей командной оболочки. Команда jhead -V выводит сведения о версии и сборке, а jhead -h — перечень поддерживаемых параметров. Эти две команды полезнее, чем копирование примеров из старой статьи: набор возможностей менялся, и некоторые исторические ключи из прежних выпусков в новых исходниках уже отсутствуют.

В Linux JHead часто присутствует в штатных репозиториях дистрибутива. На macOS утилита доступна через распространённые менеджеры пакетов. В Windows можно использовать готовую сборку либо собрать программу из исходников. Независимо от системы рабочая логика одинакова: откройте терминал, перейдите в каталог с копиями фотографий и сначала выполните чтение метаданных без изменяющих ключей.

jhead IMG_0001.JPG

Если путь или имя содержит пробелы, заключайте его в кавычки:

jhead "D:ФотоПоездка 1IMG_0001.JPG"

На первом знакомстве разумно работать не с единственным экземпляром архива, а с копией нескольких характерных файлов: обычным JPEG с EXIF, кадром с GPS, фотографией с поворотом по Orientation и файлом после экспорта из редактора. Так сразу видно, какие секции сохранила именно ваша камера и какие поля JHead воспринимает после сторонней обработки.

У программы нет отдельного режима предварительного просмотра изменений. Читающий запуск безопасен, но корректирующая команда при корректных аргументах применяется сразу. Особенно это важно для удаления EXIF и массовой коррекции времени: «подтвердить для каждого файла» JHead не просит. Перед пакетной записью полезно сначала сузить маску до нескольких тестовых кадров, сверить результат и только затем расширять её на каталог.

Чтение EXIF и других сведений о файле

Самая простая операция — передать JHead имя фотографии без дополнительных параметров. Программа выводит только те сведения, которые смогла извлечь или вычислить. В типичном файле камеры можно увидеть имя и размер файла, файловую дату, производителя и модель камеры, Date/Time, разрешение, сведения о вспышке, фокусное расстояние, выдержку, диафрагму, ISO, баланс белого, режим замера и координаты GPS, если они присутствуют.

В строке File date показывается время самого файла в файловой системе; оно не обязано совпадать с моментом съёмки. Строка Date/Time относится к данным EXIF и обычно отражает время кадра, записанное камерой. Эта разница принципиальна: копирование фотографии, распаковка архива или работа облачного клиента может изменить файловую метку, тогда как EXIF останется прежним. И наоборот, после экспорта из редактора EXIF может исчезнуть, а файловая дата сохранится или станет датой экспорта.

Показатель JPEG Quality также нужно трактовать правильно. В JPEG нет универсального поля, которое гарантированно хранит исходный ползунок «качество». JHead оценивает качество по таблицам квантования. Для стандартных таблиц такая оценка полезна для диагностики, но её нельзя считать доказательством точной настройки камеры или редактора. Нестандартные таблицы могут сделать численную оценку условной.

Краткий вывод для каталогов

Ключ -c переводит вывод в компактную однострочную форму. Это удобно, когда результат планируется фильтровать средствами оболочки, сохранять в текстовый файл или импортировать в таблицу. Поля разделяются пробелами, а текстовые значения заключаются в кавычки. Для человеческого чтения обычный многострочный режим нагляднее, но для десятков файлов компактный режим быстрее просматривается и проще обрабатывается.

jhead -c *.jpg

Ключ -v делает вывод более подробным. Он полезен при диагностике необычного JPEG или при проверке того, какие сегменты программа увидела. Для анализа структуры EXIF существует -exifmap: он показывает карту байтов заголовка. Это уже инструмент для разбора повреждённых или нетипичных файлов, а не повседневная команда фотографа.

-se подавляет сообщения об ошибках, относящихся к повреждённой структуре EXIF. Его не следует воспринимать как «починку заголовка»: ключ только снижает шум вывода. Если важный файл вызывает структурные ошибки, сначала сохраните оригинал, сравните результат чтения другими инструментами и не выполняйте массовую запись поверх единственной копии.

Исправление даты и времени съёмки

Одна из самых полезных функций JHead — массовая коррекция часов камеры. Это типичная ситуация после поездки: камера осталась в старом часовом поясе, часы спешили на несколько минут, либо две камеры снимали одно событие с постоянным смещением. Исправлять каждую фотографию вручную не требуется, если ошибка одинакова для всей серии.

Постоянное смещение с помощью -ta

Ключ -ta добавляет или вычитает заданный интервал из времени EXIF. Формат позволяет указывать часы и минуты, а при необходимости секунды. Например, чтобы прибавить один час ко всем JPEG в каталоге:

jhead -ta+1:00 *.jpg

Чтобы вычесть 23 секунды:

jhead -ta-0:00:23 *.jpg

Если нужна поправка только в минутах, допустима соответствующая короткая запись. Смысл операции — не подставить всем файлам одну дату, а сохранить интервалы между кадрами и сдвинуть всю серию на одинаковую величину. Поэтому -ta подходит для неверного часового пояса или стабильного отставания часов.

Перед массовым исправлением найдите кадр, время которого можно независимо проверить: фотографию часов, билет, запись телефона, сообщение или другой синхронный источник. Рассчитайте смещение на одном файле, примените к копии нескольких соседних кадров, снова прочитайте их JHead и только после проверки запускайте маску на всю серию.

Большое календарное смещение с помощью -da

Ключ -da предназначен для ситуации, когда нужно перенести даты относительно двух заданных календарных точек. Он удобен для крупных сдвигов, где простое число часов становится неудобным, и учитывает разную длину месяцев и лет. Формат использует даты вида yyyy:mm:dd; при необходимости к ним добавляется время. Такой подход практичнее ручного подсчёта количества суток между, например, неверно установленным годом камеры и фактической датой.

Перед применением -da особенно важно проверить первый и последний кадр серии. Ошибка в исходной или целевой календарной точке даст систематически неверный результат всему набору, а визуально фотографии от этого не изменятся — проблема обнаружится только при сортировке или импорте в каталогизатор.

Явная установка даты: -ts и -ds

-ts задаёт полное значение даты и времени EXIF в формате yyyy:mm:dd-hh:mm:ss и приводит связанные временные поля к заданному значению. Это подходит для единичного файла или небольшого набора, когда точный момент известен. Для серии кадров -ts обычно не годится: одинаковое время уничтожит естественные интервалы между снимками.

-ds позволяет задавать дату с меньшей детализацией: полный год, год и месяц либо полную дату, в зависимости от используемой формы. Это полезно при восстановлении архивов, где известна только часть календарной информации. Однако нельзя превращать предположение в ложную точность: если известен только год, не стоит выдумывать день и время только ради красивой сортировки.

Синхронизация EXIF и файловой даты

Ключ -ft переносит дату EXIF в файловую метку времени. Он полезен после копирования, когда файловая дата стала датой переноса, а правильный момент съёмки сохранился внутри фотографии. После -ft файловые менеджеры, сортирующие по времени изменения файла, начинают показывать порядок ближе к хронологии съёмки.

jhead -ft *.jpg

Обратная операция -dsft устанавливает дату EXIF из файловой метки. Это следует применять только когда файловая дата действительно заслуживает доверия. Если она появилась при скачивании из мессенджера или распаковке архива, переносить её в EXIF нельзя. Для файла без EXIF можно сначала создать минимальную секцию с помощью -mkexif, а затем использовать файловую дату как источник, но это уже реконструкция метаданных, а не восстановление исходных данных камеры.

-tf берёт время модификации другого файла и использует его для даты EXIF текущей фотографии. Сценарий встречается реже, но полезен, когда точная временная точка хранится в связанном файле. Перед такой синхронизацией нужно убедиться, что источник не был перезаписан или скопирован с изменением файлового времени.

Переименование и раскладка фотографий по дате

Ключ -n переименовывает файлы по времени DateTimeOriginal. Это один из наиболее практичных способов превратить имена вроде IMG_8432.JPG и DSC_1021.JPG в общую хронологическую схему. Если корректной EXIF-даты нет, JHead может использовать файловую дату, поэтому перед массовым запуском нужно определить, приемлемо ли такое резервное поведение для конкретного архива.

Простой формат с годом, месяцем, днём, часами, минутами и секундами:

jhead -n%Y%m%d-%H%M%S *.jpg

В результате имя строится средствами форматирования времени. Поддерживаются знакомые обозначения: %Y — четырёхзначный год, %y — двухзначный год, %m — месяц, %d — день, %H — часы, %M — минуты, %S — секунды, %j — номер дня в году, %w — день недели, а также недельные обозначения, предоставляемые форматом времени.

В формат можно включать %f для исходного имени без расширения и %i для последовательного номера. Это помогает, если секунды недостаточно для уникальности: современные камеры способны сделать несколько кадров за одну секунду. При столкновении имён JHead также добавляет суффикс, однако для большого архива лучше заранее выбрать схему, в которой уникальность и сортировка понятны без последующего расследования.

Каталоги в шаблоне имени

Если в формате присутствуют разделители пути, JHead может использовать их для формирования пути и перемещения файлов в каталоги по дате. Такой режим удобен для раскладки вида «год/месяц», но он повышает цену ошибки: неверный шаблон меняет не только имя, но и расположение. Начинайте с тестовой папки и после выполнения проверьте итоговое дерево каталогов.

В Windows есть дополнительная особенность командных файлов: символ процента интерпретируется самим batch-синтаксисом. Поэтому в .bat или .cmd знаки % в шаблоне времени обычно нужно удваивать. Команда, набранная вручную в консоли, и та же строка внутри batch-файла могут выглядеть по-разному. Если шаблон внезапно теряет спецификаторы, проверяйте сначала экранирование оболочки, а не JHead.

На Unix-подобных системах маски файлов обычно разворачивает оболочка до запуска JHead. На Windows JHead исторически предоставляет собственную обработку масок и в актуальной документации описывает рекурсивный шаблон с компонентом **. Не следует переносить этот синтаксис между системами автоматически. Для воспроизводимого скрипта явно учитывайте, какая оболочка отвечает за рекурсию.

Автоповорот JPEG по Orientation

Цифровая камера часто сохраняет пиксели в «родной» ориентации матрицы и записывает в EXIF тег Orientation. Современный просмотрщик поворачивает изображение на лету, но не все программы, веб-сервисы и старые устройства делают это одинаково. Ключ -autorot физически приводит JPEG к нужной ориентации, ориентируясь на EXIF, и затем устанавливает значение ориентации в нормальное состояние.

jhead -autorot *.jpg

Сам JHead не содержит полноценного JPEG-кодека для этой операции: он вызывает внешнюю программу jpegtran. Поэтому наличие JHead ещё не гарантирует работу автоповорота. Если команда сообщает, что внешняя утилита не найдена, установите совместимую реализацию jpegtran и убедитесь, что она доступна в PATH либо там, где её ожидает конкретная сборка.

Поворот через jpegtran рассчитан на преобразование JPEG без обычного цикла декодирования и повторного сжатия, то есть без типичной дополнительной потери качества от повторного сохранения. При этом ограничения JPEG-блоков на краях изображения никуда не исчезают: для некоторых геометрий полностью без потерь можно преобразовать только область, согласованную с блоковой структурой. Для обычных камер кадры часто имеют подходящие размеры, но это не универсальная гарантия для любого JPEG после произвольного кадрирования.

JHead также поворачивает встроенную EXIF-миниатюру при автоповороте. Однако поля размеров внутри EXIF могут не быть пересчитаны так, как это сделал бы полноценный редактор метаданных; документация отдельно предупреждает о несовпадении некоторых размерных полей после внешних преобразований. Если последующий каталогизатор критично использует EXIF PixelXDimension/PixelYDimension, проверьте эти теги отдельным инструментом.

Когда нужен -norot

-norot не вращает пиксели. Он очищает или нормализует ориентационный признак, когда само изображение уже физически повернуто правильно, а EXIF остался старым. Типичный симптом — один просмотрщик показывает кадр нормально, другой переворачивает его второй раз. В такой ситуации повторный -autorot может сделать хуже, а сброс ошибочного тега — именно то, что нужно.

Перед -norot откройте файл в программе, которая умеет игнорировать EXIF Orientation, либо посмотрите фактическую ширину и высоту. Нельзя определять состояние только по одному современному просмотрщику: он может скрывать проблему автоматическим поворотом.

Встроенные EXIF-миниатюры

Многие камеры помещают в EXIF небольшое JPEG-превью. Оно помогает быстро показывать фотографию без декодирования полного изображения, но после редактирования может устареть: в основном кадре уже выполнено кадрирование или ретушь, а миниатюра всё ещё демонстрирует исходник. JHead предоставляет несколько специализированных команд для этой секции.

Сохранение миниатюры: -st

-st извлекает встроенное превью в отдельный файл. В имени результата можно использовать подстановку &i, соответствующую имени входного файла. Амперсанд имеет специальное значение для многих оболочек, поэтому шаблон следует заключать в кавычки. На Unix-подобных системах специальное имя - может использоваться для вывода извлечённых данных в стандартный поток, что удобно в конвейере.

Извлечение — хороший диагностический шаг перед удалением или регенерацией. Если миниатюра визуально не соответствует основному кадру, это объясняет, почему некоторые файловые менеджеры или старые просмотрщики кратко показывают «не ту» картинку.

Удаление и замена: -dt и -rt

-dt удаляет встроенную EXIF-миниатюру, сохраняя остальную метаинформацию. Это отличается от удаления всего EXIF. Команда полезна, когда превью устарело и не нужно приложению-потребителю. После удаления размер файла обычно уменьшается лишь на размер маленького превью; смысл операции — согласованность, а не существенная экономия места.

-rt заменяет существующую миниатюру указанным JPEG. Важное ограничение: операция рассчитана на EXIF-заголовок, где место под миниатюру уже предусмотрено; она не превращает произвольный файл без соответствующей структуры в полноценный камерный EXIF. Размер и пригодность вставляемого превью также нужно контролировать.

Регенерация: -rgt

-rgt пересоздаёт миниатюру по основному изображению. Актуальная документация использует для этого внешний ImageMagick через команду magick. Как и в случае jpegtran, зависимость должна быть установлена отдельно. Регенерация работает в контексте существующей EXIF-структуры с миниатюрой; это не универсальная команда «добавить превью куда угодно».

После регенерации полезно снова выполнить -st для одного файла и визуально сравнить извлечённое превью с основным изображением. Такой контроль быстрее выявляет проблемы с путём к ImageMagick или с неподдерживаемой структурой EXIF, чем массовый запуск вслепую.

JPEG-комментарии, EXIF, IPTC и XMP

JHead различает несколько служебных областей файла. Это важно при очистке: «удалить метаданные» может означать разные вещи. EXIF обычно содержит параметры камеры, дату, GPS и миниатюру; IPTC и XMP могут хранить подписи, ключевые слова, авторские и редакционные поля; JPEG Comment — отдельный комментарий в структуре JPEG.

Комментарий JPEG

-cl заменяет комментарий текстом, переданным в командной строке. Если текст содержит пробелы или символы оболочки, заключайте его в кавычки и учитывайте правила конкретного терминала. -dc удаляет поле комментария. Эти операции не являются редактированием произвольного XMP-описания — речь именно о JPEG Comment.

Удаление секций

-de удаляет EXIF-секцию, оставляя другие поддерживаемые служебные области вроде IPTC, XMP и комментария. Это удобный способ убрать камерные данные, но он неизбирателен внутри EXIF: вместе с моделью и экспозицией исчезнут дата, GPS, Orientation и другие EXIF-теги. Если изображение полагается на Orientation для правильного отображения, перед удалением EXIF сначала физически нормализуйте поворот.

-di удаляет IPTC, а -dx — XMP. Возможность чистить области отдельно полезна при подготовке публикации: можно сохранить одну систему описаний и удалить другую. Но JHead не является детальным редактором содержимого этих секций; его сила здесь — удаление целого блока.

-purejpg очищает JPEG от не относящихся к визуальному декодированию секций, оставляя «чистую» структуру изображения. Это наиболее радикальная операция и потому требует копии исходника. После неё нельзя рассчитывать на сохранение EXIF, подписей, комментариев или других служебных вложений только потому, что картинка визуально выглядит так же.

Конфиденциальность и GPS

У JHead нет отдельного повседневного ключа «удалить только GPS и сохранить остальные EXIF-поля» в том же удобном смысле, в каком есть -de для секции целиком. Если задача — точечно вычистить координаты, оставив объектив, выдержку, автора и дату, лучше использовать инструмент с адресной записью тегов. Если допустимо удалить весь EXIF, -de решает задачу проще.

После очистки всегда проверяйте результат чтением, а для чувствительных публикаций — вторым независимым инструментом. Отсутствие строк GPS в коротком выводе не всегда означает отсутствие всех потенциально идентифицирующих данных: они могут находиться в XMP, IPTC, комментариях или нестандартных секциях.

Создание минимального EXIF

Ключ -mkexif создаёт минимальную EXIF-структуру в JPEG, где её не было. Это не попытка восстановить параметры камеры. Минимальный заголовок предназначен прежде всего для даты/времени и структуры, необходимой некоторым дальнейшим операциям JHead; произвольные дополнительные поля с помощью этого ключа не добавляются.

По умолчанию источником времени может служить файловая дата. Такой сценарий имеет смысл для сканов или экспортированных изображений, если файловое время заранее приведено к нужному значению. Но создание EXIF на основании ненадёжной файловой даты закрепит ошибку уже внутри файла. Сначала выясните происхождение timestamp, затем решайте, переносить ли его в метаданные.

Практическая последовательность для подготовленной копии может выглядеть так: убедиться, что EXIF отсутствует; проверить файловую дату; выполнить -mkexif; при необходимости синхронизировать дату через -dsft; снова прочитать файл обычным jhead. Такой порядок не добавит модель камеры, ISO или объектив — и именно это нормально, потому что этих данных у программы нет.

Фильтрация набора перед пакетной операцией

Маска *.jpg проста, но не всегда достаточно точна. В каталоге могут лежать кадры разных камер, экспортированные копии и изображения без EXIF. JHead имеет несколько фильтров, помогающих ограничить набор до нужных файлов.

Отбор по модели камеры

-model обрабатывает только файлы, в чьём EXIF-названии модели присутствует указанная подстрока. Это удобно, когда в одной папке объединены материалы двух камер, но поправка времени относится только к одной. Перед изменяющей командой запустите фильтр в читающем режиме и убедитесь, что он выбирает именно ожидаемую серию.

Подстрока должна соответствовать тому, как модель записана в EXIF. Не ориентируйтесь только на название на корпусе камеры. Сначала прочитайте один файл, скопируйте характерную часть значения Camera model, затем используйте её в фильтре.

Пропуск файлов без EXIF

-exonly заставляет пропускать изображения без EXIF. Это особенно полезно в смешанном каталоге, где есть веб-копии или результаты экспорта. Без такого ограничения некоторые операции могут опираться на файловую дату либо выдавать лишние сообщения для файлов, к которым выбранный сценарий неприменим.

Рекурсия и оболочка

В Unix-подобных системах рекурсивный обход обычно удобнее строить средствами оболочки или find, передавая JHead найденные файлы. В Windows текущая документация JHead описывает собственный рекурсивный шаблон **, причём двойная звёздочка должна составлять целый компонент пути. Это платформенная особенность; не стоит предполагать, что один и тот же шаблон даст одинаковый список файлов в Bash, PowerShell и классическом cmd.

Перед рекурсивной записью полезно сначала получить список кандидатов без изменения. В больших фотоархивах опаснее всего не сама команда, а слишком широкая выборка: она может затронуть экспортные копии, вложенные резервные каталоги или уже исправленную часть коллекции.

Пакетные сценарии без лишнего риска

JHead ценен именно тем, что одна команда применяется к множеству файлов, но эта же особенность требует дисциплины. Надёжный рабочий процесс состоит не из «сразу запустить на всём диске», а из короткой последовательности проверки.

1. Скопируйте несколько репрезентативных фотографий в тестовый каталог.
2. Снимите исходное состояние обычным выводом JHead и при необходимости сохраните его в текстовый файл.
3. Сформулируйте одну операцию: только время, только переименование, только очистка или только поворот.
4. Примените её к одному или нескольким тестовым файлам.
5. Снова прочитайте метаданные и откройте изображение просмотрщиком.
6. Только после проверки расширяйте маску до всей серии.

Разделение операций упрощает диагностику. Если одновременно сдвинуть дату, переименовать файл, удалить EXIF и повернуть JPEG, а затем заметить проблему, выяснить причину будет сложнее. Кроме того, некоторые шаги логически конфликтуют: например, удалив EXIF, вы лишитесь источника DateTimeOriginal и Orientation, на которых основаны последующие команды.

Хороший порядок для подготовки фотографии к публикации обычно таков: сначала прочитать EXIF; при необходимости выполнить автоповорот; проверить изображение; затем удалить те метаданные, которые не должны публиковаться. Для архивной обработки, наоборот, сначала исправляют дату, затем переименовывают по исправленному времени и только после этого синхронизируют файловую дату, если это требуется выбранной системе хранения.

Практический сценарий: камера снимала в другом часовом поясе

Предположим, камера весь день показывала время на два часа меньше фактического. Интервалы между кадрами правильные, значит менять каждый timestamp на фиксированное значение нельзя. Нужен общий сдвиг.

1. Найдите кадр с проверяемым временем и прочитайте его: jhead IMG_0123.JPG.
2. Сопоставьте Date/Time с внешним источником и подтвердите величину ошибки.
3. На копии нескольких файлов выполните jhead -ta+2:00 *.JPG.
4. Снова прочитайте первый, средний и последний кадр.
5. Если время корректно и переход через полночь обработан как ожидается, примените команду к серии.

Такой способ сохраняет секунды и естественный порядок. Если в середине съёмки часы камеры вручную меняли, одна поправка для всего дня уже неприменима: коллекцию нужно разделить на интервалы с разными смещениями.

Переход на летнее время также требует осторожности. JHead работает с записанными значениями и заданным смещением; он не выступает базой часовых поясов, которая автоматически знает исторические правила конкретного региона. Определяйте поправку исходя из фактического периода съёмки.

Практический сценарий: свести две камеры в одну хронологию

При съёмке мероприятия двумя камерами кадры часто импортируются в один каталог, но часы устройств расходятся на десятки секунд или несколько минут. Для корректной сортировки сначала нужно определить сдвиг одной камеры относительно другой.

Выберите событие, снятое почти одновременно обоими устройствами: вспышку, начало выступления, общий кадр с заметным действием. Считайте EXIF обеих фотографий и вычислите разницу. Затем используйте -model, чтобы коррекция затронула только одну модель. До записи проверьте, что фильтр действительно отделяет камеры: некоторые семейства записывают похожие названия, а после обработки сторонним ПО поле модели могло исчезнуть.

После коррекции не обязательно немедленно переименовывать файлы. Сначала импортируйте несколько тестовых кадров в программу-каталогизатор и убедитесь, что сортировка по времени съёмки соответствует реальному порядку. Только затем можно применять -n для единой схемы имён. Такой двухэтапный подход отделяет исправление метаданных от организации файлов.

Практический сценарий: переименовать архив по дате съёмки

Перед переименованием нужно проверить три вещи: есть ли DateTimeOriginal, уникальна ли выбранная точность времени и не смешаны ли в каталоге файлы без EXIF. Если часть изображений лишена EXIF, их имена могут строиться по файловой дате и оказаться в неожиданном месте хронологии.

Для архива, где достаточно секундной точности, удобно начать с шаблона:

jhead -n%Y-%m-%d_%H-%M-%S *.jpg

Дефисы безопаснее двоеточий в кроссплатформенных именах. Если камера делает серии быстрее одного кадра в секунду, добавьте последовательный компонент или сохраняйте часть исходного имени через %f. После теста отсортируйте папку по имени и визуально проверьте несколько серийных последовательностей.

Если конечная цель — каталоги по годам и месяцам, сначала выполните простое переименование в одном каталоге. Когда схема подтверждена, переходите к шаблону с компонентами пути. Это снижает риск создать глубокую неверную структуру из-за одной ошибки в спецификаторе.

Практический сценарий: подготовить JPEG к публикации без EXIF

Если нужно убрать камерные данные и координаты, но сохранить пиксели JPEG без полноценного повторного экспорта, JHead может удалить EXIF напрямую. Однако последовательность важна из-за Orientation.

1. Прочитайте файл и проверьте строку Orientation.
2. Если изображение зависит от тега поворота, выполните -autorot и визуально проверьте результат.
3. Если требуется удалить EXIF целиком, выполните -de.
4. Если также нужно убрать IPTC или XMP, примените соответствующие ключи отдельно либо используйте более радикальный режим очистки, если он действительно соответствует задаче.
5. Снова прочитайте файл и проверьте его независимым просмотрщиком метаданных.

Удаление только EXIF не гарантирует отсутствие авторской подписи или иных данных в XMP/IPTC. И наоборот, удаление XMP не убирает GPS, если координаты находятся в EXIF. Поэтому сначала решите, какие типы информации допустимы в публикации, и только затем выбирайте секции для удаления.

Практический сценарий: исправить неверный поворот после старой программы

Старый редактор мог физически повернуть JPEG, но оставить исходное значение Orientation. Современный просмотрщик затем применяет поворот ещё раз. Диагностика начинается с проверки фактической ориентации пикселей и значения EXIF.

Если пиксели уже расположены правильно, используйте -norot, а не -autorot. После этого проверьте изображение в двух разных просмотрщиках. Если EXIF-миниатюра осталась повернута иначе, её можно удалить -dt либо регенерировать -rgt при наличии требуемой внешней утилиты и подходящей EXIF-структуры.

Если же пиксели не повернуты, а Orientation корректно описывает требуемый разворот, применяйте -autorot. Не смешивайте эти случаи: один ключ меняет изображение, другой только нормализует метаданные.

Практический сценарий: привести файловые даты к времени съёмки

После копирования с карты памяти фотографии могут получить файловую дату, не совпадающую с датой кадра. Если сторонняя программа сортирует именно по файловому времени, можно перенести EXIF-время наружу через -ft.

Сначала проверьте, что DateTimeOriginal корректен и уже учтены нужные поправки часового пояса. Если сначала выполнить -ft, а потом исправить EXIF через -ta, файловая дата снова будет отставать. Логичный порядок: исправить EXIF, проверить, при необходимости переименовать, затем выполнить -ft.

Обратный перенос -dsft нужен гораздо реже и требует более сильного обоснования. Файловые даты легко меняются при копировании и экспорте, поэтому они не являются автоматически более надёжным источником.

PNG и WebP: ограниченная совместимость новых сборок

Современное исходное дерево JHead расширило чтение и часть работы с EXIF на PNG и WebP, однако это не делает программу универсальным редактором этих форматов. Значительная часть команд, документации и многолетней практики JHead построена вокруг структуры JPEG. Кроме того, пакет в репозитории операционной системы может быть старше исходной ветки и вообще не знать о новых форматах.

Поэтому для PNG или WebP начните не с изменяющего ключа, а с трёх проверок: jhead -V, jhead -h и чтение одного тестового файла. Если программа не распознаёт контейнер или не показывает ожидаемый EXIF, не пытайтесь «додавить» операцию опциями от JPEG. Для сложной межформатной обработки лучше использовать инструмент, который заявляет этот контейнер и конкретные типы метаданных как основную область поддержки.

Даже если JHead читает EXIF из PNG/WebP, не следует автоматически применять к ним инструкции о JPEG-комментариях, jpegtran или «чистом JPEG». Название ключа и описываемая структура должны соответствовать формату. В сценариях смешанного каталога удобнее сначала разделить файлы по расширениям и выполнять только совместимые операции.

Автоматизация в скриптах

JHead хорошо подходит для сценариев, потому что каждая операция выражается короткой командой и не требует взаимодействия с окном. Однако надёжность автоматизации определяется не только JHead, но и оболочкой: кавычками, масками, кодировкой имён, обработкой ошибок и тем, как формируется список файлов.

Сначала получить данные, потом менять

В Bash можно сначала сохранить компактный отчёт, затем отдельно запускать изменения:

jhead -c *.jpg > before.txt
jhead -ta+0:03:12 *.jpg
jhead -c *.jpg > after.txt

Такой «до/после» не является резервной копией EXIF, но позволяет быстро заметить массовое смещение не в ту сторону. Для критичных архивов резервная копия самих файлов всё равно обязательна.

Тихий режим

-q уменьшает обычный вывод при успешной обработке. Это удобно в автоматических заданиях, где лог должен содержать в основном ошибки. На этапе настройки лучше оставить стандартные сообщения: они показывают, какие файлы действительно были затронуты. Тихий режим включают после проверки сценария, а не вместо неё.

Имена с пробелами

Если список файлов строится внешней командой, избегайте схем, где имена делятся простым пробелом. Фотокаталоги часто содержат пробелы, скобки и национальные символы. На Unix используйте механизмы безопасной передачи имён, поддерживающие нулевой разделитель или корректное quoting; в PowerShell работайте с объектами файлов и передавайте путь как отдельный аргумент. Главная цель — не позволить оболочке превратить один путь в несколько параметров.

Не полагаться на случайный порядок

При переименовании с последовательным номером важно понимать порядок, в котором файлы подаются программе. Оболочка, файловая система и рекурсивный обход могут давать не тот порядок, который пользователь считает «очевидным». Если последовательность критична, сформируйте и проверьте список явно либо используйте дату/время в имени как основной устойчивый ключ.

Производительность на больших каталогах

JHead специально невелик и при обычном чтении метаданных не декодирует весь снимок как фоторедактор. Поэтому перечисление EXIF и простые изменения заголовка обычно ограничены скоростью доступа к файлам и количеством объектов, а не тяжёлой обработкой пикселей. При этом корректно сравнивать производительность только на конкретном носителе и наборе данных: тысячи маленьких файлов на сетевом диске ведут себя иначе, чем несколько сотен больших JPEG на локальном SSD.

Операции с внешними программами имеют другой профиль. -autorot запускает jpegtran и затрагивает данные изображения, а -rgt использует ImageMagick для создания миниатюры. Здесь время определяется уже не только парсингом EXIF. В массовом сценарии затраты на запуск внешнего процесса для каждого файла могут быть заметнее, чем собственная работа JHead.

Не стоит ускорять обработку слепым запуском множества параллельных экземпляров. Запись в один каталог, вращение больших JPEG и работа на HDD могут упереться в ввод-вывод, а параллелизм только ухудшит ситуацию. Если требуется масштабирование, сначала измерьте последовательный сценарий на копии реального набора и следите за диском, а не придумывайте универсальное число потоков.

Для чтения огромного архива можно уменьшить объём вывода с -c либо использовать фильтры -model и -exonly, чтобы не выполнять лишнюю обработку. Для изменений гораздо важнее правильно сузить набор, чем выиграть несколько процентов времени ценой риска затронуть ненужные файлы.

Типичные ошибки и способы исправления

JHead не показывает параметры камеры

Первое объяснение — в файле нет EXIF. Это обычная ситуация после публикации в соцсети, скриншота, экспорта с очисткой метаданных или повторного сохранения некоторыми редакторами. Проверьте другой оригинальный кадр с камеры. Если EXIF отсутствует, JHead не сможет восстановить выдержку, ISO или модель из пикселей.

Дата выглядит как время копирования

Убедитесь, что вы смотрите на Date/Time, а не File date. Если EXIF-даты нет, некоторые операции переименования могут опереться на файловый timestamp. Для архива после переноса это может дать неверную хронологию. Не переносите File date в EXIF через -dsft, пока не подтвердили происхождение метки.

После -autorot ничего не происходит

Возможны три причины: Orientation уже нормальный; jpegtran не найден; или конкретная сборка/файл не подходит для операции. Сначала прочитайте Orientation, затем вызовите jpegtran отдельно или проверьте его доступность из той же оболочки. Если файл уже физически повернут и тег неверен, нужен -norot, а не повторное вращение.

После удаления EXIF картинка стала отображаться боком

Пиксели были записаны в исходной ориентации, а правильный показ обеспечивал EXIF Orientation. Удаление секции убрало подсказку. На исходной копии сначала выполните автоповорот, проверьте геометрию и только потом удаляйте EXIF.

-rgt не создаёт новую миниатюру

Проверьте две вещи: доступна ли команда ImageMagick magick и содержит ли исходный EXIF структуру миниатюры, с которой работает этот режим. -rgt не следует считать универсальным генератором EXIF с нуля. Для файла без EXIF сначала определите, вообще нужна ли встроенная миниатюра потребителю.

Шаблон -n работает в консоли, но ломается в .bat

Причина часто в процентах: cmd-файл обрабатывает % как собственный синтаксис. Удвойте проценты в шаблоне batch-файла. Одновременно избегайте двоеточий в будущих именах Windows-файлов и проверяйте кавычки вокруг путей с пробелами.

Одинаковые кадры получают конфликтующие имена

Секундной точности недостаточно для серийной съёмки. Добавьте %i или часть исходного имени %f. Не полагайтесь только на автоматически добавляемый суффикс, если схема имён должна быть понятна другим программам или пользователям.

Появляются сообщения о повреждённом EXIF

-se может скрыть часть диагностических сообщений, но не исправляет данные. Для ценного файла сначала сделайте копию и сравните чтение ExifTool или Exiv2. Если структура нестандартна, отказ от записи безопаснее, чем принудительная массовая модификация.

Команда из старой инструкции неизвестна

В интернете много руководств для прежних веток JHead. В них встречаются ключи для переноса заголовков, запуска внешних команд, фильтрации по качеству и ориентации, которые могли быть изменены или удалены в новых исходниках. Источником истины для установленной копии служат jhead -V и jhead -h. Если сценарий зависит от старого ключа, либо используйте соответствующую версию осознанно, либо перенесите задачу на ExifTool/Exiv2.

Ограничения, которые важно учитывать

Первое ограничение — JHead не является общим редактором произвольных EXIF-тегов. Его внутреннее представление ориентировано на конкретные операции, а добавление новых полей сильно ограничено. Если требуется записывать авторские, GPS, объективные, пользовательские или XMP-теги по имени, нужен более универсальный инструмент.

Второе — значительная часть сильных функций завязана на JPEG. Даже при наличии ограниченной поддержки EXIF в PNG/WebP новые контейнеры не получают автоматически весь набор JPEG-операций. Особенности JPEG-комментариев, jpegtran и «purejpg» нельзя переносить на другой формат по аналогии.

Третье — внешние зависимости для некоторых действий. Автоповорот требует jpegtran, регенерация миниатюр — ImageMagick. JHead может быть установлен и отлично читать EXIF, но эти конкретные операции не заработают, пока вспомогательная программа не доступна.

Четвёртое — отсутствует графический предпросмотр. Это плюс для автоматизации и минус для пользователя, которому нужно визуально выбирать кадры, сравнивать до/после и править отдельные поля формой. Ошибка в маске или параметре не будет остановлена диалогом подтверждения.

Пятое — точность результата зависит от исходных метаданных. Камера или редактор могут записать некорректный размер сенсора, ориентацию или время. JHead умеет интерпретировать известные поля, но не может знать, что часы камеры были неверны, пока пользователь не задаст правильную поправку.

Наконец, после внешних геометрических преобразований часть EXIF-полей может не соответствовать фактическому изображению. Если метаданные используются в научном, юридическом или производственном процессе, результат следует валидировать инструментом, который позволяет адресно проверить требуемые теги.

Сравнение с аналогами

JHead, ФотоМАСТЕР, ExifTool и Exiv2 пересекаются только частью функций, поэтому сравнивать их корректнее по конкретной задаче. ФотоМАСТЕР — визуальный фоторедактор: он умеет корректировать изображение, ретушировать портреты, работать с RAW, пакетно менять размер и добавлять водяные знаки. В информации о фото можно посмотреть технические параметры, а при сохранении JPEG доступно удаление метаданных и отдельно GPS. Однако это не консольный редактор произвольных EXIF-полей.

ExifTool — гораздо более широкий метаданный инструмент. Он читает и записывает большое число форматов и систем тегов, умеет адресно копировать поля между файлами, работать с XMP/IPTC/EXIF и выводить структурированные данные. Цена универсальности — более объёмный синтаксис и значительно больше вариантов одной и той же операции. Для сложной метадатной миграции это преимущество; для простого «сдвинуть часы JPEG на два часа» JHead часто выражает задачу короче.

Exiv2 совмещает командную утилиту и библиотеку C++. Он рассчитан на работу с EXIF, IPTC, XMP и ICC в разных форматах, умеет изменять отдельные теги, извлекать и вставлять метаданные и превью. Его выбирают, когда нужна программная интеграция в C++ или более адресное управление полями, чем предлагает JHead.

Если задача состоит в визуальном улучшении снимка и параллельной очистке метаданных перед публикацией, ФотоМАСТЕР решает её в одном графическом процессе. Если нужно массово менять конкретные теги, переносить метаданные между разными форматами или строить сложный конвейер, ExifTool или Exiv2 дают больше контроля. JHead рационален там, где набор действий невелик и повторяется на JPEG: посмотреть EXIF, поправить часы, переименовать по дате, нормализовать Orientation, управлять EXIF-миниатюрой или удалить служебные секции.

Как выбрать инструмент для конкретной операции

Для просмотра одного JPEG JHead удобен тем, что команда и вывод короткие. Для криминалистического или исследовательского анализа, где нужно увидеть неизвестные теги и вложенные структуры, лучше дополнить его ExifTool. JHead показывает полезную сводку, но не претендует на исчерпывающую расшифровку всех метаданных.

Для исправления часов камеры JHead особенно силён, когда ошибка постоянна. -ta выражает сдвиг непосредственно и сохраняет относительную хронологию. ExifTool способен на более сложные вычисления и выбор тегов, но синтаксис будет объёмнее. Графический фоторедактор имеет смысл, если одновременно нужна визуальная правка, а не только timestamp.

Для конфиденциальности сначала сформулируйте, что именно нужно убрать. «Все EXIF» — хороший сценарий для -de. «Только GPS, но оставить параметры камеры» — задача для адресного редактора тегов или функции экспорта, умеющей отдельное удаление геоданных. «Убрать вообще все несущественные служебные блоки JPEG» — более радикальный сценарий -purejpg, который нельзя применять к архивному оригиналу без копии.

Для автоматизации в программе на C++ Exiv2 привлекателен наличием библиотеки. Для разнородного медиаархива с множеством контейнеров ExifTool обычно удобнее благодаря широкой поддержке. Для небольшого shell-скрипта вокруг JPEG JHead сохраняет преимущество минимального набора команд.

Совместимость старых инструкций с текущими сборками

JHead существует давно, поэтому поисковая выдача часто приводит к руководствам для выпусков, где присутствовали дополнительные ключи. Например, старые документы описывают перенос EXIF-заголовка между файлами, запуск произвольной внешней команды с последующим возвратом метаданных, фильтры качества и ориентации. В актуальном исходном дереве часть прежних возможностей была убрана или переработана.

Из этого следует практическое правило: не включайте неизвестный ключ в массовый скрипт только потому, что он встречается в старом man page. Сначала посмотрите jhead -h на целевой машине. Если опция отсутствует, сценарий нужно переписать, а не подбирать похожее имя наугад.

Обратная ситуация тоже возможна: пакетный менеджер поставляет стабильную сборку, которая старше текущих исходников. Тогда свежая документация может упоминать PNG/WebP или изменённые зависимости, которых в установленном бинарнике нет. Номер версии здесь важен не сам по себе, а как индикатор фактически доступного синтаксиса.

Для инфраструктурного скрипта разумно фиксировать ожидаемые возможности при развёртывании: проверить -V, сохранить вывод -h рядом с документацией проекта и тестировать ключевую операцию на эталонном JPEG. Это предотвращает неожиданное изменение поведения после обновления системы.

Разбор основных параметров JHead

Контроль результата после изменения

Проверка должна соответствовать операции. После коррекции времени достаточно прочитать Date/Time на нескольких файлах и убедиться в правильном порядке. После переименования следует дополнительно посмотреть коллизии и соответствие имени EXIF-дате. После автоповорота нужна визуальная проверка в просмотрщике и чтение Orientation. После удаления секций нужен повторный анализ метаданных.

Для критичных задач полезен второй инструмент. Это не признак недоверия к JHead, а обычная валидация: разные программы по-разному показывают неизвестные теги и контейнеры. Например, после удаления EXIF можно проверить, не остались ли координаты или идентификаторы в XMP. После изменения времени — убедиться, что каталогизатор сортирует по тому тегу, который вы действительно исправили.

Сохраняйте оригиналы до окончания проверки всего конвейера. Визуальная неизменность JPEG не означает, что потерянные метаданные легко вернуть. Удалённый EXIF нельзя восстановить из изображения, если отдельной копии заголовка или исходного файла нет.

Что JHead не делает

JHead не проявляет RAW, не исправляет экспозицию, не меняет баланс белого в пикселях, не удаляет шум, не повышает резкость и не выполняет ретушь. Параметр Whitebalance в выводе — это прочитанная метаинформация о режиме камеры, а не регулятор цветовой температуры изображения.

Программа не предоставляет визуального редактора карты для GPS. Она может показывать координаты, если они присутствуют, но точечная работа с геотегами — не её сильная сторона. Для добавления, переноса или выборочного удаления GPS лучше использовать метаданный инструмент с адресной записью тегов или специализированный геотеггер.

JHead не является универсальным конвертером изображений. Внешний jpegtran используется для специального поворота JPEG, ImageMagick — для генерации миниатюры, но это не превращает сам JHead в редактор формата и размера изображения. Если нужно массово масштабировать фотографии, логичнее вызвать ImageMagick напрямую и отдельно решить, какие метаданные сохранять.

Наконец, JHead не гарантирует, что метаданные камеры истинны. Он читает то, что записано в файле. Ошибочная дата, неверный сенсорный параметр после сторонней обработки или странное значение фокусного расстояния требуют понимания происхождения файла, а не только другого ключа командной строки.

Как отличать EXIF-время от времени файловой системы

В фотоархиве часто одновременно существуют несколько временных шкал. Камера записывает время съёмки в EXIF; файловая система хранит собственные даты; редактор может создать новый файл и присвоить ему момент экспорта; облачный сервис способен скачать копию с новой датой изменения. JHead показывает часть этих значений рядом, поэтому важно не считать их взаимозаменяемыми.

DateTimeOriginal обычно является главным ориентиром для хронологии фотографий. Именно на него рассчитаны типовые операции переименования и коррекции времени JHead. Но сам формат EXIF исторически не гарантирует наличие полноценной информации о часовом поясе рядом с каждым старым timestamp. Поэтому строка вроде 2024:07:18 20:15:03 без дополнительного контекста не отвечает на вопрос, было ли это местное время Парижа, Токио или часы камеры, оставшиеся в домашнем поясе.

Файловый timestamp отвечает на другой вопрос: когда объект был изменён или создан в представлении конкретной файловой системы. Он может совпасть с временем съёмки, если камера и процесс копирования его сохранили, но такое совпадение нельзя предполагать. Команды -ft и -dsft специально существуют для синхронизации этих двух миров, а значит JHead сам рассматривает их как разные источники.

При разборе старого архива полезно составить приоритет источников. Например: исходный EXIF с камеры — основной; журнал поездки — внешний контроль; файловая дата — только резервный источник для кадров без EXIF. Для сканов приоритет может быть противоположным, если дата заранее выставлена вручную. Главное — не смешивать разные правила в одной массовой операции.

Часовой пояс и переходы времени

-ta выполняет арифметический сдвиг записанного времени. Он не знает, почему возникла разница и не определяет автоматически географический часовой пояс. Если поездка проходила через несколько зон, а часы камеры менялись в пути, каталог нужно разделить на логические участки. Аналогично, переход на летнее или зимнее время нельзя исправлять одной глобальной поправкой, если серия пересекает момент перевода часов.

GPS тоже не следует использовать как автоматическое доказательство локального времени без дополнительной логики. Координаты помогают определить место, но связь с часовым поясом и историческим правилом перехода времени находится за пределами обычных операций JHead. Если требуется полноценная нормализация по географии, лучше сначала вычислить целевые timestamps отдельным инструментом, а затем применять изменения адресно.

Порядок операций: какие команды зависят друг от друга

В JHead отдельные действия выглядят независимыми, но в реальном рабочем процессе между ними есть зависимости. Самая очевидная — переименование по времени должно выполняться после исправления времени. Иначе имя будет отражать старую дату, а EXIF — уже новую, что создаст два разных источника хронологии.

Другой важный случай — -purejpg. Его логично оставлять на самом конце публикационного конвейера, потому что после радикальной очистки метаданные уже нельзя использовать для переименования, коррекции времени или диагностики ориентации. В архивном конвейере этот ключ обычно вообще не нужен: оригинальные служебные данные ценнее небольшого упрощения структуры.

Такая последовательность не является обязательным «мастером» JHead — программа не навязывает порядок. Это именно инженерная зависимость данных. Поле должно существовать в тот момент, когда следующий шаг использует его как источник.

Безопасные шаблоны переименования

Переименование кажется простой косметической операцией, но именно оно чаще всего связывает метаданные с внешней организацией архива. Хороший шаблон должен сортироваться лексикографически, быть допустимым в нужных файловых системах и не создавать коллизии при серийной съёмке.

Форма %Y-%m-%d_%H-%M-%S удобна тем, что год идёт первым, а разделители безопасны для Windows, Linux и macOS. Двоеточие красиво выглядит как время, но недопустимо в обычных именах Windows, поэтому его лучше не использовать, если каталог переносится между платформами. Пробелы допустимы, но увеличивают требования к quoting в скриптах.

Если камера способна делать несколько кадров в секунду, точности %S недостаточно. JHead может разрешать конфликт суффиксом, но для долговременного архива лучше сделать источник уникальности явным. Один вариант — добавить %i, другой — включить %f, сохранив оригинальный счётчик камеры. Второй способ полезен, если фотограф привык искать номер кадра по журналу съёмки.

Перед переименованием нескольких камер следует проверить, не совпадают ли их timestamps полностью. Две камеры могут снять один момент в одну секунду, и одинаковая схема имён столкнётся даже при исправных часах. Сохранение фрагмента исходного имени или отдельного префикса для камеры делает схему устойчивее.

Что делать с файлами без EXIF

Если каталог содержит смешанные данные, разумно сначала запустить -exonly и переименовать только файлы с EXIF. Остальные можно обработать отдельным правилом после проверки файловой даты. Так отсутствие EXIF не будет незаметно подменено другой временной шкалой.

Для архивов со сканами полезно вообще отделить их от камерных JPEG. У скана «время создания файла» и «дата изображённого события» — разные понятия, и автоматическое формирование имени по техническому timestamp может создать ложную хронологию.

Проверка коллизий до массовой записи

У JHead нет отдельного режима dry-run для каждого преобразования имён. Практический заменитель — тестовая копия выборки. Возьмите кадры с границы суток, серийную последовательность и файлы двух камер. Если шаблон сохраняет порядок и уникальность на этих сложных случаях, вероятность проблем на основной серии существенно ниже.

Удаление метаданных: что именно остаётся

Служебные данные JPEG состоят не из одного монолитного «EXIF». Поэтому команда очистки должна соответствовать модели угроз или редакционной задаче. -de удаляет EXIF, но не означает автоматически удаление XMP, IPTC и JPEG-комментария. -di и -dx адресуют другие секции. -dc работает с отдельным JPEG Comment.

Это различие особенно важно для авторских полей. Камера может записывать GPS в EXIF, редакционная система — подпись и автора в IPTC, а фоторедактор — историю или дополнительные свойства в XMP. Если очистить только EXIF, координаты из стандартного EXIF исчезнут, но другая чувствительная информация в XMP может остаться.

С другой стороны, бездумное удаление всех секций тоже не всегда правильно. Для редакционного архива IPTC-подпись и авторство могут быть полезнее камерной диагностики. Для публичной публикации может быть допустимым сохранить авторство, но удалить геолокацию. JHead хорошо подходит к сценарию удаления секций целиком, но не к тонкой политике «оставить десять тегов, удалить три».

Почему -purejpg нужно применять осознанно

-purejpg предназначен для удаления не нужных самому декодированию изображения данных. Это удобно, когда нужен максимально «чистый» JPEG для публикации или теста совместимости, но такой файл перестаёт быть полноценным носителем исходных метаданных. В архиве фотографа EXIF, комментарии и редакционные поля могут иметь ценность, даже если на экране пиксели выглядят одинаково.

Поэтому публикационная очистка должна выполняться на копии после экспорта. Архивный оригинал хранится отдельно, а очищенная версия проверяется на отсутствие нужных секций. В таком процессе необратимость JHead перестаёт быть риском: исходник остаётся доступным.

Работа с повреждёнными и необычными EXIF-заголовками

Файлы после старых редакторов, камерных прошивок и многократного копирования иногда содержат EXIF, который формально нарушает ожидаемую структуру. JHead может вывести предупреждения, частично прочитать данные или отказаться от конкретной операции. Такие сообщения не стоит автоматически подавлять, особенно перед массовой записью.

-exifmap помогает увидеть расположение элементов заголовка на уровне байтов. Обычному фотографу этот вывод мало полезен, но для разработчика или администратора он позволяет сравнить проблемный файл с нормальным образцом той же камеры. -v также даёт больше диагностической информации, чем стандартная сводка.

-se нужен в другой ситуации: когда скрипт обходит большую коллекцию и известные некритичные предупреждения делают журнал нечитаемым. Он не делает повреждённый файл корректным и не должен скрывать проблему на этапе расследования. Сначала выясняется причина, потом при необходимости уменьшается шум.

Когда лучше не писать файл

Если JHead и второй инструмент по-разному интерпретируют EXIF, если исходный JPEG открывается не во всех просмотрщиках или если метаданные имеют юридическую/научную ценность, безопаснее ограничиться чтением копии. Исправление структуры специализированным редактором следует отделить от обычных пакетных операций.

Также стоит отказаться от записи, если единственный исходник находится на нестабильном носителе или в каталоге синхронизации, где параллельно работает другая программа. Сначала скопируйте файл на локальный рабочий диск, проверьте контрольную копию и только затем модифицируйте метаданные.

JHead в Bash, PowerShell и cmd

Сам JHead кроссплатформенно сохраняет идею «опции + файлы», но оболочки по-разному обрабатывают маски и специальные символы. Поэтому практический скрипт должен быть написан под конкретную среду, а не просто перенесён построчно.

Bash и другие Unix-оболочки

Звёздочку обычно раскрывает оболочка. Команда jhead -ft *.jpg получает уже готовый список имён, подходящих под маску. Если в каталоге расширения записаны как .JPG, маска в регистрозависимой системе их не захватит. Можно обработать обе формы отдельно или построить список через find.

При рекурсивном обходе нужно корректно передавать имена с пробелами и переводами строк. Простая конструкция «for по выводу ls» для этого ненадёжна. Предпочтительнее механизмы оболочки, которые работают с аргументами как с отдельными строками, либо find с безопасной передачей найденного пути.

PowerShell

PowerShell удобен тем, что файлы можно сначала отфильтровать как объекты, проверить их свойства и только затем передать пути внешней программе. Это полезно для сложной выборки: например, ограничить каталог и расширение до запуска JHead. Но каждое значение пути всё равно должно попасть к программе отдельным корректно процитированным аргументом.

Не следует автоматически переносить синтаксис bash-подстановок в PowerShell. Если нужен рекурсивный обход, лучше построить список средствами PowerShell, а JHead оставить узкую роль обработки каждого найденного JPEG.

Классический cmd и batch-файлы

Главная ловушка — символ процента в шаблонах -n. В интерактивной строке спецификатор времени выглядит как %Y, а в batch-файле процент участвует в подстановках самой оболочки, поэтому обычно пишется как %%Y. Проверяйте также кавычки вокруг путей с пробелами и используйте имена без запрещённых Windows-символов.

Если команда должна работать на нескольких платформах, полезнее иметь маленькие оболочечные адаптеры для каждой системы, чем одну строку с множеством условных экранирований. Само ядро операции JHead при этом остаётся одинаковым.

Проверка после стороннего фоторедактора

Экспорт из графического редактора может изменить не только пиксели, но и структуру метаданных. Одни программы копируют EXIF целиком, другие оставляют только часть, третьи создают XMP или меняют файловую дату. JHead удобен как быстрый контроль результата до массовой публикации.

Сравните оригинал и экспорт обычным выводом. Обратите внимание на Date/Time, Orientation, размеры, модель камеры и GPS. Если редактор физически повернул изображение, но сохранил старый Orientation, это может объяснить двойной поворот в другой программе. Если экспорт удалил EXIF, переименование по DateTimeOriginal после экспорта уже будет ненадёжным.

Для цепочки «редактор → оптимизатор → загрузка на сайт» лучше определить момент, когда метаданные ещё должны существовать. Например, переименование и архивная сортировка выполняются до публикационной очистки. После удаления EXIF файл считается конечной веб-копией и не используется как источник для восстановления каталога.

Встроенная миниатюра после редактирования

Некоторые редакторы меняют основное изображение, но сохраняют старое превью внутри EXIF. JHead позволяет извлечь его через -st и проверить. Если миниатюра устарела, её можно удалить либо пересоздать. Это особенно актуально, когда в файловом менеджере кратко появляется исходная версия до загрузки полного кадра.

Как документировать пакетное изменение архива

Для личной папки из двадцати снимков достаточно резервной копии. Для редакционного или корпоративного архива полезен журнал операции. В нём не обязательно хранить каждый байт EXIF; достаточно зафиксировать дату обработки, команду, критерий выбора файлов, источник правильного времени и место резервной копии.

Перед изменением можно сохранить компактный вывод -c для выбранной серии. После операции — второй файл отчёта. Разница между ними помогает подтвердить, что поменялось именно ожидаемое поле. Для переименования дополнительно полезен список старых и новых имён, который генерируется оболочкой или системой контроля файлов.

Если используется -model, в журнале следует записать фактическую строку модели, по которой выполнялся фильтр. Если применялась временная поправка, записывается её происхождение: «камера отставала на 3 минуты 12 секунд относительно синхронного кадра телефона», а не только команда. Такой контекст позволяет через годы понять, почему метаданные отличаются от оригинала.

Архивная дисциплина особенно нужна для -de, -dx, -di и -purejpg: удалённая секция не восстанавливается из пикселей. Если исходник остаётся неизменным, операция безопасно повторяема; если нет — журнал не заменяет резервную копию.

Когда JHead удобнее ExifTool, а когда уступает ему

Оба инструмента могут участвовать в обработке EXIF, но подход различается. JHead предоставляет специализированные действия с понятными ключами: сдвинуть время, переименовать по дате, удалить EXIF, повернуть JPEG по Orientation, извлечь миниатюру. Для пользователя, который делает только эти операции на JPEG, короткий словарь команд снижает сложность сценария.

ExifTool выигрывает, когда задача формулируется на уровне конкретных тегов и разных контейнеров. Например, «скопировать только Copyright и Artist, удалить GPS, сохранить DateTimeOriginal, вывести результат в JSON» — естественная задача для ExifTool, но не для JHead. Попытка собрать её только из секционных операций JHead либо невозможна, либо слишком груба.

Разница особенно заметна в автоматизации. JHead прост, когда заранее известна одна операция. ExifTool удобнее, когда правила зависят от наличия тегов, требуется условная логика или сохранение сложной структуры метаданных. Поэтому эти программы не обязательно конкурируют: JHead может быть быстрым узким инструментом в JPEG-процессе, а ExifTool — общим метаданным слоем.

Когда JHead удобнее Exiv2, а когда нужен Exiv2

Exiv2 предоставляет CLI и библиотеку для разработчиков. Если метаданные нужно обрабатывать внутри собственного C++-приложения, библиотечный интерфейс — принципиальное преимущество. JHead в основном используется как отдельная команда и не строится вокруг публичного API для интеграции.

Для пользователя терминала Exiv2 также гибче в адресном чтении и записи отдельных EXIF/IPTC/XMP-тегов. JHead проще, когда нужно воспользоваться одной из его готовых операций. Выбор определяется не количеством функций, а тем, совпадает ли конкретная задача с теми действиями, которые JHead реализует напрямую.

Когда ФотоМАСТЕР решает другую часть задачи

ФотоМАСТЕР нужен там, где результат оценивается глазами: исправить свет и цвет, ретушировать портрет, удалить объект, заменить фон, применить эффект, кадрировать или подготовить изображение к печати. JHead ничего из этого не делает. Он может сообщить выдержку или ISO, но не меняет внешний вид кадра на основе этих данных.

Пересечение появляется при публикации. В ФотоМАСТЕРе пользователь может визуально отредактировать фото, а при сохранении JPEG удалить метаданные и отдельно GPS. JHead может выполнить очистку секций без визуального редактирования и встроиться в скрипт. Если нужно точечно удалить только геолокацию, сохранив прочий EXIF, возможность отдельного удаления GPS при экспорте в фоторедакторе практичнее, чем грубое -de.

Пакетная обработка тоже различается по смыслу. ФотоМАСТЕР пакетно применяет визуальные операции вроде изменения размера и водяного знака; JHead пакетно меняет служебные данные и имена. Эти задачи могут идти последовательно в одном процессе, но одна программа не заменяет другую.

Проверочный набор перед внедрением JHead в процесс

Если JHead планируется использовать регулярно, стоит подготовить небольшой набор эталонных файлов. В него полезно включить JPEG с обычным EXIF, файл с GPS, портретный кадр с Orientation, JPEG после фоторедактора, файл без EXIF и снимок с встроенной миниатюрой. На таком наборе быстро проверяется новая версия или изменение скрипта.

Для каждой операции заранее известно ожидаемое состояние. После -ta меняется время на заданный интервал; после -autorot изображение ориентировано физически и тег нормализован; после -de EXIF отсутствует; после -dt EXIF остаётся, но встроенной миниатюры нет. Это превращает ручную проверку в небольшой регрессионный тест.

Особенно полезен такой набор на рабочих станциях с разными ОС. Он выявляет разницу не столько в JHead, сколько в оболочке, путях к jpegtran/ImageMagick, обработке процентов и масок. Прежде чем запускать команду на общем сетевом архиве, лучше обнаружить эти различия на шести тестовых файлах.

Диагностика ориентации без визуальных догадок

Проблемы с Orientation часто проявляются только после переноса в другую программу. Один просмотрщик автоматически учитывает тег, другой показывает физическое расположение пикселей, третий при экспорте запекает поворот и оставляет старые метаданные. Поэтому надёжная диагностика состоит из двух независимых проверок: что записано в EXIF и как реально расположены пиксели.

Сначала прочитайте файл JHead и зафиксируйте Orientation. Затем откройте копию в инструменте, где можно увидеть изображение без автоматического поворота, либо сравните ширину и высоту с ожидаемой ориентацией. Если пиксели «лежат», а тег правильно сообщает требуемый поворот, -autorot соответствует задаче. Если пиксели уже стоят правильно, а тег продолжает требовать вращение, нужен -norot.

После автоповорота проверьте не только основное изображение, но и встроенную миниатюру. JHead старается согласовать превью с поворотом, однако файлы после сторонних редакторов могут иметь нетипичную структуру. В спорном случае извлеките миниатюру через -st и сравните её. Если она не нужна, проще удалить её -dt, чем сохранять визуально противоречивую копию.

Не используйте удаление EXIF как способ «исправить поворот», пока не выяснена физическая ориентация. Удаление тега у файла, где пиксели не были повернуты, лишь делает ошибочное отображение постоянным для всех программ.

Миниатюры EXIF в архиве и публикационных копиях

Встроенное превью часто воспринимается как несущественная деталь, но оно имеет два практических эффекта. Во-первых, некоторые программы используют его для быстрого показа. Во-вторых, оно может сохранять старую версию изображения после кадрирования или ретуши. Для чувствительного контента это даже вопрос приватности: маленькая копия способна содержать область, которую пользователь уже обрезал в основном кадре.

Поэтому после сильного кадрирования старого JPEG полезно проверить -st. Если превью показывает исходную композицию, выберите один из двух вариантов: удалить его -dt или пересоздать -rgt. Регенерация имеет смысл, когда программа-потребитель реально использует embedded thumbnail; в обычной веб-публикации она часто не нужна.

-rt полезен в контролируемом процессе, где есть заранее подготовленное превью и существующая EXIF-структура. Он не предназначен для произвольного конструирования сложного EXIF-блока. Если нужно сформировать стандартизованные превью и одновременно записать множество тегов, JHead лучше заменить более универсальной метаданной библиотекой.

После любой работы с миниатюрой сравните размер основного JPEG и извлечённого превью. Не следует принимать встроенную картинку за «второй оригинал»: она обычно намного меньше и служит только для предварительного показа.

Разбор сценария с неверным годом камеры

Ошибочный год — более неприятная ситуация, чем постоянный часовой сдвиг. Если камера снимала весь отпуск в 2014 году, считая, что сейчас 2012-й, простая поправка в часах неудобна и хуже читается. Здесь полезнее календарный сдвиг -da, который выражает отношение между двумя датами и учитывает реальные месяцы и годы.

Начните с события, календарная дата которого известна точно. Убедитесь, что ошибка действительно одинаковая для всей серии и часы внутри дня идут правильно. Затем протестируйте перенос на кадрах возле конца месяца и, если диапазон проходит через февраль, возле соответствующей календарной границы. Такой тест нужен не потому, что JHead «не умеет календарь», а потому, что исходный набор может содержать ручные изменения часов или файлы из другой камеры.

После переноса дат сначала проверьте EXIF, затем переименование. Если старые имена уже содержат ошибочный год, не используйте их как контрольную точку. Надёжнее сравнить с независимым журналом события.

Разбор сценария с камерой, которая спешила на секунды

Для синхронизации двух камер на концерте, свадьбе или спортивном событии иногда важны не часы, а десятки секунд. JHead принимает секундную часть в -ta, поэтому можно скорректировать стабильное расхождение без округления до минуты.

Найдите несколько пар кадров одного события в начале и конце съёмки. Если разница одинакова, это постоянный offset и его можно исправить одной командой. Если расхождение постепенно растёт, часы одной камеры имеют дрейф; один линейный сдвиг исправит только выбранную точку. JHead не строит модель дрейфа, поэтому длительную серию придётся разделять на интервалы или использовать более сложный скрипт.

После секундной коррекции особенно полезна проверка по хронологической ленте: быстрые события должны чередоваться между камерами в физически правдоподобном порядке. Это практический контроль, который дополняет чтение цифр.

Границы автоматического анализа качества JPEG

Строка JPEG Quality полезна для быстрой оценки, но она не должна становиться основанием для безусловного решения «пересжать всё ниже этого числа». JHead вычисляет приблизительный коэффициент по таблицам квантования. Разные кодировщики могут использовать нестандартные таблицы, оптимизированные матрицы и настройки, которые не сводятся к одному универсальному ползунку.

Если цель — оценить, был ли файл повторно сжат, одного значения недостаточно. Сравнивайте размер, таблицы, визуальные артефакты и происхождение файла. Для архивного оригинала повторное сохранение только ради «нормального числа качества» не имеет смысла.

В старых версиях JHead встречались дополнительные фильтры и сценарии вокруг оценки качества. В актуальной работе не следует полагаться на них без проверки -h: документация разных выпусков расходится.

Как читать вывод JHead как техническую сводку

Поле Camera make сообщает производителя, Camera model — строку модели, записанную устройством. Эти значения полезны для -model, но не гарантируют уникальность физической камеры: две одинаковые камеры будут иметь одну и ту же модель. Для разделения конкретных корпусов понадобятся другие теги и более универсальный инструмент.

Focal length, Exposure time, Aperture и ISO equiv. — удобная человеческая сводка параметров съёмки. JHead нормализует вывод, но не заменяет полную расшифровку MakerNotes. Если производитель хранит специфические параметры в собственных тегах, они могут не попасть в краткий отчёт.

Поля GPS полезны как быстрый индикатор наличия координат. Но отсутствие понятных координат в кратком выводе не доказывает отсутствие геоданных вообще. Для проверки приватности нужен анализ всех секций и при необходимости ExifTool.

Resolution показывает фактические размеры JPEG, которые JHead извлекает из структуры изображения. Отдельные размерные теги внутри EXIF после внешней обработки могут расходиться с реальностью. Если приложение-потребитель опирается именно на EXIF-размеры, проверяйте их адресно.

Что проверить перед запуском на сетевом или облачном каталоге

Пакетная запись непосредственно в синхронизируемую папку может конфликтовать с облачным клиентом, антивирусом, индексатором или резервным копированием. JHead работает с файлами быстро, и десятки изменений подряд могут вызвать повторную загрузку всей серии. Для крупной коррекции практичнее сначала обработать локальную рабочую копию, проверить её и только потом синхронизировать результат.

На сетевом ресурсе важны права на запись и стабильность соединения. Чтение EXIF может пройти успешно, а массовая запись — оборваться в середине. Поэтому в журнале следует фиксировать, какие файлы уже обработаны, или разделять набор на небольшие партии. Не стоит считать частично завершённую команду «всё или ничего».

Если каталог одновременно индексируется фотоменеджером, после изменения EXIF ему может понадобиться повторное чтение метаданных. Иначе интерфейс программы будет показывать старые значения из базы, хотя сам JPEG уже изменён. Проверяйте результат непосредственно по файлу, а затем обновляйте каталог.

Контрольный список для массовой операции

• Проверить версию и доступные ключи через -V и -h.
• Сохранить оригиналы отдельно от рабочей копии.
• Прочитать несколько файлов до изменения.
• Убедиться, что маска не захватывает резервные и экспортные каталоги.
• Проверить регистр расширений и правила оболочки.
• Для -autorot проверить наличие jpegtran.
• Для -rgt проверить наличие ImageMagick.
• При коррекции времени подтвердить знак и величину смещения внешним источником.
• При переименовании проверить коллизии и допустимость символов.
• Перед удалением EXIF нормализовать Orientation, если он нужен для показа.
• После операции перечитать метаданные и открыть несколько изображений.
• Для конфиденциальной публикации проверить результат вторым инструментом.

Этот список не усложняет JHead, а компенсирует его сильную сторону — отсутствие интерактивных подтверждений. Чем шире маска, тем важнее предварительная проверка.

Рациональный рабочий процесс с JHead

Для повседневной работы полезно разделять оригиналы, рабочие копии и публикационные файлы. Оригиналы с карты памяти сохраняются неизменными. На рабочей копии исправляют время и ориентацию, приводят имена к выбранной схеме и проверяют миниатюры. Публикационная копия при необходимости очищается от EXIF/XMP/IPTC. Такое разделение позволяет одновременно сохранить доказуемое происхождение снимка и получить аккуратные файлы для сайта.

Если архив уже организован и менять имена рискованно, JHead можно использовать только для отчёта и точечной коррекции времени. Не обязательно применять все возможности программы к каждому набору. Хороший сценарий — минимальный набор операций, необходимый для конкретной проблемы.

Для повторяющейся работы запишите команды в скрипт только после ручной проверки на нескольких образцах. В комментарии к скрипту зафиксируйте, какой источник времени считается правильным, какой тип файлов ожидается и какие внешние зависимости нужны. Это важнее, чем запоминание синтаксиса: через полгода контекст операции обычно забывается раньше самой команды.

JHead особенно удобен как «точный инструмент»: он не скрывает пакетное действие за большим интерфейсом и не заставляет проходить через экспорт, когда нужно изменить только служебную часть JPEG. Но именно поэтому ответственность за выбор файлов, резервную копию и проверку результата остаётся у пользователя. При таком подходе программа надёжно закрывает свои основные задачи — чтение EXIF, коррекцию времени, организацию файлов, ориентацию и очистку метаданных — без лишнего преобразования изображения.