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

А вот, например, Adobe Bridge:

  1. Читает TIFF-файлы (ура).
  2. Умеет их повернуть (тоже неплохо). Делает это сменой тега Orientation.
  3. Но: если в файле содержится несколько изображений (т.е. image pyramid в терминах фотошопа), то Orientation меняется только у IFD0.
  4. При этом стандарт конечно умалчивает "как правильно поворачивать TIFF", но поскольку в IFD1..n прочие описания изображения (ну там размер, BitsPerSample, etc) описывают данное "под"-изображение, логично думать что и Orientation там верный (если этот тег есть, понятно что если его нет, то надо брать из IFD0).
  5. Но, сука, после бриджа - это не так.
  6. Причем, если поворот на 90/270 допустим можно детектировать (SubIFD не матчат IFD0 по width/height + поворот), то для 180 и/или зеркалирования это не так.
  7. Соответственно, если какое приложение (ну к примеру Windows Explorer) для построения превьюшки использует IFD отличное от 0, то поворот будет неверный.
  8. Ибо нехер, догадываться "какая программа так криво повернула TIFF" - невозможно.
  9. Доклад закончил.

UPD: Lightroom, если в ем повернуть TIFF, а затем 'Write metadata to file' делает полностью аналогично бриджу.

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

Вот еще например: в PNG-файлах может быть вложенный XMP-блок и вложенный EXIF-блок. И в каждом из них может быть свой тег Orientation. В общем случае он будет разный. Ну и вишенка: приложения пишут XMP до блока IDAT (с изображением) т.е. теоретически XMP:Orientation можно учесть. А вот EXIF-блок идет (везде где видел) после IDAT, что в сочетании с PNG-шным "читаем только вперед" автоматически означает, что EXIF:Orientation учесть никак нельзя (PNG сдизайнен так, что его можно начать показывать не скачав файл целиком, соответственно повернуть потом как-бы нельзя уже).

Comments

"Б-ди, Сэр!" (c)

Нет, просто ГОСТа нету!

мне ли тебе напоминать, насколько альтернативные читатели ГОСТов (contemporary: standards, BCPs, whatever, чорталысоговступе) заполоняют окружаюшчую среду!

Ну вот с метадатой у изображений творится какая-то полная чертовщина.

При этом с RAW еще кое-как (да и то, вот к примеру EXIF-block может быть в другом byte order, чем сам файл, причем никаких II*/MM* там нету и надо догадаться /что несложно, впрочем/).

Но RAW - это изображение "без истории", поэтому тамошняя метадата она на момент capture и более-менее однозначна (ну опять бывают приколы, но мы не о них).

А потом некто начинает редактировать, появляется история, а в ней артефакты:
1) метаданные - это ценность, их хорошо сохранять в исходном виде
2) за исключением, конечно, тех мест, которые мы при редактировании заменили (тот же тег Orientation)
3) а еще, мы собрали панораму (как пример) программой А, а редактируем программой Б и естественно Б про теги А ничего не знает и при всем желании не может привести их в соответствие, даже если мы предпочитаем вариант 2) а не 1)

Ну и на это всякое другое накладывается тоже. Чтобы обновить метадату - файл надо бы переписать целиком. Многогигабайтный на USB2-connected drive, причем USB оный временами отваливается т.к. контакт плохой.

Ну и да, мы имеем в одном файле EXIF, XMP, IPTC, поправили к примеру поле Author (Artist), но наш софт был не IPTC-Aware, поэтому поправили только в двух местах.

А при коммунизме будет ГОСТ,
Он наступит скоро — надо только подождать

Это всё от гибкости. Вот зачем PNG вообще разрешает не-родную метадату? Было бы нельзя — не было бы путаницы.

А что такое "не родная метадата"?
Вот открыли мы RAW, сохраняем в формат.... ну скажем JPEG. Мы EXIF должны скопировать целиком, как оно было, или должны подредактировать в силу криворукости разработчиков сохраняющей программы?

Вот к примеру Adobe XMP SDK, когда добавляет XMP-блок к JPEG, оно, найдя в этом JPEG блок с EXIF - его редактирует, причем от души.
Хорошо ли это?

Ну то есть хорошего решения нет, все решения что я могу представить - имеют свои недостатки.

Ну, вот есть single source of truth по формату. Там прописано всё, что может быть в файле такого формата. Это всё — родное. Остальное — не соотвествует формату и вообще не обязано поддерживаться ничем.

Когда нет single source of truth — ну вот такое и получается.

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

Вопрос о копировании EXIF из RAW в JPEG вообще не имеет смысла в идеальном мире и не имеет правильного ответа в мире реальном, увы. О чём ты, собственно, и пишешь.

Ну вот смотри, вот есть EXIF, который вот даже пишет какой-то там комитет (не знаю кто) и даже развивает потихоньку.

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

Что делать?

А в EXIF нет private space?
Это во-первых.
Во-вторых, какая камера?! Это в RAW надо записать прямо вот сейчас? Ну так у тебя RAW, туда и пиши, всё, что не обще-человеческое! :-) Свой RAW-то контролируешь.

Правильно, в RAW записал свое.

Дальше из RAW сделали DNG, оно должно пойти в комплект с ним? Очевидно, да (архивный же формат!).
Дальше - индукция.

Если этот формат архивный, то мы его после не трогаем. И тогда тоже нет проблем «разъехалось». Не так ли? ;-)

В примере с XMP SDK — плох сам факт возможности двух комплектов метадаты. Adobe вместо того что бы официпально через тот комитет, что сделал EXIF, провести собственные нужные им теги, которых им не хватало, ляпнуло XMP. Ну девочка, ну ё…

Всё, после этого не имеет смысла говорить про хорошо или плохо.

По хорошему — XMP SDK в такой ситуации должно делать JPEG/XMP и удалять весь EXIF. Скопировав данные оттуда к себе. Или делать какой PDF контейнер, whatever. Но не лепить две (сильно перекрывающиеся) метадаты рядом.

Ну то есть если мы хотим выпустить ACR 10.0 (параметры обработки пишутся в XMP) - мы должны его сначала провести через комитет по стандартам (EXIF), а потом уже выпускать?

Так тоже не работает. По многим причинам.

Мы не должны допускать технической возможности дублирования метаданных. Этого можно достигнуть многими способами. Не вносить в свой формат то, что есть в EXIF. Не сосуществовать с EXIF. Чётко прописать приоритет в своём, более новом (!) формате, раз не можешь поправить не-свой старый.

Ну как так "не сосуществовать с EXIF", когда есть куча программ (к примеру) читающих EXIF, но не XMP?

Ну вот так. Adobe точно может себе позволить :-)

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

Ну а TIFF, увы, помойка, как и JPEG :-(

JPEG никакая не помойка, я бы попросил!

Как раз на JPEG/EXIF есть даже человеческий стандарт.

Там может быть JPEG/EXIF, JPEG/JIFI, всё тоже с и без IPCT и XMP ещё прямо внутри или рядом. Это — помойка.
Вообще, любой расширяемый более чем одним актором формат/стандарт становится помойкой.

Это не помойка, а APP-сегменты, я бы попросил!
Проблема же в том, что метадата то нужна, причем разных видов, в частности
- параметры съемки
- введенные пользователем данные

А вторая проблема в том, что если одно и то же может быть описано в разных блоках метаданных и это "одно и то же" влияет на показ - то нет приоритетов.

И их не может быть, EXIF - один стандарт, IPTC - другой, XMP - третий.

Нужен ГОСТ на метаданные, да!

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

И в стандарте не написано: «Complaint reader MUST [as in RFC2119] reject files which contains additional or custom bytes not described in this format». «Writer MUST NOT [as in RFC2119] write bytes not described in this standard to be complaint»

Индустрия не может ждать "когда же EXIF-комитет стандартизует параметры стабилизатора матрицы" и только после этого выпускать камеры со стабом.

Ну то есть теоретически может, а практически - тот кто не будет этого делать и выпустит камеру со стабом не дожидаясь для нее стандартного EXIF - тот и выиграет рынок.

К софту это тоже относится: допустим мы хотим параметры процессинга RAW писать в результирующий TIFF (есть масса причин почему это хорошо). И тормозить новую версию конвертора до стандартизации процесса обработки - никто по очевидным причинам не будет.

И в чём тут проблема?

If one needs more than 10 tags or so, the TIFF specification suggests that, rather than using a large amount of private tags, one should instead allocate a single private tag, define it as datatype IFD, and use it to point to a so-called 'private IFD'.

Вот в этом и проблема. Эта 'private IFD' - это XMP-блок. Или EXIF. Целиком. Ну если в случае TIFF.

А дальше у нас есть TIFF+EXIF aware program, которая правит Orientation в TIFF, в EXIF, но не в XMP.

Проблема в том, что в Private кто-то положил то, что должен был положить в Standard. Вот в этом проблема.
Потому что помойка.

Хм, но у меня может быть XMP-aware, но не EXIF-aware program.

Или, что вот еще более смешно, потому что очень жизненно:
- я не хочу модифицировать исходный файл
- поэтому пишу sidecar. С XMP:Orientation
- а потом приходит другая программа
- и этот XMP всасывает внутрь RAW
(потому что не ссут модифицировать исходники).

Каждый делал как правильно.

А это (первая часть) — проблема формулировок стандарта XMP. Правильно со стороны Adobe было бы сказать (уж если не хочется выбрасывать EXIF ради хотя бы частичной совместимости) «XMP вы имеете право читать только после прочтения EXIF если он есть». Ну и SDK написать соовтествующим образом.

После этого программа в первой строке не может быть. Т.е. технически может, но она вообще-то не XMP-aware потому что нарушает требования XMP :-)

Сложно так сделать. Потому что XMP бывает и в PDF (где, AFAIK, не бывает EXIF)

Не говоря о том, с чего все начиналось, о sidecars.

В XMP есть неймспейсы. В общем, это всё можно аккуратно разрулить, если захотеть. Не захотели.

О, да, есть.
Поэтому вот FRV пишет crs:exposure и libraw:exposure. А потом мы редактируем это в ACR, оно меняет crs: но не трогает libraw: естественно.

То есть это вот ровно та же проблема, но уже в рамках одного XMP.

Ну вот индустрия и переложила этот гемморой на тебя.

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

Параметры съемки (включая и, для примера, стаб) должны быть в RAW, это очевидно ж.

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

Если уж так хочется в RAW писать именно EXIF зачем-то (зачем? Всё равно RAW нифига не TIFF и общими средствами не читаются, так что смысла большого иметь внутри RAW именно EXIF я не вижу).

Большинство RAW - это TIFF (как контейнер). Есть исключения, но их немного. Т.е. libtiff их прочтет.

Ну, так себе прочтёт. Они все эволюционировали из TIFF, но ты сам не раз писал, что там бывают и относительные смещения вместо абсолютных и прочий мусор, нарушающий стандарт. Т.е. нет особого смысла читать его libtiff'ом.

Как раз "относительные вместо абсолютных" - это результат переноса private data не интерпретируя. Там хорошего решения нет.

UPD: в самом TIFF как раз относительные смещения от начала IFD. И у меня есть зацикленный TIFF.

Ну, если Private Data сохраняют формат IFD, т.е. являются той же табличкой, то их можно переносить правильно, интерпритируя, так как IFD хранит типы данных (!). Но, видимо, много кому было лень делать так и в результате эти Private IFD — и не IFD вовсе.

Оно на то и private, что ты не знаешь что в них.

Это какое-то очень неправильное прочтение стандарта. В стандарте сказано, что там должны быть tags как и в стандартной IFD, только их codes живут в собственном пространстве имён и не требуют регистрации в Adobe.

Т.е. Private IFD должна быть валидной IFD, просто Code могут значить другое. Но это не значит, что она может быть в произвольном формате.

EXIF - да. А Makernotes - это ж поди UNDEF какой-то большой длины.

При чём тут EXIF? Это стандарт TIFF, он общий для EXIF, XMP, Makernotes.

Если мы заявляем что мы TIFF, стандартный, то обязаны делать такой файл, что бы условный libtiff мог перепаковывать все данные не ломая их (но и возможно не понимая).

Но просто RAW — не TIFF и никто и не обещал. Опять же, потому что на экосистему авторам насрать.

Кто запрещает положить private data в какой-нть private tag целиком? Не SubIFD, а вот просто "вот бинарный массив"?

Ничто не мешает, Code = 0xZZZZ, Count = XXXX, Type = BYTE, Offset = 0xYYYY, это нормально копируется в соседний файл, перепаковывается, сохраняется, что угодно.

Если ты ВНУТРИ этих XXXX байт вдруг положил важные для тебя АБСОЛЮТНЫЕ оффсеты — ну, ты ИДИОТ. (понятно, что «ты» здесь — не Алексей Тутбалин).

Тем не менее - кладут. Даже если оффсеты относительные - это не спасет.

Ну вот я и говорю — им насрать на экосистему. Или просто идиоты (не объяснять злонамеренностью и всё такое).

Относительные должны спасать, их же можно релоцировать.

Ты же в чужих private data не знаешь, что offset, а что - просто значение.

Все offset в private data должны быть внутрь их же.

Мне трудно себе представить, чем и как надо думать, делая расширение TIFF где есть кросс-ссылки из бинарных блоков в другие бинарные блоки, которые (бинарные блоки) с точки зрения стандарта TIFF будут независмыми элементами данных.

Т.е. именно потому что так, судя по твоим рассказам, делают, я и говорю, что RAW — не TIFF и libtiff на самом деле НЕ ПРОЧТЁТ RAW, хотя сделает вид, что прочла. Но нет, это иллюзия.

Ну вот взял на сон грядущий CR2 от Canon 1Dx. Tiffdump читает, не ругается.

Собственно, а что оно может прочесть, кроме структуры IFD (правильная) и списка известных ей тегов (корректные)?

Я считаю, что что бы считать файл TIFF'ом, он должен отвечать условиям не только «прочли IFD и не отругались» но и условиям «Отсортировали все IFD и внешние блоки данных как захотели, записали назад и всё работает». Из-за криво сделанных MakerNotes это не так, что и делает RAW не TIFF'ом а чем-то, что чисто по удаче читается libtiff'ом.

Таких, кстати, будет тоже довольно много.

Слава богу, не все программисты у производителей фотоаппаратов на столько криворукие :-)
Это радует.
Но легче вашу жизнь не делает.

Ну ты же понимаешь, что это иллюзия.
Если бы читал — то по его выводу можно было бы восстановить валидный CR2 файл. Обратно собрать теги, записать в файл. Но ведь если и удастся то только по удаче, если все приватные блоки в те же места попадут. А если нет — то TIFF будет «валидный» а CR2 — уже нет.

Значит CR2 — не TIFF. Если бы CR2 был TIFF'ом, то он не ломался бы от любых преобразований, которые не ломают TIFF и не теряют tag values.

Вот ровно это (не совсем ровно, конечно, но по смыслу - очень близко) делает DNG Converter (+ еще упаковку собственно raw-данных меняет с приватной на человеческую). И, гм, все работает более-менее.

Ну, он это делает для поддерживаемых камер же, а не для любых RAW. libraw тоже всё читает — зачем вы написал libraw если всё читает libtiff? Можно было просто libdemosaic написать :-) А вы, глупые, мучаетесь!

А класть оффсеты на внешние блоки, описанные другими тегами, — это уж точно полный идиотизм. Какой-то запредельный.

Ну и проблема конечно есть. Вот берешь ты и начинаешь писать свое (ну там lens data). А потом это стандартизуют.
Но свое писать в таких случаях не перестают.

И зря не перестают. В следующей камере надо перестать. И перейти на стандартное. Это будет честно и правильно.

Но всем пофиг на любой софт, кроме родного, а родной нужные молчаливые приоритеты имеет :-)

Т.е. вот в этом и есть проблема и отсюда и произростает помойка.

Я же не говорю, что проблем нет. Я говорю, что если бы люди думали головой и заботились не только о своих дедлайнах и своём софте, прилагающемся к камере, а о всей экосистеме в целом, то проблем можно было бы избежать даже не имея ГОСТов. В этом мой Point. Что разруха в головах а не в технологиях.

Ты знаешь, разруха она изначальная, даже в рамках EXIF.

В рамках EXIF есть три способа описать colorspace. И никто не мешает использовать все три одновременно. В PNG, кстати, полностью аналогично (но там хотя бы написано в описании, что они не должны противоречить друг другу).

Ну вот и как они приняли такой стандарт без описания приоритетов?! :-)

После этого от остальных как-то даже неловко требовать!

А еще может быть ICC-профиль в EXIF и ICC-профиль в APP (это старый стандарт, до JPEG/EXIF).
И при этом, я вроде никогда не видел (особо и не искал, впрочем) ICC в EXIF.

И при этом вполне может быть JPEG(+ICC) aware program, которая не EXIF-aware.

На самом деле, конечно, цветовые данные и Orientation - это единственная серьезная проблема для показа.
Остальное можно пережить.

Об экосистеме должен думать регулятор, если он есть. Вендор, который думает про экосистему вместо дедлайнов, проиграет и вылетит с рынка.

Но глобально ты прав. Индустрия именно что переложила этот геморой на меня и я не знаю что с ним делать.
Поэтому TIFF/PNG в FRV будут read-only во всех смыслах. Т.е. даже rating/label/orientation поменять будет нельзя.

Ибо
а) модифицировать исходник я не хочу, принципы
б) а sidecars никто для этих форматов не читает.

Это больно.

Но честно.

My kudos.

А если "XMP-блок" и прочую мутоту перезаписывать...
... а ещё лучше ЗАТИРАТЬ и складывать модифицированное рядом.
?
Если ЛибРо почти (альтернативный Адобу) стандарт, почему нет??!

Даже если не проканает с Корелом, приверженцы Ваших программ будут юзать и каждый раз спасибо говорить!
А для "супер_натуралов" можно и галочку прописать "Не трогать "оригинал"!".

Куда писать всё (кроме самой картинки) удалённое из оригинального файла - ваше дело. Но лучше сразу "стандартизовать".

В очередной раз извините за бред.

Мы оригиналы не трогаем не потому что не можем, а потому что считаем это неправильным.

:-D

Добавьте "временную" совместимость.

Что вам мешает добавить "ничем не воспринимаемую метку" в оригинальный файл,,,, и положить рядом файлик с описанием "вашего взгляда на "правду" как и взгляда автора/пользователя снимка"??!
В конце концов, Адобе подобную хрень и продвигает, начиная с Лайтрум (как минимум)!

Если ваше "API" универсальнее, удобнее, богаче и долговечнее, то ... /я вам не завидую/
\
Ещё раз извините за бред.

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

Вы вообще какой-то треш советуете. Украсить помойку еще и своей мусорной кучей.

Убираем весь "треш" из самого файла
(или безопасно "закомментим" его) и переносим в "своё стандартное место"/в "отдельный сопутствующий файлик".

Прога, которая "в курсе", прочтёт и применит то, что нужно вам (и приверженцам вашего подхода и ваших программ), а все остальные этих "модификаторов" и не заметят.

Всего-то дописать #lexa в конец файла! ..

А ещё лучше, (безопасно) дописать это куда-нибудь в самое начало файла.
Тогда у программы (Корел, Адобе, етц) будет выбор. ...

Но, как Вы понимаете, я вовсе не настаиваю!
Идея либо применима либо нет.
...

Либо я непонятно пишу, либо вы не читаете.
Мы не модифицируем исходники. Не потому что не можем, а потому что не хотим, считаем это неправильным.

Add new comment