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

lexa - 31/Янв/2019 15:24

А вот, например, 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

marck - 31/Янв/2019 16:22

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

lexa - 31/Янв/2019 16:27

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

marck - 31/Янв/2019 17:41

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

lexa - 31/Янв/2019 17:55

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

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

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

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

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

lexa - 31/Янв/2019 17:56

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

ziavra - 31/Янв/2019 16:23

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

blacklion - 31/Янв/2019 20:10

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

lexa - 31/Янв/2019 20:15

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

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

lexa - 31/Янв/2019 20:17

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

blacklion - 31/Янв/2019 20:22

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

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

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

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

lexa - 31/Янв/2019 20:28

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

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

Что делать?

blacklion - 31/Янв/2019 20:32

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

lexa - 31/Янв/2019 20:37

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

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

blacklion - 31/Янв/2019 20:43

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

blacklion - 31/Янв/2019 20:24

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

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

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

lexa - 31/Янв/2019 20:30

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

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

blacklion - 31/Янв/2019 20:34

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

lexa - 31/Янв/2019 20:36

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

blacklion - 31/Янв/2019 20:38

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

lexa - 31/Янв/2019 20:40

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

blacklion - 31/Янв/2019 20:11

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

lexa - 31/Янв/2019 20:16

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

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

blacklion - 31/Янв/2019 20:19

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

lexa - 31/Янв/2019 20:24

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

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

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

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

blacklion - 31/Янв/2019 20:27

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

И в стандарте не написано: «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»

lexa - 31/Янв/2019 20:33

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

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

lexa - 31/Янв/2019 20:34

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

blacklion - 31/Янв/2019 20:39

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

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'.

lexa - 31/Янв/2019 20:42

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

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

blacklion - 31/Янв/2019 20:44

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

lexa - 31/Янв/2019 20:49

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

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

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

blacklion - 31/Янв/2019 20:55

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

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

lexa - 31/Янв/2019 20:58

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

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

blacklion - 31/Янв/2019 21:00

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

lexa - 31/Янв/2019 21:10

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

lexa - 31/Янв/2019 21:11

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

blacklion - 31/Янв/2019 20:36

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

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

lexa - 31/Янв/2019 20:38

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

blacklion - 31/Янв/2019 20:42

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

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

lexa - 31/Янв/2019 20:43

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

blacklion - 31/Янв/2019 20:45

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

lexa - 31/Янв/2019 20:53

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

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

blacklion - 31/Янв/2019 20:57

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

lexa - 31/Янв/2019 21:04

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

blacklion - 31/Янв/2019 21:24

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

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

lexa - 31/Янв/2019 21:37

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

blacklion - 31/Янв/2019 21:42

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

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

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

lexa - 31/Янв/2019 21:46

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

blacklion - 31/Янв/2019 21:52

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

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

lexa - 31/Янв/2019 21:57

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

blacklion - 31/Янв/2019 22:00

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

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

lexa - 31/Янв/2019 22:05

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

blacklion - 31/Янв/2019 22:10

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

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

blacklion - 31/Янв/2019 22:15

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

lexa - 31/Янв/2019 22:28

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

lexa - 31/Янв/2019 22:28

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

blacklion - 31/Янв/2019 22:34

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

lexa - 31/Янв/2019 22:51

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

blacklion - 31/Янв/2019 22:54

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

blacklion - 31/Янв/2019 22:32

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

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

lexa - 31/Янв/2019 22:53

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

blacklion - 31/Янв/2019 22:58

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

blacklion - 31/Янв/2019 22:01

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

lexa - 31/Янв/2019 20:45

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

blacklion - 31/Янв/2019 20:46

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

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

blacklion - 31/Янв/2019 20:49

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

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

lexa - 31/Янв/2019 20:51

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

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

blacklion - 31/Янв/2019 20:58

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

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

lexa - 31/Янв/2019 21:08

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

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

lexa - 31/Янв/2019 21:09

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

Seva - 01/Фев/2019 14:57

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

lexa - 31/Янв/2019 20:56

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

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

marck - 01/Фев/2019 02:07

Это больно.

Но честно.

My kudos.

mikeuz - 01/Фев/2019 22:05

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

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

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

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

lexa - 01/Фев/2019 22:10

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

mikeuz - 01/Фев/2019 22:23

:-D

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

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

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

mikeuz - 01/Фев/2019 22:12

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

lexa - 01/Фев/2019 22:21

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

mikeuz - 01/Фев/2019 22:30

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

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

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

mikeuz - 01/Фев/2019 22:34

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

mikeuz - 01/Фев/2019 22:58

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

lexa - 02/Фев/2019 08:53

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