Закон парности

События, как известно, ходят парами. Например:

I. Последнюю неделю, в вялом режиме (1 письмо в день) разбирался с багрепортом пользователя одного опенсорсного RAW-конвертора.  Дескать вот на Олимпусах их конвертор не показывает нормально превьюшки: в файле их две крохотная и нормальная, извлекается крохотная. "А раньше все работало".

Что оказалось:

  1. Этот самый конвертор берет и правит метадату прямо внутри RAW (убилбынах), вписывая туда СВОЮ превьюшку. А потом ее не показывает.
  2. Свою превьюшку он вписывает в Sub-IFD олимпусовскую (тег 0x2020) и ставит этому тегу тип 4 (32-bit unsigned), тогда как у Олимпуса оригинально там тип 13 (Sub-IFD).
  3. Ну и в LibRaw 0.17 и более новых - мы добавили в чтение тега 0x2020 проверку типа и принимаем там только тип 13 или 7 (undefined). Надо, наверное, и 6 принимать (потому что выглядит корректно)

Ну и соответственно, "раньше работало" (потому что тип не проверялся), теперь работает с файлами из камеры, ну а если в файл нагадить - не работает. Так как нет гарантий, что тег 0x2020 используется только Олимпусом (и только для превью) - проверять тип кажется полезным.

Ну вот в течение 7 дней я пытаюсь объяснить несчастному пользователю, что

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

II. Сегодня сажусь утром разбирать другую жалобу. Дескать FRV показывает маловато EXIF-тегов у JPEG. И действительно, маловато.

Беру камерный JPEG (от того же Олимпуса - от предыдущих разборок остался под рукой), смотрю в него, смотрю в EXIF-парсер (не от LibRaw, у FRV - свой) и что я вижу:

  1. Тег 0x8769 (EXIF SubIFD), тип 4 (unsigned int), длина 1.
  2. Ну естественно, у такого тега (тип 4, длина 1) значение содержится в самом теге, а в нем вовсе не смещение к данным.
  3. Ну оно так и читается, как значение, а не как смещение.

И оно как бы вот даже смешно, одна и та же камера, в разных местах ставит разные типы: 13-й для превьюшки и "какой попало" для EXIF Sub-IFD (ну потому что конкретно 0x8769 "все и всегда" обрабатывают как смещение).

Но таки да, под камеру парсер поправим. А под кривой софт - нет.

Comments

Адъ...

Жызнь!

И что это за "опенсорсный конвертор" такой, который равы портит?

digiKam

(давайте называть это "модифицирует")

Всё у этих кедофилов не как у людей...

Ну вот желание Адобы писать метаданные внутрь DNG (а не в sidecar, той же компанией придуманный) меня тоже несколько вот удивляет.

То есть от сайдкаров, конечно, есть некоторые проблемы by design. А от записи в raw - проблемы другого типа.

DNG — адобовский формат, имеют право. Я вот как раз вижу в этом огромное преимущество DNG перед PEF у Пентакса.

Т.е. одно дело лезть в формат, формально не документированный, формально не являющийся над/под-множеством TIFF'а (часто фирменный RAW похож случайно на TIFF, это да, но как мы видим – всего лишь похож, потому что ВСЕ производители камер что-нибудь да нарушат (с точки зрения TIFF, не с точки зрения своего RAW), но ОНИ ИМЕЮТ НА ЭТО ПРАВО, потому что они НИГДЕ не заявляли, что это TIFF). Поэтому лезть в фирменный RAW — не нужно.

А вот если производитель заявляет проддержку именно DNG — то это совсем другое дело. Тогда лезть туда можно (соблюдая стандарт, разумеется), ведь стандарт заявлен и описан. А если при этом производитель камеры что-то нарушает — то надо бить его ногами, потому что он прямым текстом обещал Adobe® DNG, а не «какой-то RAW случайно похожй на TIFF».

У меня претензия не в том, что "не имеют права", а в том, что "не стоило бы".
Потому что "это" можно (пытаться) делать и на карте памяти, подключенной через полуживой ридер. Вот не надо писать в RAW. Совсем не надо. А в промежуточный формат - которым вполне может быть DNG - можно.

Как из программы различить два случая - не знаю.

Мне кажется, человек, который делает что-то с современной картой памяти кроме как копирование средствами OS с неё файлов, напрашивается на неприятности в любом случае.

Ну и с USB-диском внешним.

У меня, кстати, очередной (третий или четвертый) уже кард-ридер перестал быть USB3. В смысле что если к -3 подключить кабелем же -3, то устройства не видать. А микро-USB-кабелем (USB2) в тот же порт - работает.
Два (кажется) трансценда, один внутренний китайский и вот один Lexar. При том что включены в разные порты, китаец был даже в другой контроллер, Lexar - через хаб (в мониторе). А конец - один.

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

> DNG — адобовский формат

ну так как почти все raw форматы это tiff контейнер, то им можно и туда заодно !

Z / V

RAW - это же "как бы"сырые данные.
Чтобы состряпать из них TIFF, камере нужно потратить некие дополнительные ресурсы...
(особенно если этот ТИФФ потом ещё раз пережёвывать, в камере же!, в "фирменный" RAW).
Про камерный джипег я помню. Он из тифа в камере считается?

Речь о том, что фирменный RAW часто похож на TIFF. Иногда — до степени смешения. На первый взгляд. Но есть ньюанс. TIFF — гибкий формат. А вот фирменный RAW может (и технически и юридически, потому что никто не произносил вслух слово «TIFF») сломаться от перестановки местами двух полей в image directory. TIFF от этого разваливаться не имеет право. а фирменный RAW — имеет.

А можно из как бы ТИФа поканально вырвать RGGB, G1 и G2 раздельно?

Из какого как бы ТИФа? Из фирменных RAW? Ну вот libraw этим занимается, в частности. Из настоящего четырёхканального TIFF? Да, можно.

"А можно из RGB-тифа вынуть R,G,B отдельно?"

"Можно, придется программу написать или взять готовую". Вот у ежиков то же самое....

> А вот фирменный RAW может (и технически и юридически, потому что никто не произносил вслух слово «TIFF») сломаться от перестановки местами двух полей в image directory. TIFF от этого разваливаться не имеет право. а фирменный RAW — имеет.

вы имеете ввиду наверное что некое конкретное ПО может не обработать данный случай... но причем здесь сам raw файл ?

Z / V

При том, что вы не сможете сказать, что это RAW файл от такой-то камеры такой-то версии прошивки. Это что-то уже совсем другое. Т.е. вас любой софт имеет право послать после такого изменения далеко и надолго. И будет прав.

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

Понятно, что перестановка полей тут — только один из многих примеров.

>> это баг в софте будет — ожидать фиксированный порядок полей. А в случае любого собственного RAW формата перестановка полей будет ошибкой в файле а не в софте

А если выяснится, что тот, кто переставил поля - владеет фирменной документацией (под NDA) и там написано что можно переставлять?

А как это выяснится без нарушения NDA? Я рассуждаю с точки зрения внешнего наблюдателя.
Производитель что-то нам гарантирует про свою камеру.
Например, что у неё есть запись в proprietary RAW format.
Или что она поддерживает формат DNG. С логотипчиком, ссылкой что это trade mark или что там Adobe, и всем подобным.

В первом случае мы не можем вообще ничего требовать относительно формата. Похож на TIFF? Ну, так получилось, мы не специально.

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

Производитель нам, в общем, ничего не гарантирует (кроме своего конвертора, который дает в комплекте и пользоваться которым обычно нельзя).

Производители софта (которым можно пользоваться) гарантировать тоже ничего не могут. Они делают all the best и что-то получается

Так все и живут.

А это вопрос, в частности, к адобу. Если мне на ноутбуке наклеют наклеечку wiFi 802.11n а там будет собственный формат беспроводной сети внутри — ну, с большой вероятностью производителя вые... и высушат. Потому что WiFi Alliance, сертификация, и всё такое.

Если Adobe не следит за то, куда лепят DNG — это фигово (ну да, мало что мы можем с этим сделать).

В случае отсуствия наклейки DNG, конечно, ничего не гарантирует.

Я скорее не про DNG, а про все остальные форматы.
DNG, я надеюсь, хотя бы адобьим валидатором проходят.

Ну так если про все остальные форматы, то ты повторяешь мой тезис: как бы оно ни было похоже на TIFF — никаких гарантий нет и поэтому вообще можно (и нужно) забыть слово TIFF, а не говорить «ну оно жн так похоже, давайте работать с TIFF'ом».

Именно по этому я не вижу проблем писать метадату в DNG (ну, за вычетом сбоя оборудования во время записи, да), но вижу — в любой другой RAW.

Ну надо сказать, что makernotes в DNG тоже вот лежат как-то не так (и потому, собственно, адобовский конвертор их и портит)

Ну, пинать техподдержку. Вон, Sony запинали же за lossy raw.

Причем тут техподдержка?

Бррр. Я запутался. DNG-то откуда?

DNG - из конвертора.
Хотя, наверное, DNG из камеры лейка тоже может извратить.

И вот там (в DNG из конвертора) есть гигантских размеров жопа с Makernotes.

Ну значит в техподдержку Adobe ;-)

Чем она поможет?

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

- Makernotes берем из исходника как есть, никак не интерпретируем, никак не меняем, кладем в DNG
- но Makernotes могут внутри содержать ссылки на другие места в исходном файле.

Каковые места - не берем, не копируем (а если даже берем и копируем - то как сохранить смещения?)

Идея патчить makernotes мне тоже не кажется разумной.

Мда, разве что рядом вкладывать ихсодный RAW целиком…

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

Причем к формату DNG это тоже относится: (минимальная) часть данных, нужных для интерпретации RAW она как бы есть (и описана в стандарте). А вот те же makernotes - их же пишут и те камеры, у которых родной формат DNG

Многие добавляют строку "обработано в ... ".
Что мешает все комментарии (параметры проявки, обработки) писать отдельной, не мешающей никому/ничему секцией?
Вот у Олимпуса есть секция Distortion, там больше 10 параметров. Её же никакой софт не портит.

Кстати, хорошая идея и для вашего софта. :-)

Куда писать?

Понятно, что не вам пинать, а владельцам этих камер.

>>Производитель что-то нам гарантирует про свою камеру.
Например, что у неё есть запись в proprietary RAW format.

Производитель, в данном случае, не гарантирует, а предупреждает и отмазывается: только родной софт иначе сам_дурак!

> А в случае любого собственного RAW формата

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

Z / V

так а откуда мы знаем что это tiff-контейнер? Расширение другое, в документации слова tiff нигде нет.

Да, было несколько камер в истории, умевшие tiff (но не raw, заметим, а по сути непожатый jpeg!), но ресь же не о них.

> так а откуда мы знаем что это tiff-контейнер?

если структура файла соотв. "стандарту" , то ПО которое учитывает стандарт (не обязательно конвертер) может правильно разобрать файл на составные части (опять же мы не говорим о конверсии - просто разбор, без интепретации содержимого относящегося к конверсии и томы подобному)

Z / V

Это может быть удачей. Сегодня может разобрать, завтра вышла прошивка с версией на сотую изменившаяся (1.02 → 1.03) и уже не может. И чо? Производитель камеры что-то нарушил? Нет. Потому что ничего не обещал. Это бага? А может быть и нет.

В общем, пока нам производитель чётко не сказал: «у нас тут TIFF, пользуйтесь» нельзя полагаться на то, что структура файла, записанного аднной конкретной версией прошивки в данных конкретных условиях съёмки на данной конкретной камере вдруг оказалась валдина с точки зрения любого стандартра — TIFF6, TIFF/EP, PDF, PostScript, whatever.

Вот про JPEG честно говорят: JIFI/EXIF2.3 или что там, и пытаются соотвествовать, и мы имеем право на это полагаться.

Вот история с панасом и их SubIFD не с тем порядком байт - она и к JPEG внутрикамерным относится.

Ну типа никто не обещал же, там же другой тег.

Вот например панасоники (и лейки - которые те же камеры), у которых вроде как "a la tiff" структура, но у SubIFD может внутри порядок байт внезапно быть другим.
Никакого II/MM там, конечно, нету, ибо места для него нет.

Ну вот "похож", да.

Если в PhotometricInterpretation написано что-то, чего нет в описании TIFF 6.0 - это TIFF или нет?

> Если в PhotometricInterpretation написано что-то, чего нет в описании TIFF 6.0 - это TIFF или нет?

1) это же относится к интерпретации данных внутри контейнера, да ? т.е. даже если "стандард" явно запрещает что-то не описанное в стандарте для данного тэга это все равно оставляет саму структуру файла контейнером соотв. стандарту

2) если же "стандард" явно не запрещает для данного случае что-то не описанное стандартом то не только структура соотв. контейнеру, но и в части интерпретации содержимого контейнера все в порядке

Z / V

Вот кстати я тут разбирал тупо RGB Tiff. (При помощи, тупо, libtiff)

И вот скажу честно - мне вот совершенно неочевидно, чего там ждать в распакованых данных при bits per sample = 12 (ну, к примеру вот 12).
Написать такой тег можно? Ну да. Что он значит?

> Написать такой тег можно? Ну да. Что он значит?

а вот это уже не про "контейнер", а про интерпретацию содержимого тэгов (тех которые не отвечают за собственно структуру контейнера)...

Z / V

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

Я говорю о конкретно TIFF 6, вот в одной руке файл, в другой - текст стандарта. Стандарт определяет не только "контейнер" но и интерпретацию стандартных же тегов.

И выясняется, внезапно, что стандарт довольно рыхлый даже когда мы вот ровно ему следуем.

> Назвал все буквы, но не сумел прочесть слово.

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

> Стандарт определяет не только "контейнер" но и интерпретацию стандартных же тегов.

я лишь про контейнер - кто-то утверждал что если какое-то ПО не понимает допустимую стандартом перестановку тэгов в порядке следования в файле то все пропало и на этом основании это не tiff контейнер...

Z / V

>> кто-то утверждал что если какое-то ПО не понимает допустимую стандартом перестановку тэгов в порядке следования в

Ну мне весь этот спор напомнил "средневековую схоластику", то есть, понятно, наше представление о ней.

Само по себе заявление "это TIFF-контейнер" (которого никто /кроме DNG-камер/ не делают, но формата контейнера при этом придерживаются "как то") - практического смысла не имеет т.к. контейнер без интерпретации содержащихся в нем данных никому не интересен. Что с ним делать то? Копировать? Копировать его тоже можно только побитно, потому что что там на уровне данных (и нет ли абсолютных/относительных ссылок в другие части файла) - в рамках гипотезы "ну вот такой контейнер" - неизвестно.

> Ну мне весь этот спор напомнил "средневековую схоластику", то есть, понятно, наше представление о ней.

так отож...

Z / V

Да нет же. Вы прочли, что я написал вообще? Это что-то, что, если прищуриться в той или иной степени, похоже на TIFF. Но не TIFF.

> Но не TIFF.

чем не TIFF ? что именно нарушает в стуктуре файла стандарт ? речь не про конвертер, а именно про содержимое файла

Z / V

Часто maker notes нарушают. Часто II/MM в начале нет, а есть своя сигнатура какая-то. Наверное, есть камеры, у которых на 100% не нарушают (сомневаюсь, если честно), но могут начать завтра с новым апдейтом прошивки.

А что такое "стандарт"

В стандарте TIFF 6.0 даже про SubIFD нету ничего.

Tag Image File Format/Electronic Photography (TIFF/EP) is a digital image file format standard – ISO 12234-2

> В стандарте TIFF 6.0 даже про SubIFD нету ничего.

но тогда и претензии к файлу про SubIFD не надо предъявлять (на тему что он не tiff 6.0 контейнер

Z / V

Ну да, он не 6.0, а, например, EXIF.

> но ОНИ ИМЕЮТ НА ЭТО ПРАВО, потому что они НИГДЕ не заявляли, что это TIFF

кстати а в чем должно состоять заявление что файл - tiff контейнерм, помимо следования стандарту насчет содержимого ?

Z / V

Официальная ссылка в документации, очевидно. В которую можно тыкать носом техподдержку.

> И нет, всякое говно, которое придумало тип из головы - мы поддерживать не будем. Вот хочешь патч и собирай все сам, но и не более.

но вот если говно будет в firmware камеры то будете же, да ?

Z / V

увидел что камеру (firmware) будете... а если например в чем-нибудь фирменном типа Adobe DNG converter'е что-нибудь не так (случилась проруха) - будете писать им чтобы поправили или таки будете поддерживать (если вдруг нет) ?

Z / V

Хороший, добрый вопрос. Да, будем, конкретно с конвертором. Более того, уже (там этой прорухи у них...)

То есть водораздел - по безальтернативности.