LINUX.ORG.RU

UFRaw 0.5


0

0

Вышла новая версия UFraw - программы для обработки цифрофоточных Raw-файлов.

- добавлена чтение файлов кривых Nikon Tone Curve (NTC/NCV);
- добавлен редактор кривых (вместо ползунков);
- добавлено управление основной кривой;
- поддерживаются новые цветные матрицы;
- улучшена управляемость из командной строки;
- добавлена предварительная поддержка EXIF [1];
- новые ID-файлы UFRaw содержат все параметры преобразования для пакетной обработки;
- вместо ufraw --batch теперь отдельный бинарник ufraw-batch;
- масса других изменений;
- новая адаптивная гомогенно-ориентированная интерполяция пока не включена.

[1] Что касается предварительной поддержки EXIF, это означает, что тэги копируются из Raw-файла в экспортируемые JPEG. При экспорте в TIFF тэги пока не пишутся.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous_incognito

Ну так прикрутите! :) Все спасибо скажут

AP ★★★★★
() автор топика

Чорт! Как только появится свободное время, обязательно поучаствую. Я свою конвертилку так и забросил в зачатках, они значительно дальше меня продвинулись, так что лучше помочь, чем форкать.

Casus ★★★★★
()

А ведь вполне себе неплохая вещь! Как фотограф-любитель говорю :) Хорошо бы прикрутить поддержку изменения кривых в реал-тайме (как в BibblePro), а также научить GiMP 16-bit цвету. Цены бы этой штуке не было (в моих глазах). PS: Кстати, этот самый ufraw и шумы давит неплохо (в сравнении с bibblepro тем же), только это не настраиваемо (пока). PPS: Да и shadow/highlights работает :)

anonymous
()

реал хакерам респект

anonymous
()
Ответ на: комментарий от anonymous

> А ведь вполне себе неплохая вещь!

Из свободных - лучшая :)

Шумодав в составе UFRaw мной пока не замечен :) Прошу рассказать подробнее, а то может зря я собираюсь под GREYCstoration кластер собрать :)

AP ★★★★★
() автор топика
Ответ на: комментарий от AP

>Из свободных - лучшая :)

причём в последнем CVS включен dcraw 7.70, который получше работает с ББ в Canon PowerShot S60.

PS. А где там окопались shadows/highlights? Я видел только кривую яркости. В shadows/highlights посложнее алгоритм...

adarovsky ★★★★
()
Ответ на: комментарий от AP

> Шумодав в составе UFRaw мной пока не замечен :) Прошу рассказать подробнее, а то может зря я собираюсь под GREYCstoration кластер собрать :)

Сравнивал шумы при примерно одинаковых кривых rgb на результатах обработки Bibblepro и ufraw - последняя явно шумит меньше. Я не хочу сказать, что там какой-то алгоритм шумоподавления работает, просто видимо разные алгоритмы дебайеризации.

PS: 300d, iso200/400 в довольно тяжёлых условиях (есть провалы в тенях, разница между светами и тенями ~4 EV наблюдал).

anonymous
()
Ответ на: комментарий от adarovsky

> PS. А где там окопались shadows/highlights? Я видел только кривую яркости. В shadows/highlights посложнее алгоритм...

Shadows и black point. Я не фотошоповский алгоритм имел ввиду. PS: Хотя если бы можно было двигать кривые вместе и отдельно по каналам (да ещё не только в rgb, но и в lab) - всё это было бы лишним :)

anonymous
()

0.5

Я давно использую снэпшот-билды. Оччень приятно. Уди написал в кронференции, что новый AHD алгоритм dcraw не встроил, потому, что хотел быстрее выпустить версию 0.5. На очереди включение AHD алгоритма в 0.6. Смотрел тестовые фотографии, впечатлило очень сильно - отсутствие артефактов цвета по сравнению со старым алгоритмом и сильное увеличение детализации. http://users.tkk.fi/~stanhua/rawcomp/ Bibble вообще рядом не стояла.

В перспективе (я так думаю) - включение нового фильтра - шумодава из dcraw: http://home.earthlink.net/~paul.j.lee/

В общем, вскоре остальные конверторы отдохнут :).

BigSerpent ★★
()
Ответ на: комментарий от AP

> Shadows уже нет. Теперь всё кривыми :)

О, точно, пропустил это дело... сегодня обновлюсь, спасибо.

anonymous
()

А зачем нужен этот Raw формат? Динамический диапазон пленки - 7, у CCD еще меньше (6-5). Т.е. 8 битов за глаза хватает, чтобы записать показания с CCD камеры. Что у них там в нижних 8 битах записано - хз, но думаю, что это белый шум. На нем может что-то и можно наиграть (если пускать moving-average с окном 10x10), но тот же эффект можно получить и с 8 битными картинками.

geekkoo
()
Ответ на: комментарий от AP

Изучил. Ничего нового для себя не обнаружил. Что камера, что телевизор - RGB устройства, поэтому шум на тему color-models не к месту. Остальная аргументация -

Most camera raw files have a color depth of 12 bits per channel instead of the 8 used by JPEG. This allows minor exposure errors to be corrected and tonal changes to be made with less risk of posterization. (However, overexposed areas are just as white with 12 bits as with 8, so using raw is not a substitute for correct exposure.)

мягко говоря - вранье. То что производители камер впаривают народу 12 битные AЦП - охотно верю, но CCD матрица она как была, так и осталась 7 бит максимум. Поэтому, что там АЦП насчитает с нее в младших разрядах - одному богу известно.

geekkoo
()
Ответ на: комментарий от geekkoo

Фигово изучили, ой фигово.

Объясните мне, любезнейший, каким образом Вы будете править в JPEG или TIFF неверно выставленный баланс белого?

(пример из жизни приятеля) Предположим, проснулись Вы поутру в палатке. Выглянули наружу, глядь - а на соседней ветке капельки после ночного дождя диво как хороши. Вы тут же, понятно, схватились за камеру и нащёлкали их в JPEG/TIFF. Просмотр отснятого с целью экономии заряда аккумулятора отключен. А через пару часов замечаете, что ББ был выставлен на "вспышку", потому что предыдущей ночью со вспышкой снимали, а назад переключить забыли. Соответственно, дома Вы предсказуемо с огорчением рассмтариваете на мониторе вместо красивой реалистичной утренней картинки какую-то дрянную синеву.

Ваши дальнейшие действия с JPEG/TIFF?

AP ★★★★★
() автор топика
Ответ на: комментарий от AP

2AP
> Ваши дальнейшие действия с JPEG/TIFF?

Всё зависит от степени "испорченности". Действий может быть много.
Три основных направления:
1. Выравнивать баланс
2. Использовать искаженные цвета в плюс (нестандартное решение)
3. Перевод в ч/б

В зависимости от замысла каждый вариант равноценен.
Т.к. вопрос был о выравнивании баланса, то телодвижений больше и диапазон возможностей меньше.
1. инструмент Color Balance
2. команда Auto balance
3. инструмент Levels
4. инструмент Curves

Но не сильно обольщайся на счёт RAW. Штука хорошая, но, бывает, конвертация из RAW в JPEG может занять больше времени, чем обработка JPEG при сопостовимых результатах. Всё зависит от конкретного снимка и того, что автор желает получить в итоге - начального замысла.

Korwin ★★★
()
Ответ на: комментарий от Korwin

RAW

RAW имеет несколько достоинств: 1. не имеет примененного баланса белого - делается потом на усмотрение пользователя 2. позволяет использовать более совершенный алгоритм обратного Байеровского восстановления, чем используется в камере. Завимсит от RAW конвертора. Позволяет по сравнению с jpg избежать артефактов компрессии. По сравнению с tiff - улучшить детализацию. Алгоритмы RAW конвертации улучшаются, поэтому с новой версией программы, вполне возножно, Вы сможете вытащить больше деталей с той же самой фотографии. 3. Позволяет менять в определенных пределах экспозицию - вводить компенсацию - уже после факта съемки. Особенно актуально для малошумящих зеркалок, где +2EV может не вызывать существенного повышения шумов. Тонкость - даже если бы информация в RAW была в 8 бит, то изменение экспозиции (освещенности) в RAW приводит к лучшим результатам, чем для jpg с неправильной экспозицией и уже наложенным балансом белого.

Вообще говоря, RAW это максимальное качество, которое можно получить с фотоаппарата. RAW - это оригинал, а jpg - копия, сделанная процессором камеры.

BigSerpent ★★
()
Ответ на: RAW от BigSerpent

> Вообще говоря, RAW это максимальное качество, которое можно получить с фотоаппарата
Мне ближе уточнение: RAW имеет _возможность_ получить большее качество чем даёт ПО аппарата при съемке в JPEG/TIFF. Но не факт, что эту возможность может поиметь каждый.

Korwin ★★★
()
Ответ на: комментарий от Korwin

Не слабо. И всей этой ерундой Вы будете заниматься вместо того чтобы поправить температуру цвета?

AP ★★★★★
() автор топика
Ответ на: RAW от BigSerpent

Скажу по секрету: профессиональные фотографы, исопльзующие цифру, давно и безвозвратно перешли на Raw.

AP ★★★★★
() автор топика
Ответ на: комментарий от AP

В другом треде товарищ Korwin уже сказал, что отдельные шибко умные фотографы скрывают постеризацию добавлением шума. На мой взгляд Perline noise в этом деле более полезней, чем Gaussian - ну это дело вкуса. Производители фотокамер позаботились и об не шибко умных фотографах и тот же самый noise (реализации они правда тщательно скрывают) стал доступен любому представителю homo sapiens хоть раз слышавшему про raw формат.
Такие дела.

geekkoo
()
Ответ на: комментарий от AP

2AP
> Не слабо. И всей этой ерундой Вы будете заниматься вместо того чтобы
> поправить температуру цвета?

Передёргивать не надо, ладно? Ответ был на вопрос, что будешь конкретно делать если оригинал в JPEG/TIFF. На него был дан развернутый ответ.

Если у тебя есть ответ лучше - дай его! Опять таки не забываем про вопрос (JPEG/TIFF).

Korwin ★★★
()
Ответ на: комментарий от AP

2AP
> Скажу по секрету: профессиональные фотографы, исопльзующие цифру
Ошибочка по Фрейду? :)

Открыл америку. Забыл добавить [шёпотом]: - ...и они об этом никому не говорят...

Korwin ★★★
()
Ответ на: комментарий от geekkoo

2geekkoo
Не шибко умные фотографы, а просто из желания получить сколько-нибудь приличный результат, а не пластилиновую кожу, волосы как проволку и прочее, прочее.

Korwin ★★★
()
Ответ на: комментарий от Korwin

О-о-о, знатный порнограф Korwin делится секретами мастерства.

А по существу есть что сказать? Про динамический диапазон CCD матриц (это информация скрывается покруче, чем ядерные коды эрефии)? Про время оцифровки 5 Мегапиксельной матрицы (они что за микросекунду каждый пиксел оцифровывают)? "и прочее, прочее" (цитата)

geekkoo
()
Ответ на: комментарий от geekkoo

2geekkoo

О как зацепило! :) завудешь знатному порнографу Korwin'у? Зависть это плохо.

Не переводи во флейм. по существу я сказал. Тебе повторять не буду.

А вот ты что сказал по существу? Ляпнул чушь и радуешься. Дитятко.

Korwin ★★★
()
Ответ на: комментарий от AP

>>>Предположим, проснулись Вы поутру в палатке.

Офуеть - это ж скока надо выпить.

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

Какая сука ссыт возле палатки?

>>>Вы тут же, понятно, схватились за камеру и нащёлкали их в JPEG/TIFF.

Делать мне что-ли больше нечего в полшестого утра? И голова еще трещит после вчерашнего.

>>>Просмотр отснятого с целью экономии заряда аккумулятора отключен. А через пару часов замечаете, что ББ был выставлен на "вспышку", потому что предыдущей ночью со вспышкой снимали, а назад переключить забыли.

Чё?

>>>Соответственно, дома Вы предсказуемо с огорчением рассмтариваете на мониторе вместо красивой реалистичной утренней картинки какую-то дрянную синеву.

Кстати сказать и не только в мониторе.

>>>Ваши дальнейшие действия с JPEG/TIFF?

Опохмелиться.




geekkoo
()
Ответ на: комментарий от Korwin

> Если у тебя есть ответ лучше - дай его! Опять таки не забываем про вопрос (JPEG/TIFF).

Разумеется есть ответ и я его дал. Просто читать надо внимательно. А Вы второй раз за день замечены в невнимательном чтении :) Нехорошо как-то :)

Ладно, я добрый, я повторю. Использование Raw позволяет гораздо проще и быстрее скорректировать ББ при ошибке.

Ещё вопросы есть? :)

AP ★★★★★
() автор топика
Ответ на: комментарий от Korwin

Итак, несмотяр на то, что вопрос был задан не Вам, по порядку.

> 1. Выравнивать баланс

При серьёзной ошибке не катит. Проверено на опыте.

> 2. Использовать искаженные цвета в плюс (нестандартное решение)

Не пробовал. Любопытно посмотреть на результат такого "нестандартного решения".

> 3. Перевод в ч/б

Оригинально. То есть любую хреново снятую фотку перевёл в Ч/Б - и сразу молодец. Интересный подход :)

> 1. инструмент Color Balance

Вариант,

> 2. команда Auto balance

Далеко не везде даёт адекватный результат.

> 3. инструмент Levels

То же самое, требует времени

> 4. инструмент Curves

То же самое, требует времени

> Но не сильно обольщайся на счёт RAW. Штука хорошая, но, бывает, конвертация из RAW в JPEG может занять больше времени, чем обработка JPEG при сопостовимых результатах. Всё зависит от конкретного снимка и того, что автор желает получить в итоге - начального замысла.

Ну да, это очень удобно - сказать, что всё зависит от конкретного снимка :) Но в реальности обычно получается, что проблема, которая в UFRaw решается сменой пресета с Flash на Auto, в случае с JPEG/TIFF требует изощрений.

На тот случай, если Ваш механизм суперинтерпретации текста снова даст сбой: я не утверждаю, что _вообще нельзя_ в JPEG/TIFF выровнять цвета при ошибке ББ. Я утверждаю, что в большинстве случаев коррекция при использовании Raw занимаете существенно меньше времени и усилий.

AP ★★★★★
() автор топика
Ответ на: комментарий от AP

> Я утверждаю, что в большинстве случаев коррекция при использовании Raw занимаете существенно меньше времени и усилий.

Ну и результат почище

AP ★★★★★
() автор топика
Ответ на: комментарий от AP

Вы же тут с Korwin слились в экстазе. Я решил не вмешиваться.

geekkoo
()
Ответ на: комментарий от AP

>При серьёзной ошибке не катит. Проверено на опыте.
Согласен на то он и JPEG/TIFF как конечное представление.

>Не пробовал. Любопытно посмотреть на результат такого "нестандартного решения".
http://www.photoline.ru/cgi-bin/cr/photo.pl?ind=1116426282
Сейчас лень искать.

> Оригинально. То есть любую хреново снятую фотку перевёл в Ч/Б - и сразу молодец. Интересный подход :)
Не оригинально. Этот способ применяется с тех пор как появилось цветное фото.

Да и что делать есть источника света слишком не однородные по цветовой температуре? ч/б бывает единственным выбором.

Да и цвет не всегда, и чаще не нужен в работе.

>>команда Auto balance
>Далеко не везде даёт адекватный результат.
Для этого есть можножность корректировать результат auto функций. Нужно ими пользоваться.

>То же самое, требует времени
При опыте и чустве цвета не так уж и много.


>я не утверждаю, что _вообще нельзя_ в JPEG/TIFF выровнять цвета при
>ошибке ББ. Я утверждаю, что в большинстве случаев коррекция при
>использовании Raw занимаете существенно меньше времени и усилий.
А с этим я никогда и не спорил. Перечитайте ветку. Я говорил о том, что для _рядового_ пользователя RAW избыточен.
А профессионалы выбирают тот инструмент который адекватен задачи. И JPEG/TIFF ещё не выброшен на свалку истории.


Korwin ★★★
()
Ответ на: комментарий от geekkoo

> Изучил. Ничего нового для себя не обнаружил.

А ты подумай.

1. Raw -- "сырая" картинка с матрицы. Как есть.

2. CCD -- приборы _аналоговые_, к ним понятие "битности" неприменимо.

3. Кривые у матрицы сильно отличаются от финального цветового пространства, нам ведь надо sRGB или Adobe.

4. И зависимость нелинейная.

5. А если учесть еще и баланс белого и гамму.

baka-kun ★★★★★
()
Ответ на: RAW от BigSerpent

Ну тогда вечером cvs up -Pd и вперёд с песТней :)

AP ★★★★★
() автор топика
Ответ на: комментарий от baka-kun

2. CCD -- приборы _аналоговые_, к ним понятие "битности" неприменимо.

Ну, да - я неправильно выразился. Имел в виду, что соотношение сигнал/шум для матрицы не позволяет получить информации больше, чем на 7 бит (что соответствует примерно 45дБ). С другой стороны тот же параметр позволяет предсказать максимальный (теоретически достижимый) динамический диапазон для этой матрицы - те же самые 7 EV (хотя может быть и меньше).

3. Кривые у матрицы сильно отличаются от финального цветового пространства, нам ведь надо sRGB или Adobe.

4. И зависимость нелинейная.

5. А если учесть еще и баланс белого и гамму.

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

geekkoo
()
Ответ на: комментарий от geekkoo

> соотношение сигнал/шум для матрицы не позволяет получить информации больше, чем на 7 бит... те же самые 7 EV.

Для начала ответ "в лоб": при _любой_ мультипликативной операции мы теряем половину младшего разряда. Приходилось видеть "расческу" в уровнях? Во-вторых, сигнал/шум достаточно тяжело оценить: спектр шума, например. Вот говорить о динамическом диапазоне -- это уже лучше. Если про максимальный уровень сигнала все понятно, то с минимальным нужен небольшой эксперимент: закрой крышку объектива и сделай снимок ;) А потом посмотри в RAW, и сосчитай нулевые старшие биты. Вот прям сейчас возьми из кофра камеру, и проверь.

Но даже это не столь релевантно. Напомню, мы говорим о необходимости более восьми бит на этапе _обработки_ изображения, а тут все однозначно:

> Это все одно и то же

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

Проведи эксперимент в 8-бит редакторе: нарисуй градиент от 0 до 255, поправь гамму в любую сторону, оцени уровни, верни гамму обратно, снова оцени уровни, ужаснись. ;) И представь, что происходит при правке баланса белого.

А теперь повтори в 16-бит редакторе: нарисуй градиент от 0 до 255, смени в 16-бит, поправь гамму в любую сторону, в 8-бит, в 16-бит, верни гамму обратно, в 8-бит, оцени уровни -- уже лучше, правда в основном за счет шейпинга при 16->8.

И, наконец, все в 16-бит: нарисуй градиент от 0 до 255, смени в 16-бит, поправь гамму в любую сторону, верни обратно, в 8-бит, оцени уровни -- тут вообще красота.

Сделай выводы.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

>>> Проведи эксперимент в 8-бит редакторе: нарисуй градиент от 0 до 255, поправь гамму в любую сторону, оцени уровни, верни гамму обратно, снова оцени уровни, ужаснись. ;) И представь, что происходит при правке баланса белого.

Это все замечательно, но я не аргументирую против 16 бит при _обработке_ сигнала (более того - я даже раньше высказывал мысль, что double для этих целей был бы более полезен) где ошибки округления играют большую роль, но считывание raw с камеры в 16 битах - это занятие бесполезное, тк значащими будут только верхние 7 бит. Любая гамма, нелинейность - это характеристики датчиков, в регистрирующую систему поступает уже линеаризованный сигнал, и вся математика идет с этим сигналом после его дискретизации. Подавляющая часть шумов вносится в промежутке между считыванием заряда (напряжения) на пикселе и его дискретизацией, причем аналогово-цифровое преобразование тут тоже не причем. Шум 45 дБ это не шум интенсивности падающего светового потока, а шум измеряемого напряжения на пикселе.

Вроде бы, как-то так

geekkoo
()
Ответ на: комментарий от geekkoo

> но считывание raw с камеры в 16 битах - это занятие бесполезное, тк значащими будут только верхние 7 бит.

Как для слепого пишу, ей богу. :( Давай с азов, что ли:

1. CCD -- прибор аналоговый.

2. То, что динамический диапазон матрицы (пусть будут семь бит, бог с тобой) позволяет получить разницу между самым светлым и самым темным в 128 раз, совсем _не_значит_, что минимальная разница между двумя соседними уровнями будет составлять 1/128 от максимального.

3. Сигнал с матрицы линейный.

4. Для финальной картинки в большинстве случаев нужна гамма 2.2

5. Цветовая температура источника освещения может меняться весьма значительно.

6. Я что, зря про _нелинейные_ преобразования говорил? Начнешь крутить гамму, и, естественно, самые яркие уровни продублируются, а тени просто пропадут. Если на входе 8-бит ты потеряешь не так много сверху, хотя и больше, чем в 16-бит, зато в тенях не останется _ничего_ вплоть до 20-23, а дальше будут зиять дыры. Это то, что называется постеризацией, в данном случае нелинейной.

7. Сколько мультипликативных операций на пути от сенсора до точки в скорректированном 8-бит битмапе? Гамма коррекция, баланс белого, байер, в котором их куча,...

> Любая гамма, нелинейность - это характеристики датчиков

А вот хрен тебе, ПЗС _очень_ линейны: каждый попавший фотон -- это один электрон. Нелинейная характеристика у устройств отображения, а баланс белого правят для рецепторов человека.

> шум измеряемого напряжения на пикселе.

Сигнал/шум измеряемого напряжения на _пикселе_ более 60-70дБ. И то только потому, что малошумящие усилители дороже стоят.

Ты путаешь два разных шума: тепловой шум пикселя + усилителя в time domain и spatial шум _группы_ пикселей.

Ну и не забывай про спектр шумов. И про то, что "аналоговый" шум предпочтительней "цифрового".

PS. Кстати, знаешь, как измеряют сигналы ниже уровня шума?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Я тут немного погуглил по поводу типичных параметров средненьких матриц. Для КМОП:

1. Собственный шум ячеек -- 30-35 электронов
2. Тепловые шумы -- 200-250 электрон/сек
3. Емкость ячейки -- 65000-70000 электронов

Что нам дает динамический диапазон (ёмкость/шум) -- 60-68 дБ. DSLR Canon D60 с APS даёт почти 70дБ _с_учетом_ шума АЦП. А кодаковские ПЗС имеют отношение сигнал/шум более 72 дБ.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Да с CCD я промазал ;) Но у меня есть что возразить (после)

Я тут тоже время даром не терял и тоже кое-что нагуглил.

Про Canon D60 - я не знаю где вы нашли такое дикое соотношение сигнал шум с учетом АЦП:

http://www.dpreview.com/reviews/canoneosd60/page16.asp

Статейка рекламного характера, но там авторы при максимальных параметрах (ISO100, 1/10 сек) получают на тестах шум 0.64 8-го бита при том, что как авторы скромно заметили вначале, они использовали unsharpening (те moving average по пикселам). Разумеется шум это значительно должно подавить. В остальных случаях все гораздо хуже.

А вот сведения общего характера про CCD

http://www.olympusmicro.com/primer/digitalimaging/concepts/ccdsnr.html

Даже если отбросить все шумы вносимые CCD/аналоговой частью/АЦП у нас еще есть шум самого источника света, и его шум N=(S)^0.5. Этот шум - теоретический предел, что вы можете наиграть на камере. Заметьте, что он меняется как корень от числа электронов (фотонов) попавших на ячейку и сопоставьте это с вашей экспериментально найденной гаммой (2.2). Получается, что величина этого шума одинакова во всем диапазоне даже после гамма-преобразования.

А теперь берем ваши цифры и считаем:

сигнал/шум=65000/(65000)^0.5=250 (мне понравилось, что эта величина совпадает с с тепловыми шумами, согласно вашим данным). Т.е. шум самого сигнала имеет точность не выше 8 бит, при том что вам еще нужно хорошо напрячься, чтобы добиться этой точности (вылизать аналоговую часть / подавить белый шум). Также примеры, рассматриваемые в статье, не имеют ограничения во времени и время экспозиции в 100 секунд для них не проблема.

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

Про снятие сигнала на уровне шума я в курсе, но в камере у вас просто нет время на изыски вроде синхронного детектирования. Заявленная скорострельность 6 снимков в секунду а вам за это время еще нужно оцифровать 5 миллионов точек. Мегагерцовые сигнальные процессоры конечно не слишком дорогие, но с гигагерцами я боюсь у вас уже возникнут проблемы.

geekkoo
()
Ответ на: комментарий от geekkoo

Не уверен, что оппонент прочитает сообщение в теме, которая давно ушла в архив, но...

Вынужден сразу извиниться за ошибку, которую только что заметил: в сообщении от (01.10.2005 4:29:47) речь не шла о сигнал/шум, только о динамическом диапазоне, SNR туда вкралось по недоразумению. ;) Планировался еще один абзац, но недостаток времени не позволил продолжить.

> Про Canon D60 - я не знаю где вы нашли такое дикое соотношение сигнал шум с учетом АЦП

Это не SNR, как я уже сказал, это динамический диапазон. Более 11EV для D60.

> http://www.dpreview.com/reviews/canoneosd60/page16.asp

Как надо было читать, чтобы не заметить, что все измерения проводились _после_ компрессии в _восемь_ бит? Естественно, и намерили шум в восьмом бите. ;)

> Получается, что величина этого шума одинакова во всем диапазоне

Именно на это я и хотел обратить внимание, но не успел. Фишка вот в чем: величина этого шума зависит от уровня сигнала, и если для максимальной освещенности ты насчитал SNR 260/1 = 48.3дБ, то для 50% это НЕ будет 130/1=42дБ, будет 180/1 = 45.2дБ. Для освещенности в 10% это НЕ будет 28дБ, будет 38дБ. Для 1% НЕ 8дБ, а 28дБ. Динамический диапазон на выдержке 1/10 = 65000/(30 + 200/10) = 62.3дБ.

При этом сигнал 1% интенсивности (-40дБ) будет описываться _одной_целой_тремя_десятыми_в_периоде_ младших бит для 8-бит АЦП (5.(3) для 12-бит), но его шум еще на 28дБ (4.(6) бит) _ниже_. Это _идеальные_ цифры, для выдержки 1/10 с учетом шумов будет SNR 18дБ для 1% интенсивности, т.е. менее чем десятью битами не отделаешься.

Теперь понятней? ;)

PS. Очень надеюсь, ты прочитаешь... PSS. Ты эксперимент-то провел? Я на своем Nikon D50 вижу постоянный шум в младшем бите и всё.

baka-kun ★★★★★
()
Ответ на: комментарий от geekkoo

> Все же рассказы про постеризацию на 8-битных снимках полученных непосредственно с камеры

Ну так проверь. Представь, что у тебя в камере 8-бит RAW, а не 12 как у всех. Нарисуй градиент от 0 до 255 и примени к нему гамму 2.2. Затем посмотри на уровни (в GIMP -- Инструменты->Гистограмма, правда гимп до сих пор не умеет нарисовать градиент без "дырок").

> это просто отсутствие шумов в 8 бите

А может ты имеешь в виду небольшую зернистость? ;) Так это совсем другое. Просто хороший пространственный ФНЧ перед матрицей (объектив, например ;)).

> а в 8-битном вам нужно просто добавить (с помощью фотошопа или гимпа) гауссовый шум, чтобы все стало на свои места.

noise shaping -- это, конечно, хорошо и полезно бывает. Иногда. Но если ты повторишь опыт с гаммой в 8-бит, у тебя от 256 уровней серого останется примерно 180-185. То есть от 16M цветов около 6М. Если это не постеризация, то я Папа Римский. ;)

baka-kun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.