Вот и я хочу сказать что камера мало того что не может дать приведенные выше цвета, так и as is дать не может из-за особенностей нашего зрения(ну то есть она регистрирует длинны и спектр волн, но не то что мы видим. То что видим мы, существенно различается с тем что регистрирует камера. Вот и все. Различными инструментами мы создаем эффект присутствия (конечно все зависит от замысла и желания его создать). А по поводу извращения в слоях. Простой пример: яркая солнечная погода. Пейзаж с лесом в горах. Мы видим все (адаптация, частичное построение картинки, додумывание мозгом и.т.д.). А потом давайте снимем все это на камеру. Либо небо выбьется, либо земля темная (ну то есть варианты возможны, но вполне может быть). РАВ конвертер? То то Сони ХДР встраивает в камеры))).А вот слои очень даже помогут.А корректирующие? Вы не любите кошек, да нет, просто не умеете их готовить. Радикализм (РАВ или ФШ) здесь ИМХО не к чему.
Я же написал что это абстрактное сравнение, ну если не можете образно осмыслить, то скажу проще, значение по-умолчанию можно везде воткнуть любое, т.е. нолик поставить там где нужно и не факт что это будет нулевая точка отсчета. Насчет различия резкости и детализации я что-то не понял, практически все статьи, которые я читал о повышении детализации изображения, описывают повышение резкости, достаточная детализация-значит достаточная резкость , в чем практическая разница между этими терминами я не вижу.
apply каждый раз. обработка в rpp мне пока тоже не пошла, но возможность применять "пленочные цвета" оч интересна. всю ветку не читал.. столкнулся с тем, что при конвертации в тиф при стандартных настройках больше шумов.
3 RAW и HDR. Ну либо если хочется натуральности, то из одного вытянуть. Собсно случай со сложнымм ДД в принципе понятен, и там с ФШ можно повозиться тоже, это больше вопрос техники. Но вот насчет цветов - все приведенные примеры именно где цвет тянулся, никакого отношения к тому как видит глаз не имеют даже близко.
Столько всего написано про этот RPP, а посмотреть в деле никак. Мака нет, на виртуальной машине с маком слишком медленно и извращенно. Может есть возможность в линуксе его запустить, знает кто-нибудь? )
Про Apply уже написали, это cmd+R. Про ББ: 1. если просто кликать с нажатой cmd, то ББ будет браться по конкретной точке. 2. Если при нажатой cmd выделить прямоугольник мышкой, то усреднится по всему выделению. Это бывает актуально на зашумленных кадрах. 3. Можно пользоваться значениями каналов a и b в Lab. Для ребенка, например, значения каналов a и b должны быть примерно 13 и 14, соответственно (или 13/13, или 14/14). Про экспозицию: Очень удобный инструмент - гистограмма. Она совмещена со шкалой Адамса, и при этом показывает гистограмму текущего выделения. Поэтому можно выделить, например, лицо, и посмотреть, где оно у нас находится по гистограмме. Затем просто добавить требуемое значение в поле "Exposure" или "Compressed Exposure" для того, чтобы вывести лицо в нужную зону (для лица обычно пятая и шестая). Исправлено...
Про крутилки в RPP Вот график из статьи Павла Косенко, поясняющий действие некоторых контролов в RPP:
http://alextutubalin.livejournal.com/221456.html?style=mine#cutid1 очень занятное наблюдение по-поводу неприспособленности фотошопа к коррекции фотографий
1. Я не собираюсь осмысливать ваши абстрактные сравнения. 2. В обоих конвертерах есть вполне реальные возможности отключения улучшайзеров. В случае RPP разработчик открытым текстом говорит, для чего он добавил "Sharpness", "Local Contrast" и "Remove Dot Noise", несмотря на то, что это противоречит его идеологии проявки RAW-файла. Также добавлены чекбоксы для полного отключения постобработки. В ACR движки "Amount" для резкости и "Luminance/Color" для шумодава устанавливаются в ноль. Т.е. ноль это не некая абстрактная величина, а уровень добавляемого эффекта. Кстати Sharpness в ACR полностью аналогичен такому же эффекту в ФШ, о чем неоднократно писал Маргулис. Да и вообще практически все эффекты ACR можно выполнять с таким же успехом в ФШ. Движок один. Вот об этом я и говорю. В итоге получается как в том споре о вкусе креветок...
Потихоньку буду выкладывать примеры, на которых можно оценить характер шумов (и детализации!!!) - http://alexe.boka.ru/gallery2/main.php?g2_itemId=14079
Об использовании чисел с плавающей точкой - это чистый маркетинг. Правильное использование целочисленных вычислений очень часто позволяет получить не меньшую (а иногда и большую) точность. Другое дело, что с float'ами гораздо проще программировать, не задумываясь о точности - процессор сам всё сделает. Пример с делением-умножением на 2 - чисто синтетический. Если вместо 32-битного float'а ПРАВИЛЬНО использовать 32-битный int, то младшие разряды будут оставлены "про запас", то есть (5/2)*2 будет реально вычисляться, например, как 00010100 -> 00001010 -> 00010100. Результат равен пяти. По сути это число с =фиксированной= точкой. Легко привести пример, когда int даст бОльшую точность. 20000000 + 1 в 32-битных интах будет, как ни странно, 20000001, а в 32-битных float'ах выйдет 20000000 Не хватает точности мантиссы. Я ни в коем случае не хочу сказать, что плавающая точка в данном применении - зло. Нет, скорее наоборот. Однако само по себе это не несёт никаких преимуществ. Всё дело в более глубоких нюансах реализации. И наконец, последний момент. Если программа написана хорошо, то не так сложно перевести обработку с 8-ми бит на 16 или на float. Если бы это действительно давало значительный прирост, это сделали бы многие разработчики конвертеров. И кстати, не исключено, что в некоторых из них промежуточные результаты также хранятся с плавающей запятой. Просто обычно подобные вещи являются особенностями реализации, о которой маркетологи и не знают вовсе
Вот такие цвета получаются... По моему красивые) Вся обрабока в РПП + Шарп в Фотошопе (на 18-70 снимался кадр все же )
Если бы я не видел разницы в картинке после RPP и ACR, то я бы все равно вам не поверил - математику не обманешь. При целочисленных вычислениях относительная погрешность растет с уменьшением вычисляемых значений. Т.е. величина ошибки зависит от величины сигнала! Пример мимо кассы. У нас максимум 4095 градаций в каждом канале при условии правильной экспозиции. Реально заметно меньше. Причем каналы проэкспонированы по-разному! Реально в синем и/или красном каналах экспозиция может быть на 2-3 стопа ниже, чем в зеленом. Т.е. легко получаем 255-511 градаций для этих каналов. После коррекции (поканальной) на гистограмме это выглядит как "забор". Тоже мимо кассы. Реально возникают проблемы с быстродействием и выделением памяти. Сейчас с этим стало полегче (64бит), но тем не менее проблемы существуют. "Многие разработчики" ориентируются на потребителя. Пока "пипл хавает" - будут делать быстро, дешево и сердито...
По первому пункту вы только подтверждаете мои слова. 32-разрядной точности хватает с головой. А проблемы - либо от неумения, либо, что более вероятно, от нежелания разработчиков сделать как следует. А погрешность у 4-байтового float'а изначально больше, т. к. мантисса 24 бита против 32-х (при правильном применении int'ов). Впрочем и того и другого вполне достаточно, если нигде не накосячить Про быстродействие и выделение памяти - тут с интами не больше проблем, чем с floatами (а реально зачастую выходит чуточку быстрее, не смотря на все успехи AMD и Intel). А насчёт дешевизны - да. Абы как сделать всегда проще (читай дешевле). Но повторюсь, тут дело не в представлении чисел, а в алгоритмах. Математику-то не обманешь
у меня почему то после конвертайии в тиф размер по сторонам уменьшается в двое. У всех так или я что-то не правильно делаю?
