ЧуднЫе открытия DNG
Про DNG я уже много раз ругался (начиная вот с этой вот статьи: Два пути в никуда, которую мы написали вместе с Ильей Боргом для Компьютерры аж 6 лет назад) и продолжаю ругаться.
Тем не менее, многие проблемы, которые были в старых версиях формата - полечены (в частности, теперь сохраняется "черная рамка"), да и вообще DNG 1.4 неплохо подходит на роль универсального контейнера, для промежуточной обработки, особенно если все теги аккуратно прописаны, а кушающая эти DNG программа - их правильно понимает.
Поэтому я тут потратил пару дней на изучение текущего состояния дел: взял RAW-файлы от ~400 разных камер, сконвертировал в DNG (использовался DNG Converter 8.4, собственно я саму конверсию делал весной, для другой задачи), читал файлы LibRaw (RawDigger-ом) и смотрел, не откроются ли какие-то бездны, а ежели откроются, то значит правил недоделки в LibRaw.
Естественно, обращал я внимание только на те файлы, которые "на глазок" рендерятся не так, как исходный RAW-файл.
Из ~400 камер (вот точно не считал, на глазок), проблемы вылезли на 9-ти. А именно:
- Fuji S3Pro: DNG-конвертер обрезал таки черную рамку и записал неправильный тег CFAPattern (описание байеровской мозаики). Результирующий файл нормально открывается в Adobe Camera RAW (там, похоже, четная ошибка), нормально открывается в RPP (там, по всей видимости, для известных камер CFAPattern вшита в код), будет теперь нормально открываться в LibRaw (потому что вот пришлось этот случай захардкодить), не открывается в CaptureOne 7.2 (она его вообще не видит при импорте).
- Пачка камер Fuji с обычным байером (F800EXR, F550EXR, HSxxEXR) - уровень черного в DNG записывается крайне странным образом: BlackLevelRepeatDim 2x2, а записанное количество уровней черного - 8, а не 4. В LibRaw пришлось убрать добавленную недавно проверку, что два этих тега друг другу соответствуют. ACR - открывает. CaptureOne - эти файлы видит, но там такой бред, что придется отдельный пост про это писать.
- Fuji X-S1. Отчего-то написан тег DefaultScale, у которого scale по x и y отличаются в 4-м знаке (aspect ratio получается ~1.001). Смысла в этом я никакого не вижу. Если в raw-конверторе стоит жесткая проверка на AspectRatio==1.0, а во всех иных случаях происходит перемасштабирование, то вы немножко потеряете в резкости.
- Kodak DCS660C. DNG-конвертор ремэппит данные (с округлением!) из диапазона 160-2453 (это до вычитания черного) в диапазон 400-4095. Зачем они так делают - мне неведомо.
- PhaseOne IQ250. Вместо встроенного ICC-профиля (который так себе), пишется адобовская DNG-шная CameraMatrix, которая просто ужасна. Впрочем, камера новая, возможно в более новых версиях конвертора профиль поправили в сторону улучшения.
Отдельная история с камерами Canon (вероятно, всеми современными, но я конечно все не смотрел, выборочно 7D, 70D, 700D, файлы лежали рядом).
У камер Canon уровень черного отличается по каналам (незначительно на низких ISO, заметно - на высоких). DNG Convertor ставит поканальное одинаковое и неправильное значение (у Canon два тега, "усредненное по каналам" и "поканальный черный"). В случае, когда уровень черного отличается сильно (высокие ISO) и, одновременно, вытягиваются тени, это будет приводить к повышенному banding.
Исходя из общих соображений (DNG Convertor и ACR обновляются одновременно, я предполагаю там общую "базу знаний" по камерам), это место должно работать одинаково (неправильно) в DNG Convertor и в ACR/LR, поэтому конвертируя в DNG вы ничего не ухудшаете, относительно работы с исходными файлами прямо в ACR/LR. Используйте другие программы....
Сухой остаток:
- Если вы пользуетесь программами Adobe, то использовать DNG в качестве формата для работы - можно. Даже если в конверсии есть странности, они компенсируются четными ошибками в ACR.
- Конвертировать в DNG для совместимости новых камер со старыми версиями ACR - можно, но могут быть приколы (см. IQ250).
- Конвертировать в DNG для совместимости с другими конверторами - бывают удивительные вещи (про Capture One напишу вечером отдельно).
- Конвертировать в DNG для архивного хранения и стирать исходник - крайне нежелательно (см. IQ250).
- Если вы используете камеры Canon, пользуетесь высокими ISO и недодерживаете (тянете тени), возможно более другой (не Адобовский) конвертор даст результат лучше. Кормить этот конвертор надо CR2-файлами, а не DNG.
Comments
А вы шлёте багрепорты в адобе
А вы шлёте багрепорты в адобе? Вроде бы, даже если там просто на форумах писать - бывают положительные результаты.
ps: а не появится ли тут таки какая-нибудь нормальная авторизация от социалок? Вот даже текущая (бугага, с проверочным кодом "NAQjy") как-бы намекает..
По обрезанной рамке и по
По уровню черного у Кэнона - нет еще пока, потому что я в это место заглянул когда уже текст в бложик писал.
А какой вывод по камерам где
У меня нету ответа т.к. в
Навскидку (но PEF от K200D, а DNG от 645Z, какие были под рукой):
Опять же, поведение DNG-читателя с DNG-файлом - на самом деле вовсе непредсказуемо, ждите вечером (анонсированный уже) рассказ про C1.
С1 этих родных DNG, кстати,
Красавцы, да.
При этом DNG с неподдерживаемых официально камер - видит (другой вопрос - КАК ОНО ИХ ВИДИТ)
А "у мене все работает". В
Забавно. А в списке
Где "там"?
Где "там"?
Я смотрю сюда: http://www.phaseone.com/en/Supported-cameras.aspx?camera=Pentax никаких пометок.
Я смотрел во времена 6-ки,
ну и кстати можно построить
Оно не так просто, как
То есть, я вот ожидаю, что у адобы разницы не будет (если конвертор и ACR - одной версии), но тоже вот давно не проверял.
В случае же "обычного конвертора"™ возникает масса мест, где возможны незначительные (или значительные) расхождения. Ну вот, навскидку:
Нет, я про libraw строго. Что
Ну вот в LibRaw из трех
Для ~400 камер (800 парных файлов) быстрее всего оказался визуальный контроль. Берем FRV и листаем. Видим в паре визуальную разницу - запускаем RawDigger и смотрим че-как. Дальше идем патчить libraw, да.
Я какой-то автомагический скрипт тоже сделаю, конечно, но на текущем этапе пока так.
> Вместо встроенного ICC
> Вместо встроенного ICC-профиля
что странно ибо DNG контейнер может хранить ICC профили, в ем тэги даже для этого есть
Ну так Adobe впаривает свою
О да, их профили с 4-х
Странное что то творят с
Странное что то творят с Кодаком 660. Посмотрел быстро в прошивку - там рав просто сильно компрессируется до 10 бит (точнее до 0..670 диапазона) и потом разжимается так немного странно при конвертации но тени остапются в тенях - кривая как в 14n но более сильно компрессирующая. Что там Адоб делает непонятно. Уровни черного во всех Кодаках что я ковырял (совсем древних не знаю) вычитаются в камере перед записью в рав так что там ничего вычитать не надо.
Без камеры в руках проверить
Без камеры в руках проверить трудно, но выглядит так, как будто Adobe используют не ту кривую для линеаризации.
Сложный вопрос. У меня с этой
А рендерится одинаково в
А рендерится одинаково в Photodesk и ACR? Или в FRV и ACR? ACR для Кодаковских файлов плохой показатель нормальности - многие до сих пор Фотодеск предпочитают.
В FRV рендерится одинаково
Не, в этом кодаке черный не
Это интересно - он даже в
Это интересно - он даже в пробэке вычитали. Поковырял немного еще прошивку (в ней к сожалению символов нет как в последующих начиная с 7хх серии) вроде бы нигде нет логов о вычитании черного (у них каждая операция что то выводит - ББ итд). Похоже таки да - не вычитают. Там же рав еще не DCR а TIFF (судя по прошивке)? Кривые компрессионные можно вытянуть если что - они там отдельно в сенсорном файле лежат (ну и до 14n Кодаки из писали в рав все - и компрессионные тоже).
Смотрите тэг 0x0e4e, и там -
Смотрите тэг 0x0e4e, и там - 160. Это IMHO и есть уровень черного.
Не это
Не это AH2GreenInterpolationThreshold (тэг 3662). Уровень черного в разных тэгах есть в кодаковском IFD:
BlackLevelTop (тэг 1007)
BlackLevelBottom (тэг 1008)
BlackLevelRough (тэг 1038)
BlackLevelRoughAfter (тэг 1046)
Вот смотрю в 660C:
Вот смотрю в 660C:
0x03ef (1007) содержит 159
0x03f0 (1008) содержит 166
0x040e (1038) содержит 939
0x0416 (1008) отсутствует
Если не трудно, пришлите номера тэгов и описания в почту, пожалуйста?
2. Там вовсе не обычный байер
2. Там вовсе не обычный байер. Почитайте про матрицу EXR.
8 уровней чёрного - это BlackLevelRepeatDim 2 x 2 умножить на SamplesPerPixel.
Там нет ничего лишнего. Хотя dcraw и многие другие, берут только половину матрицы.
3. А я вот не вижу смысла сравнивать scale по x и y.
У этих камер матрица повёрнута на 45 градусов.(кстати тоже EXR)
Перемасштабирование всёравно придётся делать вместе с поворотом.
Масштаб = корень квадратный из двух.
DefaultScale - это просто масштаб подогнали, так чтобы последняя точка
исходной картинки совпадала с последней точкой полученной картинки.
Рассчитано, что картинка обрезается по DefaultCropSize.
Так как у Вас другой размер, Вам этот DefaultScale не подойдёт.
Можно рассчитать самому, а можно и оставить корень из двух.
Разница почти не заметна.
История с SamplesPerPixel=2 в
История с SamplesPerPixel=2 в случае с DNG и Fuji - вообще вот отличная, как мне кажется.
Во-первых, а вот где это документировано? (следствием является то, что DNG от этих Fuji понимают далеко не все, хотя вот совместимый формат, все вот это вот).
Ну ладно, запихали.
Переходим к следующему шагу, линеаризации. LinearizationTable общая на все каналы. Опаньки.
Ну и вообще, пиксели же не друг под другом, информацию о геометрии потеряли, красавцы.
Но да, личную адобовскую задачу это решает (линеаризацией они не пользуются).
В DNG есть такой тэг
В DNG есть такой тэг 'CFALayout'. Он описывает геометрию.
Линеаризацией они пользуются. Посмотрите их DNG SDK.
Кстати в нём много полезного.
Как записать в DNG две разные
Как записать в DNG две разные линеаризационные кривые для двух (полу)матриц?
UPD: вот CFALayout мне в данной конкретной ситуации тоже смешно выглядит т.к. два пикселя записаны в одни с SamplesPerPixel=2
И, да, история про "повернута
И, да, история про "повернута на 45 градусов" - не проходит проверку.
Возьмите вот прямо данные с RAW, никак их не масштабируя и не растягивая. Ничего там не повернуто. Столбцы вертикальны, строки - горизонтальны: http://blog.lexa.ru/2009/01/11/primenenie_psixotropnix_preparatov_k_obra...
Они таки повёрнуты. Просто
Они таки повёрнуты. Просто они в файл записываются по диагонали.
Там есть два варианта:
1. В одной строке файла записывается одна строка картинки.
Каждая вторая строка сдвинута на пол пиксела.
2. В одной строке файла записываются две строки картинки.
В чётных пикселах одна, в нечётных другая.
ну вот давайте возьмем родной
ну вот давайте возьмем родной фуджевский файл, благо сами значения пикселов там те же, что в в DNG.
И вот именно его и будем рассматривать как исходник (потому что DNG - производный вариант, сами камеры этот формат не пишут).
Вот там будет просто вот изображение. Ну вот скажем Fuji S5Pro, размер изображения 4352x1444 (вместе с краями, то что с сенсора приходит). Горизонталь - горизонтальная.
Если его удвоить по короткой стороне, получится 4300x2900, обычные такие 3:2.
То что dcraw (и не только она) - поворачивает на 45 градусов - это для получения байеровского паттерна, так оно в этой камере - столбик G, столбик RB.
Никакого интерливинга двух изображений нету, два sub-image, практически вот TIFF.
4352 - это сразу две строки.
4352 - это сразу две строки. В чётных пикселах одна, в нечётных другая.
Причём вторая строка сдвинута относительно первой на пол пиксела вправо.
Dcraw поворачивает изображение один раз после демозаики.
Если его повернуть на 45 градусов перед демозаикой, то пикселы смешаются и
сделать демозаику будет невозможно.
Если бы это было две строки,
Если бы это было две строки, то изображение повторялось бы дважды. Правая и левая половина картинки были бы (почти) одинаковые. А это не так.
UPD: я конкретно про фуджевские файлы. Впрочем, длина строки в DNG такая же.
Dcraw поворачивает дважды. Один раз в crop_masked_pixels, где из RAW() делается BAYER(), второй раз в fuji_rotate()
В crop_masked_pixels это не
В crop_masked_pixels это не поворот. Она просто расставляет их по своим местам.
Поворот на 45 градусов без интерполяции невозможен.
Если бы там был поворот, то демозаику уже нельзя было бы сделать.
Если это не поворот, то что?
Если это не поворот, то что?
Вы сдампайте raw_image[] в TIFF, а потом image[] после crop_masked_pixels() тоже в TIFF.
Собственно, это можно сделать средствами dcraw (-E и -D, соответственно). raw_image[] неповернутое и приплюснутое, это и есть исходные данные.
Вот возьмите, чтобы говорить строго про одно и то же, вот этот файл: http://rawsamples.ch/raws/fuji/s5pro/RAW_FUJI_S5PRO_V106.RAF
Вот после -E: Вот после -D:
Вот после -E:
Вот после -D:
Это я видел.
Это я видел.
В первом изображении пикселы идут так:
A0 B0 A1 B1 A2 B2 A3 B3 A4 B4
Во втором так:
A0__A1__A2__A3__A4
__B0__B1__B2__B3__B4
поэтому оно не повторяется дважды.
И даже похоже на нормальное.
Но хорошего качества Вы так не добьётесь.
Извините, но оба изображения
Извините, но оба изображения - обычный TIFF. Там никаких субпиксельных смещений нет, прямоугольная сетка, квадратные пикселы.
И дырок (нулевых пикселов)- нету после такого поворота.
Задача поворота - привести паттерн к байеровскому
RG
GB
(или аналогичному, главное что два зеленых не друг под другом)
Это не дырки. Я просто хотел
Это не дырки. Я просто хотел показать сдвиг на пол пиксела.
Пиксел B0 находится не прямо под A0, а между A0 и A1.
Вы в каком направлении
Вы в каком направлении смотрите?
Верх изображения - сверху.
Верх изображения - сверху.
Ну так тогда исходные A0,A1
Ну так тогда исходные A0,A1 тоже не рядом по горизонтали,а идут вверх под 45
Я имел ввиду верх, где облака
Я имел ввиду верх, где облака.
Ну а демозаика делается "под
Ну а демозаика делается "под углом", потому что у нее верх там, где верх "файла".
Соответственно, смело можно обойтись без этого прикола с поворотом, а модифицировать демозаику, чтобы пикселы брала со сдвигом (на пиксель, очевидно, оно иначе не умеет). Надо попробовать.
В смысле скорости и памяти - скорее всего будет огромный выигрыш.
Всё правильно можно
Всё правильно можно модифицировать демозаику.
Но после демозаики не забудьте повернуть.
Это необходимо.
Куда же повернуть, если оно
Куда же повернуть, если оно как было горизонтальным, так и останется.
Тут же просто все. Вот берем resolution target с вертикальными линиями. Смотрим на исходный RAW, без поворотов и растяжений.
Вопрос - станут ли вертикальные линии зигзагообразными? Я вот такого не вижу.
Горизонтальные линии станут
Горизонтальные линии станут зигзагообразными.
В исходнике то они не таковы,
В исходнике то они не таковы, ну насколько я видел.
Нужно смотреть на мелкие
Нужно смотреть на мелкие детали.
Про мелкие детали неизвестно
Про мелкие детали неизвестно что у них и как.
Смотреть надо, очевидно, на чуть наклонные горизонтали (и вертикали), там смещенные пикселы будут видны. Только вот я их не вижу (конкретно для S5)
> У этих камер матрица
> У этих камер матрица повёрнута на 45 градусов
В каком смысле - повернута? Матрица там стоит так же, как и в Nikon D200.
Имеется ввиду расположение
Имеется ввиду расположение пикселов относительно друг друга.
В повёрнутой матрице пикселы второй строки не находятся прямо под первой,
а сдвинуты на пол пиксела вправо.
Мы так окончательно
Мы так окончательно запутаемся и испортимся.
Давайте рассматривать, для начала, только "крупные" пикселы. Которые Fuji пишет в отдельное изображение со странным aspect ratio (никак не 1.41, что отдельно смешно).
Эти пикселы - расположены по обычной прямоугольной сетке, вертикальные столбцы, горизонтальные строки. Верно?
Эти же пикселы - это первый компонент в SamplesPerPixel=2 в DNG.
Большие и маленькие пикселы
Большие и маленькие пикселы есть только в одной камере: Fujifilm FinePix F700.
В овсех остальных они одинаковые.
Я не хотел называть их "более
Я не хотел называть их "более" и "менее" чувствительными, но придется. Вот, назвал.
Они одинаково чувствительные.
Они одинаково чувствительные.
В какой камере? В S5Pro -
В какой камере? В S5Pro - разная чувствительность (и обеспечивается, насколько я слышал, разной плотностью фильтров). Другие в руках не держал, говорить так уверенно не могу.
В S5Pro одинаковая.
В S5Pro одинаковая.
Разная чувствительность только в F700.
А с чего же две "полукартинки
А с чего же две "полукартинки" (которые лежат в файле RAF отдельно, напоминаю) отличаются по средней яркости на 4 стопа?
Вы правы насчёт второго
Вы правы насчёт второго изображения. Я о нём не знал.
Без него вполне можно обойтись, к тому же, я не знаю как правильно с ним работать.
А всё, что я говорил выше относилось только к крупным пикселам.
Если вернуться обратно к DNG,
Если вернуться обратно к DNG, то второе изображение DNG конвертер кладет во второй sample per pixel.
Что прикалывает, да.
Давайте вернёмся к матрице
Давайте вернёмся к матрице EXR, с которой началось обсуждение.
Там тоже есть второе изображение, и в DNG оно тоже кладётся во второй sample.
Но оно такой же яркости, как и первое.
Хотя его тоже можно игнорировать, и работать как с обычным байером.
Но если его использовать, можно увеличить разрешение в два раза.
Оно разной яркости, в
Оно разной яркости, в зависимости от настроек камеры.
Но да, конечно, можно использовать для увеличения разершения, я с этим и не спорю.
Да. Они одинаково
Да. Они одинаково чувствительные. Ео у них разные размеры диафрагм. Поэтому на "маленькие" попадает в ~2^3.9 меньше света за одинаковое время экспозиции.
Это поворот шаблона, а не
Это поворот шаблона, а не матрицы. Повернутую матрицу технологически невозможно на степпере изготовить.
Из поворота шаблона никак не следует, что качество при двойном повороте ради сведения задачи к предыдущей не пострадает.
Никакого двойного поворота
Никакого двойного поворота никто не делает. Это бессмысленно.
И, как Вы правильно заметили, ведёт к потере качества.
Поворот делается только один. И обойтись без него не получится.
Dcraw (и, судя, по косвенным
Dcraw (и, судя, по косвенным признакам, Capture One) делает два поворота, как я и написал выше (где именно)
Первый - чтобы из поколоночной ориентации паттерна сделать байеровский (с зелеными не друг под другом) и применить обычный байеровский же интерполятор (с корреляциями между каналами и вот этим всем). Второй - чтобы развернуть обратно ну и заодно поправить aspect ratio.
По сути Алексей сказал. А я
По сути Алексей сказал. А я добавлю вот что - камеры Fuji нигде практически нормально не поддержаны. Ни старые, ни новые. Fuji нечто выпустила, маркетинг об этом трубит. Пользователи верят легендам о повернутых матрицах - а там сенсоры Сони, вполне себе обычные.