PhotoCode: красивый цвет легко и быстро

[Deman32]

Точно. Можно просто мне выложить файл настроек. Под 750 камеру у меня в принципе всё есть: и профиль и ББ под пару условий освещения по цветной мишени. У меня ж у самого 750.

При пакетной работе бывает достаточно настроить кривую и потом просто корректировать экспозицию.

А вообще порядок обработки фотосессии примерно такой:

- определиться с несколькими типичными кадрами и проявить их

- нажав кнопку "E" перегнать их в примеры и потом просто копировать настройки на остальные кадры.

Не забывайте использовать ссылочный баланс белого: при наличии примера в левой панели и выборе его (двойным кликом) достаточно копировать его ББ, зажимая Shift, и впоследствии, если, например, ББ не понравился, нужно поменять его только на фото примера и прогнать фотосессию пакетно. ББ автоматом применится тот, который был в этом примере. Не забываем сохранять настройки каждой фотографии при переходе на следующую. Автоматически они не сохраняются.

[Deman32]

Вываливается при попытке открытия сконвертированного тиффа "..has stop working".

Видеокарта ATI?

Над этим работаю.

[xrite]

Видеокарта ATI?

Над этим работаю.

Нет, нвидия, quadro.

[Deman32]

А "..has stop working" откуда сообщение?

[xrite]

А "..has stop working" откуда сообщение?

[Deman32]

Какой размер тиффа по длинной стороне?

Если есть файл opt от старой версии, то тоже вылетит. Но может быть та типичная ошибка, что не у всех случается.

[xrite]

Какой размер тиффа по длинной стороне?

Если есть файл opt от старой версии, то тоже вылетит. Но может быть та типичная ошибка, что не у всех случается.

Сразу не глянул, 2142x1422 почему-то выдал для Д700.

[Deman32]

Половинный размер.

Ну значит всё же ошибка та. Исправляю.

[SPU]

1) программировать очень много

Строчек 10.

[Deman32]

Я смотрел, что в dcraw - даже если отбросить всё что не связано с чтением рава и демозаиком - на одну очень большую проблему переписывания потянет. Это хорошо, если возможность для равов появится, но в приоритете эта задача не первая далеко. На удобстве это скажется самым малым образом. На скорости - гораздо сильнее.

[Deman32]

Для примера, чтоб не потерялись в спорах:



D700



RT vs PC D700







D750



D750

[Deman32]

D700

[Ратников Серёжа]

Точно. Можно просто мне выложить файл настроек. Под 750 камеру у меня в принципе всё есть: и профиль и ББ под пару условий освещения по цветной мишени. У меня ж у самого 750.

То есть вот этот маленький файлик - можно импортировать и применить к любым кадрам с D750? Можете тогда выложить его? Попробую )

[Deman32]

Его просто положить в папку с программой. Эти настройки будут выставляться при запуске программы. Ну и отталкиваться от них можете. ББ - пасмурно для 750.

https://yadi.sk/i/6rkrfpcewJqdv

[Ратников Серёжа]

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

[Deman32]

Просто сбросьте до нужного уровня. ББ естественно на все случаи жизни не бывает)

[Sound]

Демон.

Ядовитенькая необозженная глина по никоновски?

Нет?

[Deman32]

Да не, всё в норме. Даже по цифрам. 17-18, руки краснее. Если глина = пудра, то нет. Контраст в наличии. Лицо освещено больше, чем всё остальное, хорошо сказалось.





D700

[olegpan]

Пример явно не хорош. Тем более, это закат, как я понимаю.

[Deman32]

Чем? Кроме того что никон).

Детализация низкая, фон светлый, зелёный, что не есть хорошо. По цвету всё нормально, контраст на коже есть, пудры нет, налёта нет, заливки нет. Только не надо про восприятие и прочее.

[SPU]

Я смотрел, что в dcraw - даже если отбросить всё что не связано с чтением рава и демозаиком - на одну очень большую проблему переписывания потянет. Это хорошо, если возможность для равов появится, но в приоритете эта задача не первая далеко. На удобстве это скажется самым малым образом. На скорости - гораздо сильнее.

Зачем это все, когда есть готовый libraw с исходниками, да еще и со всякими оптимизациями? Нативный код цепяется к .Net элементарно.

По скорости разницы почти не будет.



ЗЫ: dcraw - это позапрошлый век.

ЗЫЫ: Чуть менее элементарно можно прицепить и никоновскую фирменную конвертацию.

[NikonDasker]

Вот такое окошко нарядного цвета:





По всем параметрам: контраст, ББ,- всё идентично. Разница в цвете заметна невооружённым глазом.

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



По этому снимку. Разница в цвете в данном случае заметна, но если вы сконвертируете рав-файл в тифф из лайтрума (а не в dcraw) и потом её подрихтуете в фотокоде, то разницы не будет.

Я сделал так: сконвертировал в разных конверторах тиффки без искажений: в АКР/LR, С1, ACDSee, RT, dcraw, Photivo. Старался не вносить изменений в выходной тифф.

Все что на основе dcraw (RT, Photivo) и сам dcraw дали практически идентичный результат затем в Фотокоде , что не удалось сделать из тиффок на основе прочих конверторов, там уже заметны сильные отклонения,

как не старайся вытянуть всё вашими опциями до бесконечности.

У вас на мой взгляд сложился некоторый стереотип, что тифф-это тот-же рав. Это неверно

jpeg является просто инкапсуляцией формата JPEG в формат TIFF. Формат TIFF позволяет хранить изображения, сжатые по стандарту JPEG, без потерь данных.

Распространенное среди некоторых пользователей мнение, что при записи как в TIFF, так и в RAW информация о кадре записывается без потерь, является в корне неверным.

Образ кадра без потерь сохраняется только в RAW. Информация о цвете заносится во время конвертации в тифф, цвет теряется или в большей степени остаётся в зависимости от выбранного конвертора, например

у Corel это заметно очень сильно в худшую строну-поэтому он непопулярен.

В вашем случае-это dcraw, который вы выбрали. Затем просто редактируем выходной растр вашей программой,

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



Вопрос выше почему-бы не сделать сразу конвертацию рав на основе libraw очень злободневен по этой теме.

[NikonDasker]

Зачем это все, когда есть готовый libraw с исходниками, да еще и со всякими оптимизациями? Нативный код цепяется к .Net элементарно.

По скорости разницы почти не будет.



ЗЫ: dcraw - это позапрошлый век.

ЗЫЫ: Чуть менее элементарно можно прицепить и никоновскую фирменную конвертацию.

Хороший вопрос, в целом побольше времени-бы можно бы и самому посидеть и сделать.

Но уже как я понял Борг и сотоварищи сделали.

[Deman32]

По этому снимку. Разница в цвете в данном случае заметна, но если вы сконвертируете рав-файл в тифф из лайтрума (а не в dcraw) и потом её подрихтуете в фотокоде, то разницы не будет.

Если на выходе из лайтрума получится точно такой же тифф как после dcraw, то да. А так нет. dcraw выбран для основы по одной простой причине: точность попадания цвета у него самая лучшая из всех. У РТ всё другое и точность ниже. Если есть какие-то ещё программы, дающие линейный тифф, идентичный dcraw, то можно и их использовать для подготовки тиффов.

Я сделал так: сконвертировал в разных конверторах тиффки без искажений: в АКР/LR, С1, ACDSee, RT, dcraw, Photivo. Старался не вносить изменений в выходной тифф.

Все что на основе dcraw (RT, Photivo) и сам dcraw дали практически идентичный результат затем в Фотокоде , что не удалось сделать из тиффок на основе прочих конверторов, там уже заметны сильные отклонения,

как не старайся вытянуть всё вашими опциями до бесконечности.

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

У вас на мой взгляд сложился некоторый стереотип, что тифф-это тот-же рав. Это неверно

jpeg является просто инкапсуляцией формата JPEG в формат TIFF. Формат TIFF позволяет хранить изображения, сжатые по стандарту JPEG, без потерь данных.

Распространенное среди некоторых пользователей мнение, что при записи как в TIFF, так и в RAW информация о кадре записывается без потерь, является в корне неверным.

Образ кадра без потерь сохраняется только в RAW. Информация о цвете заносится во время конвертации в тифф, цвет теряется или в большей степени остаётся в зависимости от выбранного конвертора, например

у Corel это заметно очень сильно в худшую строну-поэтому он непопулярен.

Я такого не говорил. Тифф сохраняет изображение таким, какое оно в раве за исключением мозайки. Ну плюс битность. Всё.

Говорить о тиффах из самих камер бессмысленно. Они даже не линейные. О них речь у меня и не идёт.

И никто не сжимает тифф по типу jpg. В моём случае это не делается.

В вашем случае-это dcraw, который вы выбрали. Затем просто редактируем выходной растр вашей программой,

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

В корне не верно. Заслуга dcraw в извлечении данных из рава и демозаике. Остальное что у него есть - гамма и яркость - работают точно так же как во всех конвертерах с тем же результатом. Хотите его увидеть - RPP. Искажения мною описываемые там никуда не уходят. Ну кроме пудры и морковки, возможно.

Был бы PhotoCode таким же простым редактором, я бы пользовался фотошопом. Попробуйте в нём поработать с этими тиффами).

Вопрос выше почему-бы не сделать сразу конвертацию рав на основе libraw очень злободневен по этой теме.

Так по сути и есть, только надстройка принципиально другая. Если вы думаете, что всё мелочи, то я вас огорчу.

Максимум что получится - примерная идентичность в очень хороших условиях съёмки с наименьшим ДД. Я про это в принципе всегда и говорю: если всё супер, то можно и jpg довольствоваться. А в 90% случаев НЕТ.

[xrite]

По идее нужна возможность открытия файлов напрямую из лайтрума.

Плавающая точка используется кстати ?

[Deman32]

Тифов в смысле? Так это просто настроить сам лайтрум на "открыть с помощью". У меня так в ACDSee настроено на PC и RAWConverter. Просто до безобразия.

Используется. Толку только от неё не много, самой заслуги в цвете у плавающей точки 1% от силы. Но я не экспериментировал, возможно, без неё были бы шумы в общем случае чуть выше. На глаз бы было незаметно.

[xrite]

Тифов в смысле? Так это просто настроить сам лайтрум на "открыть с помощью".

Почему тифов, равов. Чтобы сразу открывалось окно программы, а если сложно делать внутреннюю конвертацию, можно делать временный тиф, потом его открывать.

[Deman32]

Как-нибудь в будущем будет равы открывать. Но поймите, что демозаик - операция довольно длительная, и просто за минимальное удобство прямой работы с равами придётся платить временем. Лично меня не радует, когда, например, РТ долго думает над интерполяцией. Что-то поменяешь в настройках - опять думает. Зачем это?

[CADAS]

Вот и я скачал попробовать.

А что... Имеет право на жизнь. Удобно.

Буду следить за темой.

А для D90 есть профиль?

[Deman32]

Для всех камер могу предоставить. Вечером выложу на D90.

А что именно удобно и по сравнению с чем?

[CADAS]

За профиль спасибо!!!

Когда начинал снимать на Никон, проявлял в Капчуре. Позже перешел на шоп...

Удобства-- ну как бы меньше тело движений. колесиком удобно крутить.Скорость работы самой программы.

пока не понял как сохранить в джипег ( или в тифф,Все же допиливать приходиться в макро очень много в шопе).

Снимаю макро (большей частью). пока нового ни чего нет, как будет, покручу в этой программе.

[Deman32]

Зажать Shift и кликнуть по кнопке "S". Сохранит в 1000px по длинной стороне. Ограничение пробной версии.

[CADAS]

Зажать Shift и кликнуть по кнопке "S". Сохранит в 1000px по длинной стороне. Ограничение пробной версии.

Ясно понятно. Спасибо!

[CADAS]

при сохранении вылетает программа.

вот код

Описание:

Stopped working



Сигнатура проблемы:

Имя события проблемы: CLR20r3

Сигнатура проблемы 01: photocode.exe

Сигнатура проблемы 02: 1.0.0.0

Сигнатура проблемы 03: 57eb907a

Сигнатура проблемы 04: PhotoCode

Сигнатура проблемы 05: 1.0.0.0

Сигнатура проблемы 06: 57eb907a

Сигнатура проблемы 07: 35

Сигнатура проблемы 08: 4c0

Сигнатура проблемы 09: System.TypeLoadException

Версия ОС: 6.0.6001.2.1.0.256.6

Код языка: 1049

[LZ1]

dcraw выбран для основы по одной простой причине: точность попадания цвета у него самая лучшая из всех. У РТ всё другое и точность ниже.

Демозаик RT построен на dcraw.

[Deman32]

при сохранении вылетает программа.

вот код

Описание:

Stopped working



Сигнатура проблемы:

Имя события проблемы: CLR20r3

Сигнатура проблемы 01: photocode.exe

Сигнатура проблемы 02: 1.0.0.0

Сигнатура проблемы 03: 57eb907a

Сигнатура проблемы 04: PhotoCode

Сигнатура проблемы 05: 1.0.0.0

Сигнатура проблемы 06: 57eb907a

Сигнатура проблемы 07: 35

Сигнатура проблемы 08: 4c0

Сигнатура проблемы 09: System.TypeLoadException

Версия ОС: 6.0.6001.2.1.0.256.6

Код языка: 1049

Скачайте последний Net Framework. Но не 100% из-за него.

[Deman32]

Демозаик RT построен на dcraw.

Демозаик второстепенен в плане цвета, а его алгоритмы одни и те же у всех конвертеров +/-

rt другой цвет выдаёт

[SPU]

Но поймите, что демозаик - операция довольно длительная, и просто за минимальное удобство прямой работы с равами придётся платить временем. Лично меня не радует, когда, например, РТ долго думает над интерполяцией. Что-то поменяешь в настройках - опять думает. Зачем это?

Если вас устраивает чтение из тифа, то нет никакой необходимости делать повторный демозаик. Он нужен только при открытии файла, дальше все будет ровно то же самое.

Сплошные плюсы: место на диске не тратится, время на сохранение файлов и их чтение не тратится. Единственный возможный минус - это необходимость повторного демозаика при повторных массовых обработках тех же файлов, но эта разница крайне мала, плюс для halfres демозаик в принципе не нужен, что при подготовке картинок, например, для web, вообще сводит все возможные минусы на нет.

[NikonDasker]

Демозаик второстепенен в плане цвета, а его алгоритмы одни и те же у всех конвертеров +/-

rt другой цвет выдаёт

сами с собой вступаете в противоречие, то у вас "+/-", то rt другой цвет выдает. Эти самые плюсы и минусы очень многое определяют на самом деле.

[NikonDasker]

В корне не верно. Заслуга dcraw в извлечении данных из рава и демозаике. Остальное что у него есть - гамма и яркость - работают точно так же как во всех конвертерах с тем же результатом. Хотите его увидеть - RPP. Искажения мною описываемые там никуда не уходят. Ну кроме пудры и морковки, возможно.

Был бы PhotoCode таким же простым редактором, я бы пользовался фотошопом. Попробуйте в нём поработать с этими тиффами).

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

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

[Deman32]

Если вас устраивает чтение из тифа, то нет никакой необходимости делать повторный демозаик. Он нужен только при открытии файла, дальше все будет ровно то же самое.

Сплошные плюсы: место на диске не тратится, время на сохранение файлов и их чтение не тратится. Единственный возможный минус - это необходимость повторного демозаика при повторных массовых обработках тех же файлов, но эта разница крайне мала, плюс для halfres демозаик в принципе не нужен, что при подготовке картинок, например, для web, вообще сводит все возможные минусы на нет.

RT, например, при каждом сохранении делает демозаик. При каждом открытии рава придётся делать демозаик. Сегодня проявил, завтра посмотрел, не устроило - заново демозаик.

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

Как раз с равами и получается, что больше времени тратится на всё про всё.

Half для веба очень полезен. А где он есть? В RPP да и всё.

Я как раз за то, чтобы работать с тиффами. С нынешними SSD вообще всё быстро получается.

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

Я уже приводил данные для FX8120: открытие фотки D800 36 МПкс занимает 4 с, сохранение тоже 4 сек. NXD только предпросмотр 100% для 24 МП делает секунды за 3. Сдвинешь в сторону и опять приходится ждать отрисовки.

[Deman32]

сами с собой вступаете в противоречие, то у вас "+/-", то rt другой цвет выдает. Эти самые плюсы и минусы очень многое определяют на самом деле.

Я не вступаю ни в какие противоречия. Читаем: демозаик и цвет. Если у вас это одно и то же, то явно не во мне дело.

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

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

А зачем мне свой метод демозаика? Особенно если можно пользоваться тем, что предлагают другие программы? Я не любитель сам себе создавать лишние трудности. К чему вот это вот всё???

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

[Deman32]

Чтобы не рассуждать на пальцах, можно взять любой рав в том числе и чужой, проявить в разных программах и выложить для просмотра. Потом расписать свою точку зрения по цвету фотографий. Иначе получается как те рассказы про то как кенон могёт и даже лучше.

Или прислать параметры конвертации, которые есть практически у каждого конвертера. Я бы открыл и посмотрел. Не важно, какая фотография по сюжету и прочему, важно как её проявляет конвертер.

[SPU]

Half для веба очень полезен. А где он есть? В RPP да и всё.

RPP на том же libraw сделан. Half вообще вещь элементарная. Вместо демозаика просто делается один пиксель из 4-х, зеленый усредняется, остальные остаются как есть.

Полноценные конвертеры требуют повторного демозаика при редактированнии, т.к. работают с данными на несколько ином уровне.

[Deman32]

RPP на том же libraw сделан. Half вообще вещь элементарная. Вместо демозаика просто делается один пиксель из 4-х, зеленый усредняется, остальные остаются как есть.

Полноценные конвертеры требуют повторного демозаика при редактированнии, т.к. работают с данными на несколько ином уровне.

Да с half и rpp понятно и так.

А подробнее про другой уровень и с характеристикой результата, который этот уровень выдаёт? Я просто какой конвертер не пробовал, всё "мутнячок" (с) и серятина. Как не верти их инструменты, а через какое-то время смотришь на картинку и всё равно что-то не нравится. С PhotoCode у меня такого почему-то нет.

[Deman32]

Вот, например, как работает RT с идентичными настройками проявки:



RT vs PC

Почему света такие бледные, а тени - вырви глаз? Другой уровень работы? Для чего мне такой уровень?

[MorSeAn]

...

Spoiler: [+]

RT vs PC

Почему света такие бледные, а тени - вырви глаз? Другой уровень работы? Для чего мне такой уровень?

Лучше скажите, откуда PC накрутил такой "шум"?!

[Deman32]

С каких это пор чистый цвет стал шумней рт-шной серятины?

[Deman32]

Вообще очень забавно слышать о шумах, когда с появлением PhotoCode я вообще забыл, что такое шумодав.

Как раз серость и создаёт терапиям и прочим дополнительный шум. Вот этот разбаланс насыщенностей, когда света и тени блеклые, а середина насыщена, способствует дополнительному шуму - мало того, что пиксели разнятся по тону и яркости, РТ приливает туда ещё чехарду с насыщенностью. Полный букет).

[olegpan]

Да, шума стало больше. Т.е. имеем подтяжку теней с увеличением их насыщенности.



Достаточно посмотреть на темный треугольник в правом верхнем углу - версия с РС светлее, цветнее и шумнее.