Провел эксперимент со своим epson stylus r1900. Привык печатать на нем на 300 ppi. Оказалось, что данное разрешение выдает крайне неприглядный результат. Понравились результаты на 240 и на 250. В первом случае получал выбитые светлые полосы, во втором выбитые темные полосы. Решил подобрать удачное промежуточное значение, в результате разрешение 246 оказалось идеальным. Ни намека на полосы, высокая четкость. Неожиданное число.
Точно "долгим" способом и не получить пожалуй. У меня в итоге вышло 1.054688 1.000000 1.069336 1.000000. Не знаю насколько допустимо, но тоже доволен хотя бы таким результатом.
для 400D была та же ерунда
в итоге приблизительно установил "долгим" способом (на самом деле от силы на 5 мин делов). не точно 1.000, но мне пока и полученного результата хватит
dcrawMS -w -v -h IMG_2619.CR2
Loading Canon EOS 450D image from IMG_2619.CR2 ...
Scaling with darkness 1023, saturation 14605, and
multipliers 2.137695 1.000000 1.393555 1.000000
Converting to sRGB colorspace...
Writing data to IMG_2619.ppm ...
Хорошо, можно рассматривать зелёные каналы как два, но с меньшей плотностью и худшим разрешением каждый. В этом случае они вообще не отличаются от красного и синего. Понятно, что сигналы в каналах разного цвета разные. Тогда естественно, что в разных каналах будут разные отношения сигнала в канале к шуму в канале. Это банально и обсуждать тут нечего. Если дело только в этом, то отношение общего сигнала к шуму в одном канале должно быть одинаково для всех каналов. Так и абсолютное значение шумов во всех каналах должно быть одинаковым. Дробовых шумов в полупроводниках не видно, это не ФЭУ, значит и электрические шумы в каналах не различаются и не зависят от фильтров перед ними.
Вы сами привели случай (лампы накаливания), когда сигнал в красном канале больше сигнала в зелёном. Это значит, что применение пурпурного фильтра ограничено только случаями, когда зелёный сигнал превалирует и над красным и над синим. Т.е. для каждого спектрального распределения излучения освещения желателен свой выравнивающий фильтр, а создатели матрицы ориентируются на некоторое статистическое спектральное распределение или те распределения, которые могут встречаться. Я часто снимаю закаты и восходы, особенно в горах. Для них характерны как раз пурпурные оттенки (комбинация красных солнечных лучей прошедших толстый слой атмосферы и синего света рассеянного чистым небом).
Зеленых каналов два - и они рассматриваются по отдельности, тем более что в некоторых камерах два разных зеленых канала.
А разный уровень сигнал/шум по той тривиальной причине, что разный уровень сигнала. А разный уровень сигнала - по той причине, что
а) плотность красного фильтра большая, иначе будут проблемы при искусственном освещении, где красной составляющей очень много.
б) чувствительность кремния к синему - маленькая.
Со второй проблемой можно бороться, уменьшая чувствительность (повышая плотность фильтров) красного и зеленого каналов, но это ведет к общему уменьшению сигнала (т.е. росту шумов), что тоже ничего хорошего.
А почему разные каналы шумят пo-разному? Ведь электрически они не отличаются. Различаются числом пикселей (плотность зелёных в 2 раза выше). Значит, физическое разрешение в подрешётке красных и синих - ниже. Дальше всё определяется механизмом интерполяции. Если он вытягивает разрешение красного и синего, то вытягивает и их шумы. В телевидении разделены яркостный канал и цветностные. Причём, яркостный значительно шире по частотной полосе, т.е. все мелкие детали там, а цвета они не имеют. Ничего, глаз глотает.
Есть случаи, когда пурпурный фильтр не годится. Так на закате ограничение может наступить в красных лучах раньше, чем в зелёных. А если в кадре синее небо, но нет облаков или снега, то ограничение может быть и в синем. При передержке неба оно частенько "зеленеет" (синий обрезан), прежде чем совсем обесцветиться.
Спасибо. Немного странно, что процессор более сложную операцию делает быстрее, чем простую. Но вполне может быть, они заточены на вполне определённый набор операций. Если доберусь когда-нибудь в программировании до этого места, то объясню точно. :)
1.) У фильтров тоже есть недостатки. Они редко имеют то же оптическое качество, что и хороший объектив. 3 фильтра это уже 6 новых оптических поверхностей. Если это исключительно шнайдеровские (B&W) фильтры с наилучшим многослойным просветлением, то их отрицательное влияние будет меньше, но суммарная цена приблизится к стоимости объектива.
2.) Полярик искажает цвет неба, причём только перпендикулярно солнечным лучам (по лучам и против небо не меняется). Пятнистость неба сильно заметна на широком угле и панорамах. Исправлять потом трудно.
3.) Вместо бленды лучше поставить камеру на штатив и автоспуск, а самому стать в паре метров от неё, закрыв солнце рукой (тень от руки ложится на переднюю линзу). Так можно поступать даже когда солнце в кадре. Но тогда придётся комбинировать 2 кадра - с рукой и без.
4.) Два кадра с эксповилкой можно объединять не только маской прозрачности. Чтобы избежать каши в движущейся листве, можно воспользоваться функцией Blending, которую фотошоп использует для объединения кадров панорам. Там очень умно проводится граница между кадрами, так, что важные предметы не разрезаются.
Увы, там ничего лучше не стало. Цветовые профили не используются при отображении рабочего стола, окошек и иконок на нём. Некоторые инструменты, вроде встроенного просмотрщика изображений, вроде, пытается использовать цветовой менеджмент, но криво. Из браузеров прекрасно поддерживает профили Огнелис. Там я использую для этого специальный плагин.
Ну смотрите что получается:
- 16-битных целых, в-общем, маловато, не хватает точности при многостадийной обработке. 16-битных плавающих хватило бы (при логарифмическом кодировании), но процессор такие данные не поддерживает, а софтверная поддержка будет медленной.
- 24-битных целых процессор не поддерживает, см. выше про библиотеки.
- 32-битных целых и 32-битных float - достаточно по точности.
Только вот с 32-битными float современный процессор (если его правильно использовать) работает быстрее, чем с 32-битными целыми.
Вывод: надо работать в плавучке. Никакого выигрыша по скорости/памяти от 32-битных целых нет, а проигрыш (в виде большой относительной ошибки в районе нуля) - есть.
ACR и Bridge очень удобны, когда надо перелопатить кучу фотографий с одного события, свадьбы например. Делать все очень "правильно" смысла нет, тот набор, что предлагает ACR сейчас очень неплох и почти что достаточен. Да, это поток, но за правильную красоту никто не будет платить. Для единичных файлов, вроде пейзажа -- да, тут можно себе позволить потратить время.
Линейные, это полученные аффинным преобразованием исходной системы координат. В данном случае, помножением на матрицу. То что зрение не линейно, не мешает производить колориметрические вычисления и получать точные результаты. В колориметрических системах RGB и XYZ сигналы складываются линейно. Собственно говоря, колориметрия основана на кривых сложения стандартного колориметрического наблюдателя.
А знаете, возразить я сейчас не сумею. Вы ссылаетесь на код на С, а как раз его синтаксисом я не владею. Быстрые вещи писал на Паскале, используя ассемблерные вставки для часто исполняемых функций. В принципе, это проверяется. В код можно поставить таймер, а проблемные участки для большей точности ещё и в цикл загнать. Обычно оптимизировал скорость так.
Отвлекаясь от возможностей конкретных процессоров, существует оптимальная разрядность для любых вычислений. Избыточная точность - это лишние вычисления. Плавающая точка это и есть избыточное решение на все случаи жизни. Хотя, кажется и в С есть выбор разрядности для плавающей точки. Но малые разрядности всё равно обрабатываются в то же число тактов, что и большие, естественные для процессора.
Недавно меня попросили рассказать про две вещи - Adobe Bridge и Adobe Camera RAW. А я не пользуюсь ни тем ни другим. Ну не нравятся они мне, конкретные причины перечислять долго. Если конвертером пользовался, то Бриджем - никогда. Почитал книжку Скотта Келби справочник по фотошопу. Написано очень живо и интересно, но чем дольше читал, тем больше приходил в недоумение. Выходит, что конвертер пытается подменить собой фотошоп, но делает это непрофессионально, на уровне, который не требует от пользователя серьёзных знаний. Вот как в предыдущем сообщении - мечта подвигать движки и получить "красиво". Получится субъективность. Маргулис с другого полюса. Чтобы он поменял хоть что-то, он должен точно знать, что и зачем он делает. Его позиция мне импонирует. А его классификация назначения конвертеров более чем актуальна.
Интересно пожелание редактирования яркости отдельно от цветности. Разумеется, демозаику придётся делать в цветах сенсоров, а вот всё остальное можно делать и в других цветовых пространствах. В принципе, яркость и цветность разделены в системе LAB. Но для обработки она не очень удобна. Получается довольно странная ситуация - обработка ведётся либо в аппаратных цветах RGB, (все привыкли, а ведь это страшно неестественно), либо в LAB (довольно сложна для расчётов). А, что, в промежутке ничего нет? Выводить на экран надо RGB в соответствии с профилем монитора, печатать с профилем принтера и чернил, а сохранять в sRGB или Адобе RGB. Раз так часто надо пересчитывать цвет, то почему бы не обрабатывать в пространстве, где светлота отложена только по одной из осей координат. Годится и колориметрическая система XYZ (светлота по Y), но цветность можно сделать и более интуитивно понятной. При этом система получается линейной относительно RGB, и не такой сложной и неестественной как LAB. Надо подумать.
сегодня, при тотальном распространении процессоров с векторными операциями (SSE, AVX), ваши тезисы не вполне верны:
Операции с плавающей точкой не медленнее, чем с целыми. Те же самые 1-3 SSE операции на такт, в один SSE-вектор влезают 4 плавающих (32 бит) или 4 целых.
В конкретном случае AVX они могут быть и быстрее т.к. типичная AVX-операция обрабатывает 8 плавающих значений за такт, а целых - только 4.
Да и в SSE некоторые операции (HADDPS/PD, например, но не только они) есть для плавающей точки, но не реализованы для целых. По непонятной мне причине, целочисленные операции в SSE/AVX - более бедные.
Так как вы предлагаете пользоваться 32-битными целыми, то об экономии памяти речь, очевидно, не идет. В этом случае никакого выигрыша у целых чисел просто нет. При этом, у плавающей точки одинаковая относительная точность по всему диапазону (вполне достаточная для целей imaging), а у целых - одинаковая абсолютная, избыточная на верхней границе диапазона и, возможно, недостаточная на нижней.
Вопрос производительности плавающей точки/целых чисел я тут, совершенно случайно, исследовал для целей imaging. В конкретном приложении к матричному цветовому преобразованию. Смотрите тут: О legacy и форматах данных и далее там же по тегу Программирование. Вкратце вывод такой: самые быстрые реализации (этого конкретного алгоритма) будут или с haddps, или с dpps, а этих операций для целых чисел процессор просто не поддерживает. И эти реализации получаются в 7 раз быстрее того, что делает C-компилятор для целых чисел.
Очень интересный тест! Пусть синтетический и далёкий от реального изображения. Зато он позволяет анализировать и сравнивать разные методы интерполяции. На реальном изображении это свалится в сплошную субъективщину.
Особенно понравились результаты тестов проприетарных конвертеров. До этого я слышал мнения фотографов о том, что Capture One предпочтителен для макро, так как даёт большую резкость. Вы реально показали, что у него свой собственный метод интерполяции. И очень не плохой.
Все способы дают цветной муар. Естественно. Но интересно, что как у Capture One, так и у метода AMaZE минимальна окраска расходящихся лучиков. Да, есть у Capture One пурпурное пятно (у других не лучше, но не так заметно потому, что у других пурпур зелёным разбавлен), зато отдельные полосочки окрашены меньше. Получается, что он даёт сбой на достаточно протяженных участках с периодической структурой (пурпурное пятно), но лучше отрабатывает нерегулярные детали. Это значит, что и в случае с мелкой галькой на берегу (там нет регулярной периодической структуры) он справится лучше. Это же в большой степени относится и к интерполяции AMaZE.
Приведённые иллюстрации хорошо показывают недостаточность точности целочисленных вычислений. Но пропущен очень важный момент: не указана разрядность целого числа. На самом деле, компьютер работает только с целыми числами. В случае с плавающей точкой он вынужден оперировать с целым набором целых чисел, вместо одного. Это медленно, что справедливо отмечено в статье. Но при этом не упомянут ещё другой недостаток. Массивы данных с плавающей точкой занимают гораздо больше компьютерной памяти, чем массивы целых чисел. Для ускорения вывода графики на экран частенько требуется буферизация, т.е. приходится держать в памяти несколько вариантов изображений. При этом чрезвычайно важна их компактность.
Вообще, я не могу понять, почему точности целого числа может не хватать в любых вычислениях? Все компьютеры сейчас, как минимум 32-битные, т.е. процессор в любом случае оперирует набором из 32 бит, даже когда из них используется только один :). По крайней мере, работа с 32-битными целыми ничуть не медленнее, чем с меньшей разрядностью. Понятно, что 8 бит для обработки изображений мало, но как может не хватать 32 бита, мне не понятно. На самом деле, можно работать и с 64-битными целыми числами, если будет хоть один стимул для этого.
В целых числах вычисления быстрее, память расходуется экономней. Требуется только определить оптимальную разрядность представления целого числа. В целых числах программировать труднее. Я бы сказал, что программирование в действительных числах вместо целых может быть полезно для программистов затрудняющихся оптимизировать свой код на низком уровне. Это удобный способ, чтобы не думать об оптимизации совсем и решить свои проблемы за счёт пользователя, его времени и его компьютерной памяти.
Объясните, что вы понимаете под контрастностью - и из объяснения будет очевидно, как ее рассчитывать.
Лично мне кажется, что без учета характера изображенного объекта такой расчет невозможен. Ну вот представьте, что у вас есть два снимка
- два серых квадратика с разностью в стоп (2 раза) по яркости
- два серых квадратика с разностью в три стопа (8 раз) по яркости
И, допустим, эти два снимка выглядят одинаково т.е. первый снимали на "контрастный материал", а второй - на "вялый". Дальше то что? Если мы считаем только по снимкам, то результат тоже должен бы быть одинаковым, но это противоречит здравому фотографическому смыслу.
При этом сравнение двух снимков/вариантов одной сцены - имеет смысл, но в этом случае расчет сравнительной контрастности - тривиален.
Общее
Начиная с 0.13.6 LibRaw собирается 2010-м Visual Studio. Т.е. скорее всего, имеет место быть несовместимость рантаймов: собранное хочет open/stat/итп от 2010-й, а вы линкуетесь с 2008-м.
Лучше - собирайте сорцовую версию прямо в рамках своего проекта, благо и .pro-файлы (для Qt/qmake) и vcproj/sln (для Visual Studio) в комплекте имеются.
Частности:
IO_ERROR, судя по коду, может вылезти в куче случаев:
_stati64() вернул ошибку
- файл не открылся
- действительно ошибка IO (например, битый файл и указатели в TIFF указывают в кукурузу)
Планов на улучшение/изменение постпроцессинга в ближайших версиях - нет (но мы с удовольствием примем contributed-код).
А вот извлечение нескольких RAW-изображений из одного файла (включая и Fuji и мультишот-бэки) - в ближайших планах, в следующей версии или в следующей за ней (в течение лета).
Здравствуйте!
Я являюсь владельцем Fuji S200EXR и с сожалением обнаружил что с RAW файлами этой камеры полноценно не работает ни одна свободная программа, включая последнюю версию dcraw, импортированную в текущем релизе.
Эта камера имеет два набора сенсоров и я не нашёл возможности объединить данные с этих наборов.
В целях и задачах libraw говориться о "генерализации работы со сложными форматами, в частности: RAW-файлы от камер Fuji (с двумя наборами сенсоров)".
Я так понимаю что к S200EXR это тоже относится.
Скажите, пожалуйста, ведётся-ли работа в данном направлении и как скоро можно ждать результатов?
Могу поучаствовать в тестировании или предоставить RAW файлы, снятые в разных режимах.
Вместо того чтобы фотографировать , Вы предлагаете рассматривать 100% , 200% , 300% кроп , находить там микроскопические отличия и радоваться этому ?
Нет уж , оставьте это ботанам и профессионалам !
Смешной Вы человек : каналы , чудес не бывает ... теоретик .
Все мои друзья Canon`исты так же как и Вы живут в фотошопе , а свободное время тратят на теорию фотографии .
Специально для неверующих : зайдите на dpreview и обратите внимание , сколько фотографий Canon требуют постобработки , а сколько - Nikon ? Разница очевидна , никакой теории или пустых словосочетаний и споров . Без обид .
Допустим, чувствительность каналов у Nikon при дневном свете одинакова и пурпурный фильтр не нужен (это не так, но допустим).
В этом случае при лампах накаливания чувствительность по зеленому будет недостаточной, сильно шуметь будет не только синий, но и зеленый. У Никонов это так?
RAW - это возможность получить исходный файл максимального качества, которое может дать камера. Это по уровню детализации снимка, цветопередаче, шумам. Когда хотите получить классные картинки на принтере (и это отдельная проблема) или готовите снимки для издательства необходимо снимать в RAW и с возможно большей глубиной цветности, например, 16 бит. А обрабатывать и корректировать можно файлы любых форматов, которые может открыть ваше ПО.
Почитайте книгу Маргулиса "Photoshop LAB Color Загадка каньона и другие приключения в самом мощном цветовом пространстве". Написано очень доступно и подробно. ПРЕВОСХОДНАЯ работа автора для тех, кто хочет иметь качественные распечатанные снимки на своём принтере!
Вы немножко сложно излагаете. "Системная информация" там в формате EXIF, точно ли вы хотите его сами разбирать?
Что касается битмепа данных с сенсора, то возьмите LibRaw, она вам сделает ровно то, что вы хотите - извлечет данные изображения из файла. Хотите в исходном (RAW) виде, хотите - в обработанном.
Имеется файл .orf, при просмотре его в бинарном формате хочется понять, где какая системная информация в каком байте/бите, есть ли рамка и с какого адреса начинается все-таки информация с пзс и где она заканчивается, а также нужны адреса/описатели начала и конца строки.
В конечном счете нужен файл, представляющий собой матрицу пикселей (в бинарном формате), чтобы можно было осуществить построчное сканирование файла с определением координат всех засвеченных пикселей, при обработке серии изображениий светящейся перемещающейся марки (цвет не важен, больше важна яркость).
это конечно можно попиксельно вручную сделать в olympus studio, но это займет месяцы :(.
Алексей, а решает ли CC30M проблему шума неба\моря в красном канале после наложения его же в режиме Luminosity?
Мой пример, камера D90, снимок нормально проэкспонирован, RPP, Lab -> RGB, накладываю R на все в режиме Luminosity, получаю красный канал: http://pix.am/b5x0.png
Казалось бы, тут вообще обработку по-другому надо делать.
Если у Вас съемка делалать правильно, т.е. с дарками и флетами, то вы берете свою серию снимков, и виртуально делите ее на 4 "слоя" (предполагается, что матрица у вас RGGB):
1) все пиксели, невзирая на цвет - как данные Luminance,
2) только пикселы R - как изображение с R-фильтром снятое с binning 2x2
3) аналогично B
4) примерно так же G, только либо надо считать, что биннинг делается 2x1, либо 2x2 и усреднять.
После этого все отдельные кадры калибруются и складываются как обычно, и из них собирается композиция LRGB (L при этом "сглаживается" при применении калибровки с флетами). С точки зрения корректной фотометрии получится фигня, но эстетически это лучше, чем билинейная интерполяция "в лоб".
Если хочется еще лучше, то наверное можно R/G/B брать не грубым бинингом, а хитрее. Но и так в принципе нормально.
они и по жизни несовместимы: green_matching ожидает байеровский паттерн (1 компонент из 4 в каждом пикселе), а при -h все уже совмещено. Зеленый при этом усредняется и нелокальное усреднение не нужно.
В документации про битмаск не написано:
===
Ориентация изображения (0 - не требует поворота, 3 - требуется поворот на 180, 5 - 90 градусов против часовой стрелки, 6 - 90 градусов по часовой).
===
А битмаск это по коду, т.е. можно и отзеркалить, например.
Да, в астрофото картинки совсем иные чем в фотографии. Вероятно вы правы, что нужно изобретать соответствующий фильтр. Но странно, что все программы астрофото выполняют дебайеризацию, похоже что почти все билинейную. Разве что еще встречал "modified Kimmel" и "V.N.G Color Correcttion" (софт Fitswork). Откопать подробности, увы, пока не смог.
О! Не знал, что это битмаск. По простоте душевной полагал, что это просто угол поворота в единицах пи пополам. Посыпаю главу пеплом и иду читать документацию :)
Тут вот какое дело: в (художественной) фотографии совершенно другие требования: шум в "низкочастотной" части изображения (например: небо) омерзителен, в среднечастотной полезно усиливать границы, а в высокочастотной области (текстура трикотажа) можно повысить контраст, дорисовав любые детали (в меру, конечно, не надо ярких белых точек).
Я боюсь, что для ваших задач проще применить фильтр под вашу задачу, а не фотографический.
Почему нестандартное?
Ну то есть камера выдает вообще CameraOrientation забыл какой, а LibRaw преобразует его в flip.
А flip - это битмаск:
4 - поменять местами ширину и высоту
2 - отзеркалировать относительно горизонтальной оси
1 - отзеркалировать относительно вертикальной
(применяется именно в таком порядке)
5 - это поворот на 270.
Речь не о желании ротации, а о том что камера выдает нестандартное значение raw->sizes.flip=5 (ИМХО, это число должно быть в интервале от 0 до 3) и о том, как это значение обрабатывать.
Интерполяция выполняет роль пространственного фильтра, сглаживая уменьшает высокочастотную составляющую. Шум матрицы давится сильнее чем менее высокочастотный сигнал звезд.
13 December, 2010 - 11:38 — Ivan Uskov (not verified)
У меня несколько посторонний вопрос возник - а какова технология изготовления DNG? Есть некая тулза или просто производилась "пересадка данных" в некий существующий валидный DNG-файл?
Да, любая интерполяция порождает артефакты, каждый алгоритм свои. В астрофото без интерполяции достигается максимальное разрешение, но, увы, и шумы при этом велики. Интерполируя можно потеряв немного в разрешении уменьшшить уровень шума, но приобрести артефакты. Вопрос в том какой алгоритм лучше именно для астрофото.
В-общем, это действительно камера дурит, для двух кадров выдан разный CameraOrientation.
Править что-то в LibRaw считаю невозможным, сломается авторотация у всех пользователей.
Правильный (по инструкции) способ передать в LibRaw ваше желание о ротации - это не sizes.flip править, а params.user_flip
Упс, первый пост и сюда таки запостился, прошу прощения за дублирование оного блоге.
Насчет двух сигналов и интермодуляции - это все же немного не то. При проверке
интермодуляционных искажений частоты сигналов все же располагаются до той самой
частоты Найквиста. А я говорил о том, что а аудио старательно избегают диапазона
выше этой частоты.
А вот в случае с изображением почему-то мало того, что мы ищем детали с пространственной
частотой равной той самой частоте Найквиста, которая кстати, в случае байера еще и
по сути различна для цветовой и яркостной составляющей (и для R и G,B тоже), так еще
и убираем АА-фильтр совсем и потом боремся с последствиями.
Оно конечно понятно - на нерегулярных структурах муара вроде и не заметно, но... детализации
там получается несколько "условная", т.е. выглядит это как детали, а на практике это то,
что додумал алгоритм интерполяции.
Мне когда-то попдался хороший пример на котором показан фрагмент кадра с мелкой
серой галькой (на кадре она получилось как размером в несколько пикселей каждый камень)
снятый на камеру с АА фильтром и без. На камере без фильтра камни аккуратненько раскрашены
в разные цвета, хотя явно выраженного регулряного муара вроде и не видно.
Впрочем я безусловно согласен с тем, что раз уж у демозаика есть шанс столкнуться с неудобными данными, то не помешает знать - как он на них отреагирует, ну или хотя бы знать "область применимости"
того или иного демозаика.
Во-первых, подать в стереоусилитель два разночастотных ВЧ-сигнала в два канала и проверить интермодуляцию - это первейшее дело. Это что касается аналогии с аудиоаппаратурой.
Во-вторых, далеко не все камеры имеют anti-alias фильтр. Не имеют его многие (все?) среднеформатные задники и некоторые "узкоформатные" камеры (Кодаки, Лейки). И картинка с 13-Mp Кодака по уровню детализации близка к 20Mp-камере с фильтром, ценой легкости возникновения муара.
В-третьих, муар получается и на размытой картинке.
Все же подобные "издевательства" над алгоритмами несколько "нечестные" - мы пытаемся алгоритмам подсунуть данные на которые он даже и не должны быть расчитаны. Ведь математика говорит что нельзя с байера требовать попиксельной резкости и контраста. Мы же не пытаемся цифровому аудиотракту с частотой дискретизации АЦП 44кГц скармливать частоты выше 22кГц? Причем не пытаемся той же причине, по которой на байеровскую матрицу (равно как и фовеон) не должна попадать картинка не прошедшая через ФНЧ - АА фильтр.
Причем непонятно как судить по результатам о качестве алгоритма. Вот например то, что у AMaZE меньше цветных артефактов говорит о том что он точнее восстаналивает яркостную компоненту или о том что он успешнее "портит" цветовую? И что важнее?
Да, точность арифметики конечно важна, хорошо себя показавшие LMMSE/AMaZE - они float.
А мишени я всякие буду делать, процедура вроде налажена. Я начал, собственно, с Siemens Star, но на ней таких душераздирающих эффектов (как на резкой мишени) нету.
Весьма интересно!
Я естественно сразу сравнил заблуреный DNG с RPP (VCD и AHD) и разница даже больше чем я ожидал. Т.е. из того муара что мы получаем солидная часть идет не от алгоритма а от точности арифметики. Чем ближе к центру, тем хуже все становится.
И в плане пожелания - если нетрудно добавь еще 3 таких же звезды с шириной в 2, 3 и 4 пиксела в те DNG!
Ну так мы аппаратно калибруем (линеаризуем) монитор и, той же программой, строим его описание (уже калиброваного), которое и отдаем операционной системе.
Объясните, пожалуйста, схему управления цветом при аппаратной калибровке монитора. Или скажите, где можно почитать об этом.
Проблема в том, что пока мы характеризуем цветопередачу монитора icc профилем, все очевидно. Т. е. у операционной системы есть профиль монитора, и она его предявляет всем программам, которые способны им пользоваться. Но если я откалибрую монитор аппаратно и загружу профиль в него, то откуда операционная система будет знать характеристики монитора? И, соответственно, как в этом случае программы могут правильно показывать изображения?
за счет шума она будет загибаться, если я правильно представляю, случайно, т.к. природа шума случайна. Т.е. кривая в тенях будет содержать что-то вроде помех, а не явно выраженную зависимость? И тогда непонятно как такие "помехи" корректировать?
Если мы удваиваем экспозицию (и не попадаем в насыщение) - удваивается сигнал (после линеаризации т.е. вычитания черного/dark current).
Т.е. - пропорционален энергии.
Как в двух словах рассказать про "цветовую матрицу" - не знаю. Задам направление для рассуждений: представим себе два цветных монитора с разным цветом чистых цветов (R,G,B). Очевидно, что при подаче на них одинакового сигнала (скажем, 70, 133, 250) - цвет получится разным. И есть обратная задача - какой сигнал подать на второй монитор, чтобы получить цвет близкий/идентичный к первому.
а всё-таки сигнал пропорционален энергии или её логарифму? И расскажите, пожалуйста, нубу, что за цветовая матрица? Из полученных TIFF-файлов вынимаю только красный канал.
автобусные туры из одессы: туры из Одессы, Адрес: ул. Польская, 17, Одесса.. . Терра-Евролекс - особые конфигурации деревянные оконные конструкции в строительстве. . на немецких станках диван делаем
Canon 7D, установка по белому кадру:
multipliers 1.000000 1.000978 1.000978 1.000978
Спасибо , посмотрел , думаю Вы правы - фильтр показал свою эффективность в практических тестах .
Благодарю за статью , все доходчиво и понятно .
У меня на D700 не получается.
Кто подскажет что сделать?
И что значит "вычитание нейтральной точки"
Заранее благодарю и с Наступающим всех)
Провел эксперимент со своим epson stylus r1900. Привык печатать на нем на 300 ppi. Оказалось, что данное разрешение выдает крайне неприглядный результат. Понравились результаты на 240 и на 250. В первом случае получал выбитые светлые полосы, во втором выбитые темные полосы. Решил подобрать удачное промежуточное значение, в результате разрешение 246 оказалось идеальным. Ни намека на полосы, высокая четкость. Неожиданное число.
Точно "долгим" способом и не получить пожалуй. У меня в итоге вышло 1.054688 1.000000 1.069336 1.000000. Не знаю насколько допустимо, но тоже доволен хотя бы таким результатом.
для 400D была та же ерунда
в итоге приблизительно установил "долгим" способом (на самом деле от силы на 5 мин делов). не точно 1.000, но мне пока и полученного результата хватит
dcrawMS -w -v -h IMG_2619.CR2
Loading Canon EOS 450D image from IMG_2619.CR2 ...
Scaling with darkness 1023, saturation 14605, and
multipliers 2.137695 1.000000 1.393555 1.000000
Converting to sRGB colorspace...
Writing data to IMG_2619.ppm ...
Во как
Спасибо, поправил.
Там вроде вторая редакция выложена, вполне возможно, что и часть моих замечаний тоже устарела.
Ссылочки устарели на сайте Шадрина: http://shadrin.rudtp.ru/Personal/Shadrin_Margulis_my.htm
Камера (для которой работает крышечка или засветка) - смотрит в значения в файле, а не в метаданные.
а нельзя просто поправить коэффициенты в raw файле 1 1 1 1 и скормить его камере?
- 5D MarkII, дневной свет
- он же, лампы накаливания
А шумовая составляющая (кроме "фотонного" пуассоновского шума) - примерно одинаковая.Хорошо, можно рассматривать зелёные каналы как два, но с меньшей плотностью и худшим разрешением каждый. В этом случае они вообще не отличаются от красного и синего. Понятно, что сигналы в каналах разного цвета разные. Тогда естественно, что в разных каналах будут разные отношения сигнала в канале к шуму в канале. Это банально и обсуждать тут нечего. Если дело только в этом, то отношение общего сигнала к шуму в одном канале должно быть одинаково для всех каналов. Так и абсолютное значение шумов во всех каналах должно быть одинаковым. Дробовых шумов в полупроводниках не видно, это не ФЭУ, значит и электрические шумы в каналах не различаются и не зависят от фильтров перед ними.
Вы сами привели случай (лампы накаливания), когда сигнал в красном канале больше сигнала в зелёном. Это значит, что применение пурпурного фильтра ограничено только случаями, когда зелёный сигнал превалирует и над красным и над синим. Т.е. для каждого спектрального распределения излучения освещения желателен свой выравнивающий фильтр, а создатели матрицы ориентируются на некоторое статистическое спектральное распределение или те распределения, которые могут встречаться. Я часто снимаю закаты и восходы, особенно в горах. Для них характерны как раз пурпурные оттенки (комбинация красных солнечных лучей прошедших толстый слой атмосферы и синего света рассеянного чистым небом).
Зеленых каналов два - и они рассматриваются по отдельности, тем более что в некоторых камерах два разных зеленых канала.
А разный уровень сигнал/шум по той тривиальной причине, что разный уровень сигнала. А разный уровень сигнала - по той причине, что
а) плотность красного фильтра большая, иначе будут проблемы при искусственном освещении, где красной составляющей очень много.
б) чувствительность кремния к синему - маленькая.
Со второй проблемой можно бороться, уменьшая чувствительность (повышая плотность фильтров) красного и зеленого каналов, но это ведет к общему уменьшению сигнала (т.е. росту шумов), что тоже ничего хорошего.
А почему разные каналы шумят пo-разному? Ведь электрически они не отличаются. Различаются числом пикселей (плотность зелёных в 2 раза выше). Значит, физическое разрешение в подрешётке красных и синих - ниже. Дальше всё определяется механизмом интерполяции. Если он вытягивает разрешение красного и синего, то вытягивает и их шумы. В телевидении разделены яркостный канал и цветностные. Причём, яркостный значительно шире по частотной полосе, т.е. все мелкие детали там, а цвета они не имеют. Ничего, глаз глотает.
Есть случаи, когда пурпурный фильтр не годится. Так на закате ограничение может наступить в красных лучах раньше, чем в зелёных. А если в кадре синее небо, но нет облаков или снега, то ограничение может быть и в синем. При передержке неба оно частенько "зеленеет" (синий обрезан), прежде чем совсем обесцветиться.
Спасибо. Немного странно, что процессор более сложную операцию делает быстрее, чем простую. Но вполне может быть, они заточены на вполне определённый набор операций. Если доберусь когда-нибудь в программировании до этого места, то объясню точно. :)
1.) У фильтров тоже есть недостатки. Они редко имеют то же оптическое качество, что и хороший объектив. 3 фильтра это уже 6 новых оптических поверхностей. Если это исключительно шнайдеровские (B&W) фильтры с наилучшим многослойным просветлением, то их отрицательное влияние будет меньше, но суммарная цена приблизится к стоимости объектива.
2.) Полярик искажает цвет неба, причём только перпендикулярно солнечным лучам (по лучам и против небо не меняется). Пятнистость неба сильно заметна на широком угле и панорамах. Исправлять потом трудно.
3.) Вместо бленды лучше поставить камеру на штатив и автоспуск, а самому стать в паре метров от неё, закрыв солнце рукой (тень от руки ложится на переднюю линзу). Так можно поступать даже когда солнце в кадре. Но тогда придётся комбинировать 2 кадра - с рукой и без.
4.) Два кадра с эксповилкой можно объединять не только маской прозрачности. Чтобы избежать каши в движущейся листве, можно воспользоваться функцией Blending, которую фотошоп использует для объединения кадров панорам. Там очень умно проводится граница между кадрами, так, что важные предметы не разрезаются.
Увы, там ничего лучше не стало. Цветовые профили не используются при отображении рабочего стола, окошек и иконок на нём. Некоторые инструменты, вроде встроенного просмотрщика изображений, вроде, пытается использовать цветовой менеджмент, но криво. Из браузеров прекрасно поддерживает профили Огнелис. Там я использую для этого специальный плагин.
Ну смотрите что получается:
- 16-битных целых, в-общем, маловато, не хватает точности при многостадийной обработке. 16-битных плавающих хватило бы (при логарифмическом кодировании), но процессор такие данные не поддерживает, а софтверная поддержка будет медленной.
- 24-битных целых процессор не поддерживает, см. выше про библиотеки.
- 32-битных целых и 32-битных float - достаточно по точности.
Только вот с 32-битными float современный процессор (если его правильно использовать) работает быстрее, чем с 32-битными целыми.
Вывод: надо работать в плавучке. Никакого выигрыша по скорости/памяти от 32-битных целых нет, а проигрыш (в виде большой относительной ошибки в районе нуля) - есть.
Вычислять - можно. Редактировать неудобно, вспомните о кривых в RGB - ужас же.
ACR и Bridge очень удобны, когда надо перелопатить кучу фотографий с одного события, свадьбы например. Делать все очень "правильно" смысла нет, тот набор, что предлагает ACR сейчас очень неплох и почти что достаточен. Да, это поток, но за правильную красоту никто не будет платить. Для единичных файлов, вроде пейзажа -- да, тут можно себе позволить потратить время.
Линейные, это полученные аффинным преобразованием исходной системы координат. В данном случае, помножением на матрицу. То что зрение не линейно, не мешает производить колориметрические вычисления и получать точные результаты. В колориметрических системах RGB и XYZ сигналы складываются линейно. Собственно говоря, колориметрия основана на кривых сложения стандартного колориметрического наблюдателя.
А знаете, возразить я сейчас не сумею. Вы ссылаетесь на код на С, а как раз его синтаксисом я не владею. Быстрые вещи писал на Паскале, используя ассемблерные вставки для часто исполняемых функций. В принципе, это проверяется. В код можно поставить таймер, а проблемные участки для большей точности ещё и в цикл загнать. Обычно оптимизировал скорость так.
Отвлекаясь от возможностей конкретных процессоров, существует оптимальная разрядность для любых вычислений. Избыточная точность - это лишние вычисления. Плавающая точка это и есть избыточное решение на все случаи жизни. Хотя, кажется и в С есть выбор разрядности для плавающей точки. Но малые разрядности всё равно обрабатываются в то же число тактов, что и большие, естественные для процессора.
Системы, линейные относительно RGB - будут нелинейными относительно зрения.
В чем и проблема.
Недавно меня попросили рассказать про две вещи - Adobe Bridge и Adobe Camera RAW. А я не пользуюсь ни тем ни другим. Ну не нравятся они мне, конкретные причины перечислять долго. Если конвертером пользовался, то Бриджем - никогда. Почитал книжку Скотта Келби справочник по фотошопу. Написано очень живо и интересно, но чем дольше читал, тем больше приходил в недоумение. Выходит, что конвертер пытается подменить собой фотошоп, но делает это непрофессионально, на уровне, который не требует от пользователя серьёзных знаний. Вот как в предыдущем сообщении - мечта подвигать движки и получить "красиво". Получится субъективность. Маргулис с другого полюса. Чтобы он поменял хоть что-то, он должен точно знать, что и зачем он делает. Его позиция мне импонирует. А его классификация назначения конвертеров более чем актуальна.
Интересно пожелание редактирования яркости отдельно от цветности. Разумеется, демозаику придётся делать в цветах сенсоров, а вот всё остальное можно делать и в других цветовых пространствах. В принципе, яркость и цветность разделены в системе LAB. Но для обработки она не очень удобна. Получается довольно странная ситуация - обработка ведётся либо в аппаратных цветах RGB, (все привыкли, а ведь это страшно неестественно), либо в LAB (довольно сложна для расчётов). А, что, в промежутке ничего нет? Выводить на экран надо RGB в соответствии с профилем монитора, печатать с профилем принтера и чернил, а сохранять в sRGB или Адобе RGB. Раз так часто надо пересчитывать цвет, то почему бы не обрабатывать в пространстве, где светлота отложена только по одной из осей координат. Годится и колориметрическая система XYZ (светлота по Y), но цветность можно сделать и более интуитивно понятной. При этом система получается линейной относительно RGB, и не такой сложной и неестественной как LAB. Надо подумать.
сегодня, при тотальном распространении процессоров с векторными операциями (SSE, AVX), ваши тезисы не вполне верны:
Так как вы предлагаете пользоваться 32-битными целыми, то об экономии памяти речь, очевидно, не идет. В этом случае никакого выигрыша у целых чисел просто нет. При этом, у плавающей точки одинаковая относительная точность по всему диапазону (вполне достаточная для целей imaging), а у целых - одинаковая абсолютная, избыточная на верхней границе диапазона и, возможно, недостаточная на нижней.
Вопрос производительности плавающей точки/целых чисел я тут, совершенно случайно, исследовал для целей imaging. В конкретном приложении к матричному цветовому преобразованию. Смотрите тут: О legacy и форматах данных и далее там же по тегу Программирование. Вкратце вывод такой: самые быстрые реализации (этого конкретного алгоритма) будут или с haddps, или с dpps, а этих операций для целых чисел процессор просто не поддерживает. И эти реализации получаются в 7 раз быстрее того, что делает C-компилятор для целых чисел.
Очень интересный тест! Пусть синтетический и далёкий от реального изображения. Зато он позволяет анализировать и сравнивать разные методы интерполяции. На реальном изображении это свалится в сплошную субъективщину.
Особенно понравились результаты тестов проприетарных конвертеров. До этого я слышал мнения фотографов о том, что Capture One предпочтителен для макро, так как даёт большую резкость. Вы реально показали, что у него свой собственный метод интерполяции. И очень не плохой.
Все способы дают цветной муар. Естественно. Но интересно, что как у Capture One, так и у метода AMaZE минимальна окраска расходящихся лучиков. Да, есть у Capture One пурпурное пятно (у других не лучше, но не так заметно потому, что у других пурпур зелёным разбавлен), зато отдельные полосочки окрашены меньше. Получается, что он даёт сбой на достаточно протяженных участках с периодической структурой (пурпурное пятно), но лучше отрабатывает нерегулярные детали. Это значит, что и в случае с мелкой галькой на берегу (там нет регулярной периодической структуры) он справится лучше. Это же в большой степени относится и к интерполяции AMaZE.
Приведённые иллюстрации хорошо показывают недостаточность точности целочисленных вычислений. Но пропущен очень важный момент: не указана разрядность целого числа. На самом деле, компьютер работает только с целыми числами. В случае с плавающей точкой он вынужден оперировать с целым набором целых чисел, вместо одного. Это медленно, что справедливо отмечено в статье. Но при этом не упомянут ещё другой недостаток. Массивы данных с плавающей точкой занимают гораздо больше компьютерной памяти, чем массивы целых чисел. Для ускорения вывода графики на экран частенько требуется буферизация, т.е. приходится держать в памяти несколько вариантов изображений. При этом чрезвычайно важна их компактность.
Вообще, я не могу понять, почему точности целого числа может не хватать в любых вычислениях? Все компьютеры сейчас, как минимум 32-битные, т.е. процессор в любом случае оперирует набором из 32 бит, даже когда из них используется только один :). По крайней мере, работа с 32-битными целыми ничуть не медленнее, чем с меньшей разрядностью. Понятно, что 8 бит для обработки изображений мало, но как может не хватать 32 бита, мне не понятно. На самом деле, можно работать и с 64-битными целыми числами, если будет хоть один стимул для этого.
В целых числах вычисления быстрее, память расходуется экономней. Требуется только определить оптимальную разрядность представления целого числа. В целых числах программировать труднее. Я бы сказал, что программирование в действительных числах вместо целых может быть полезно для программистов затрудняющихся оптимизировать свой код на низком уровне. Это удобный способ, чтобы не думать об оптимизации совсем и решить свои проблемы за счёт пользователя, его времени и его компьютерной памяти.
Объясните, что вы понимаете под контрастностью - и из объяснения будет очевидно, как ее рассчитывать.
Лично мне кажется, что без учета характера изображенного объекта такой расчет невозможен. Ну вот представьте, что у вас есть два снимка
- два серых квадратика с разностью в стоп (2 раза) по яркости
- два серых квадратика с разностью в три стопа (8 раз) по яркости
И, допустим, эти два снимка выглядят одинаково т.е. первый снимали на "контрастный материал", а второй - на "вялый". Дальше то что? Если мы считаем только по снимкам, то результат тоже должен бы быть одинаковым, но это противоречит здравому фотографическому смыслу.
При этом сравнение двух снимков/вариантов одной сцены - имеет смысл, но в этом случае расчет сравнительной контрастности - тривиален.
Вопрос непонятен. Если насыщенность не поднялась, возможно точка была нейтральной?
Здравствуйте! Интересует вопрос, как определяется точка, насыщенность которой не поднялась после подъема насыщенности на 98-99%?
Общее
Начиная с 0.13.6 LibRaw собирается 2010-м Visual Studio. Т.е. скорее всего, имеет место быть несовместимость рантаймов: собранное хочет open/stat/итп от 2010-й, а вы линкуетесь с 2008-м.
Лучше - собирайте сорцовую версию прямо в рамках своего проекта, благо и .pro-файлы (для Qt/qmake) и vcproj/sln (для Visual Studio) в комплекте имеются.
Частности:
IO_ERROR, судя по коду, может вылезти в куче случаев:
_stati64() вернул ошибку
- файл не открылся
- действительно ошибка IO (например, битый файл и указатели в TIFF указывают в кукурузу)
Интересовала именно сборка фуджевских полукадров в один.
Ну... нет так нет... :(
А для написания кода моих знаний и умений явно недостаточно.
Спасибо за ответ.
Ответ двоякий, и да и нет.
Планов на улучшение/изменение постпроцессинга в ближайших версиях - нет (но мы с удовольствием примем contributed-код).
А вот извлечение нескольких RAW-изображений из одного файла (включая и Fuji и мультишот-бэки) - в ближайших планах, в следующей версии или в следующей за ней (в течение лета).
Здравствуйте!
Я являюсь владельцем Fuji S200EXR и с сожалением обнаружил что с RAW файлами этой камеры полноценно не работает ни одна свободная программа, включая последнюю версию dcraw, импортированную в текущем релизе.
Эта камера имеет два набора сенсоров и я не нашёл возможности объединить данные с этих наборов.
В целях и задачах libraw говориться о "генерализации работы со сложными форматами, в частности: RAW-файлы от камер Fuji (с двумя наборами сенсоров)".
Я так понимаю что к S200EXR это тоже относится.
Скажите, пожалуйста, ведётся-ли работа в данном направлении и как скоро можно ждать результатов?
Могу поучаствовать в тестировании или предоставить RAW файлы, снятые в разных режимах.
Пора тут уже начинать банить за тупость ) Или отключать онанимусов )
Вместо того чтобы фотографировать , Вы предлагаете рассматривать 100% , 200% , 300% кроп , находить там микроскопические отличия и радоваться этому ?
Нет уж , оставьте это ботанам и профессионалам !
Какой-то глупый комментарий от человека совершенно не понимающего о чем написано в статье
Удивительнее всего в этом то, что сами пользователи Nikon используют magenta-фильтры и им нравится:
http://forums.dpreview.com/forums/read.asp?forum=1021&message=27886783
Смешной Вы человек : каналы , чудес не бывает ... теоретик .
Все мои друзья Canon`исты так же как и Вы живут в фотошопе , а свободное время тратят на теорию фотографии .
Специально для неверующих : зайдите на dpreview и обратите внимание , сколько фотографий Canon требуют постобработки , а сколько - Nikon ? Разница очевидна , никакой теории или пустых словосочетаний и споров . Без обид .
Допустим, чувствительность каналов у Nikon при дневном свете одинакова и пурпурный фильтр не нужен (это не так, но допустим).
В этом случае при лампах накаливания чувствительность по зеленому будет недостаточной, сильно шуметь будет не только синий, но и зеленый. У Никонов это так?
Чудес не бывает...
У меня Nikon и у меня нет Ваших типично Canon`овских болячек !
Купите Nikon и не мучайтесь!
RAW - это возможность получить исходный файл максимального качества, которое может дать камера. Это по уровню детализации снимка, цветопередаче, шумам. Когда хотите получить классные картинки на принтере (и это отдельная проблема) или готовите снимки для издательства необходимо снимать в RAW и с возможно большей глубиной цветности, например, 16 бит. А обрабатывать и корректировать можно файлы любых форматов, которые может открыть ваше ПО.
Почитайте книгу Маргулиса "Photoshop LAB Color Загадка каньона и другие приключения в самом мощном цветовом пространстве". Написано очень доступно и подробно. ПРЕВОСХОДНАЯ работа автора для тех, кто хочет иметь качественные распечатанные снимки на своём принтере!
Спасибо, пошла закачка!
Ай-ай, извините, *Win32* не залил на сервер.
Теперь должна работать!
Ссылка на скачивание LibRaw-0.13.3-demosaic-packs-GPL2-GPL3-Win32.zip нерабочая. :(
Вы немножко сложно излагаете. "Системная информация" там в формате EXIF, точно ли вы хотите его сами разбирать?
Что касается битмепа данных с сенсора, то возьмите LibRaw, она вам сделает ровно то, что вы хотите - извлечет данные изображения из файла. Хотите в исходном (RAW) виде, хотите - в обработанном.
Имеется файл .orf, при просмотре его в бинарном формате хочется понять, где какая системная информация в каком байте/бите, есть ли рамка и с какого адреса начинается все-таки информация с пзс и где она заканчивается, а также нужны адреса/описатели начала и конца строки.
В конечном счете нужен файл, представляющий собой матрицу пикселей (в бинарном формате), чтобы можно было осуществить построчное сканирование файла с определением координат всех засвеченных пикселей, при обработке серии изображениий светящейся перемещающейся марки (цвет не важен, больше важна яркость).
это конечно можно попиксельно вручную сделать в olympus studio, но это займет месяцы :(.
Если вы собрали LibRaw с внешними ссылками на lcms2, то вам и ваше приложение придется линковать с lcms2
Если честно, я вопроса не понял.
Это TIFF-файл такой, правда сжатие там своеобразное.
С помощью libraw можно вытащить RAW-данные, собственно последовательность open_file() и unpack() их и вытащит.
О! А как Вы это сделали, нельзя ли конкретнее описать процесс?
Алексей, а решает ли CC30M проблему шума неба\моря в красном канале после наложения его же в режиме Luminosity?
Мой пример, камера D90, снимок нормально проэкспонирован, RPP, Lab -> RGB, накладываю R на все в режиме Luminosity, получаю красный канал:
http://pix.am/b5x0.png
Казалось бы, тут вообще обработку по-другому надо делать.
Если у Вас съемка делалать правильно, т.е. с дарками и флетами, то вы берете свою серию снимков, и виртуально делите ее на 4 "слоя" (предполагается, что матрица у вас RGGB):
1) все пиксели, невзирая на цвет - как данные Luminance,
2) только пикселы R - как изображение с R-фильтром снятое с binning 2x2
3) аналогично B
4) примерно так же G, только либо надо считать, что биннинг делается 2x1, либо 2x2 и усреднять.
После этого все отдельные кадры калибруются и складываются как обычно, и из них собирается композиция LRGB (L при этом "сглаживается" при применении калибровки с флетами). С точки зрения корректной фотометрии получится фигня, но эстетически это лучше, чем билинейная интерполяция "в лоб".
Если хочется еще лучше, то наверное можно R/G/B брать не грубым бинингом, а хитрее. Но и так в принципе нормально.
В 0.12.5 починено
Более того,
они и по жизни несовместимы: green_matching ожидает байеровский паттерн (1 компонент из 4 в каждом пикселе), а при -h все уже совмещено. Зеленый при этом усредняется и нелокальное усреднение не нужно.
Запатчу сегодня-завтра.
Ага,
похоже -h и -G - оказались несовместимы.
Изучу. Файлик не нужен, это на всех входных данных так.
Файлик выложите куда-нибудь на посмотреть, а (дальше можно в личку, если не хочется на всеобщее обозрение).
dcraw_emu.exe -a -H 9 -o 2 -h -f -G -T _IGP9767.DNG > out.file
И падаем в libraw.dll:
roblem signature:
Problem Event Name: APPCRASH
Application Name: dcraw_emu.exe
Application Version: 0.0.0.0
Application Timestamp: 4d49c0d8
Fault Module Name: libraw.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4d49c0d6
Exception Code: c0000005
Exception Offset: 0003cc00
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1049
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Windows7/x64, DNG от Pentax K-7
В документации про битмаск не написано:
===
Ориентация изображения (0 - не требует поворота, 3 - требуется поворот на 180, 5 - 90 градусов против часовой стрелки, 6 - 90 градусов по часовой).
===
А битмаск это по коду, т.е. можно и отзеркалить, например.
Да, в астрофото картинки совсем иные чем в фотографии. Вероятно вы правы, что нужно изобретать соответствующий фильтр. Но странно, что все программы астрофото выполняют дебайеризацию, похоже что почти все билинейную. Разве что еще встречал "modified Kimmel" и "V.N.G Color Correcttion" (софт Fitswork). Откопать подробности, увы, пока не смог.
О! Не знал, что это битмаск. По простоте душевной полагал, что это просто угол поворота в единицах пи пополам. Посыпаю главу пеплом и иду читать документацию :)
Тут вот какое дело: в (художественной) фотографии совершенно другие требования: шум в "низкочастотной" части изображения (например: небо) омерзителен, в среднечастотной полезно усиливать границы, а в высокочастотной области (текстура трикотажа) можно повысить контраст, дорисовав любые детали (в меру, конечно, не надо ярких белых точек).
Я боюсь, что для ваших задач проще применить фильтр под вашу задачу, а не фотографический.
Почему нестандартное?
Ну то есть камера выдает вообще CameraOrientation забыл какой, а LibRaw преобразует его в flip.
А flip - это битмаск:
4 - поменять местами ширину и высоту
2 - отзеркалировать относительно горизонтальной оси
1 - отзеркалировать относительно вертикальной
(применяется именно в таком порядке)
5 - это поворот на 270.
Речь не о желании ротации, а о том что камера выдает нестандартное значение raw->sizes.flip=5 (ИМХО, это число должно быть в интервале от 0 до 3) и о том, как это значение обрабатывать.
Интерполяция выполняет роль пространственного фильтра, сглаживая уменьшает высокочастотную составляющую. Шум матрицы давится сильнее чем менее высокочастотный сигнал звезд.
Есть Адобовский DNG SDK (безумно странный), который позволяет писать DNG. И читать, естественно, тоже.
Бесплатный, с хорошей лицензией, в исходниках: http://www.adobe.com/support/downloads/dng/dng_sdk.html
Что я про него думаю - я два раза (почти матерно) выражал в блоге:
http://twitter.lexa.ru/2010/11/25/dng.html
http://twitter.lexa.ru/2010/11/26/dng_sdk_2.html
Но вообще, пользоваться можно.
У меня несколько посторонний вопрос возник - а какова технология изготовления DNG? Есть некая тулза или просто производилась "пересадка данных" в некий существующий валидный DNG-файл?
Независимо от астрофото - я не понимаю, как интерполяция может уменьшить уровень шума.
По вашему вопросу у меня ответа нет, не астрофотографы мы...
Да, любая интерполяция порождает артефакты, каждый алгоритм свои. В астрофото без интерполяции достигается максимальное разрешение, но, увы, и шумы при этом велики. Интерполируя можно потеряв немного в разрешении уменьшшить уровень шума, но приобрести артефакты. Вопрос в том какой алгоритм лучше именно для астрофото.
Добрался до этого места.
В-общем, это действительно камера дурит, для двух кадров выдан разный CameraOrientation.
Править что-то в LibRaw считаю невозможным, сломается авторотация у всех пользователей.
Правильный (по инструкции) способ передать в LibRaw ваше желание о ротации - это не sizes.flip править, а params.user_flip
Билинейный тоже склонен к артефактам.
Т.е. я не понимаю, какова задача, как-нибудь вовсе без интерполяции никак нельзя?
Совершенно не критично. Спасибо!
Ага, спасибо.
Критично ли, чтобы фикс был в stable-ветке (0.11) или беты (0.12) достаточно? С точки зрения поддержки Canon между ними нет разницы.
Выложил на рапиду два файла по 25МБ каждый:
Файл с нормальным flip: http://rapidshare.com/files/435138177/IMG_0335.CR2
и следующий файл снятый четырьмя минутами позже у которого flip=5 http://rapidshare.com/files/435138571/IMG_0336.CR2
Эти файлы из серии темновых кадров снимались прямо на телескопе.
А можно пример такого файла куда-нибудь выложить?
Ну там на narod.ru (или по почте просто пришлите на lexa@lexa.ru)
Починим.
И, да, разноцветная галька - известная (мне) беда у Kodak SLR/c/n
Ваши комментарии проваливаются в спам отчего-то (не изучал score), если зарегистрироваться, то станет легче.
По делу: если размывать "пиксель в 4", то из 20Mpix получим 5. Что как-то мало. Если размывать меньше, то шансы алиасинга повышаются очень сильно.
Ну то есть если размер пиксела dslr уменьшить до пары микрон, то "интерполяция" будет не нужна, биннинга будет достаточно.
Упс, первый пост и сюда таки запостился, прошу прощения за дублирование оного блоге.
Насчет двух сигналов и интермодуляции - это все же немного не то. При проверке
интермодуляционных искажений частоты сигналов все же располагаются до той самой
частоты Найквиста. А я говорил о том, что а аудио старательно избегают диапазона
выше этой частоты.
А вот в случае с изображением почему-то мало того, что мы ищем детали с пространственной
частотой равной той самой частоте Найквиста, которая кстати, в случае байера еще и
по сути различна для цветовой и яркостной составляющей (и для R и G,B тоже), так еще
и убираем АА-фильтр совсем и потом боремся с последствиями.
Оно конечно понятно - на нерегулярных структурах муара вроде и не заметно, но... детализации
там получается несколько "условная", т.е. выглядит это как детали, а на практике это то,
что додумал алгоритм интерполяции.
Мне когда-то попдался хороший пример на котором показан фрагмент кадра с мелкой
серой галькой (на кадре она получилось как размером в несколько пикселей каждый камень)
снятый на камеру с АА фильтром и без. На камере без фильтра камни аккуратненько раскрашены
в разные цвета, хотя явно выраженного регулряного муара вроде и не видно.
Впрочем я безусловно согласен с тем, что раз уж у демозаика есть шанс столкнуться с неудобными данными, то не помешает знать - как он на них отреагирует, ну или хотя бы знать "область применимости"
того или иного демозаика.
Во-первых, подать в стереоусилитель два разночастотных ВЧ-сигнала в два канала и проверить интермодуляцию - это первейшее дело. Это что касается аналогии с аудиоаппаратурой.
Во-вторых, далеко не все камеры имеют anti-alias фильтр. Не имеют его многие (все?) среднеформатные задники и некоторые "узкоформатные" камеры (Кодаки, Лейки). И картинка с 13-Mp Кодака по уровню детализации близка к 20Mp-камере с фильтром, ценой легкости возникновения муара.
В-третьих, муар получается и на размытой картинке.
Все же подобные "издевательства" над алгоритмами несколько "нечестные" - мы пытаемся алгоритмам подсунуть данные на которые он даже и не должны быть расчитаны. Ведь математика говорит что нельзя с байера требовать попиксельной резкости и контраста. Мы же не пытаемся цифровому аудиотракту с частотой дискретизации АЦП 44кГц скармливать частоты выше 22кГц? Причем не пытаемся той же причине, по которой на байеровскую матрицу (равно как и фовеон) не должна попадать картинка не прошедшая через ФНЧ - АА фильтр.
Причем непонятно как судить по результатам о качестве алгоритма. Вот например то, что у AMaZE меньше цветных артефактов говорит о том что он точнее восстаналивает яркостную компоненту или о том что он успешнее "портит" цветовую? И что важнее?
Да, точность арифметики конечно важна, хорошо себя показавшие LMMSE/AMaZE - они float.
А мишени я всякие буду делать, процедура вроде налажена. Я начал, собственно, с Siemens Star, но на ней таких душераздирающих эффектов (как на резкой мишени) нету.
Весьма интересно!
Я естественно сразу сравнил заблуреный DNG с RPP (VCD и AHD) и разница даже больше чем я ожидал. Т.е. из того муара что мы получаем солидная часть идет не от алгоритма а от точности арифметики. Чем ближе к центру, тем хуже все становится.
И в плане пожелания - если нетрудно добавь еще 3 таких же звезды с шириной в 2, 3 и 4 пиксела в те DNG!
Ничего удивительного.
Если 60% рынка твои, то и 60% жалоб - тоже твои.
Ну так мы аппаратно калибруем (линеаризуем) монитор и, той же программой, строим его описание (уже калиброваного), которое и отдаем операционной системе.
Объясните, пожалуйста, схему управления цветом при аппаратной калибровке монитора. Или скажите, где можно почитать об этом.
Проблема в том, что пока мы характеризуем цветопередачу монитора icc профилем, все очевидно. Т. е. у операционной системы есть профиль монитора, и она его предявляет всем программам, которые способны им пользоваться. Но если я откалибрую монитор аппаратно и загружу профиль в него, то откуда операционная система будет знать характеристики монитора? И, соответственно, как в этом случае программы могут правильно показывать изображения?
Купите Nikon и не мучайтесь!
Сколько читаю о разных проблемах,все время выплывает,что это Сапог.
Качественно - это обычная S-образная кривая.
Количественно - надо мерять. Не забывая при этом, кстати, что будет еще и рассеяние в камере, отчего загиб снизу будет больше, чем просто от шума.
Спасибо за ответы. А могли бы вы показать на графике примерную зависимость?
Ну если учесть что то что "ниже нуля" обрезается (вместе с отрицательными шумовыми флуктуациями) - то там среднее шумовое получается ненулевое.
И в верхах, там где сток заряда начинается, аналогичный загиб имеет место быть.
за счет шума она будет загибаться, если я правильно представляю, случайно, т.к. природа шума случайна. Т.е. кривая в тенях будет содержать что-то вроде помех, а не явно выраженную зависимость? И тогда непонятно как такие "помехи" корректировать?
В тенях - за счет шума - функция (кривая) сигнал-отклик будет загибаться. Значит надо ее распрямить....
с тенями - понятно, а что за передаточная кривая?
Приведение к линейному виду: вычитание уровня черного, поправка (при возможности) на передаточную кривую (особенно в тенях)
должно было получиться. Спасибо, попробую эту программу.
Я не понял, что должно получиться.
Но в некоторых пределах - получится. Снизу шум, сверху растекание заряда.
Просто боюсь ссылки постить
http://www.dpreview.com/learn/?/Glossary/Camera_System/sensor_linearity_...
Получится или нет?...
В смысле, с dpreview?
Возьмите и сами померьте. 4channels дает вам именно что сигнал с матрицы (ну, точнее, из RAW-данных, что там с ними камера делала - конечно, вопрос).
...эта проблема решается гамма-коррекцией и форматом PNG?..
Кстати, про удваивающийся сигнал, это Вы случайно не с dpreview взяли?
Если мы удваиваем экспозицию (и не попадаем в насыщение) - удваивается сигнал (после линеаризации т.е. вычитания черного/dark current).
Т.е. - пропорционален энергии.
Как в двух словах рассказать про "цветовую матрицу" - не знаю. Задам направление для рассуждений: представим себе два цветных монитора с разным цветом чистых цветов (R,G,B). Очевидно, что при подаче на них одинакового сигнала (скажем, 70, 133, 250) - цвет получится разным. И есть обратная задача - какой сигнал подать на второй монитор, чтобы получить цвет близкий/идентичный к первому.
а всё-таки сигнал пропорционален энергии или её логарифму? И расскажите, пожалуйста, нубу, что за цветовая матрица? Из полученных TIFF-файлов вынимаю только красный канал.