все, the бисер is over
дальше общаюсь только с адекватными ))
Помогите с выбором ФФ
Всего 777 сообщ.
|
Показаны 521 - 540
Re[Цых]:
Re[Цых]:
от: Цых
все, the бисер is over
дальше общаюсь только с адекватными ))
Вы мне ярлык пытаетесь приладить? Мда, жесть, грусно.
Бисер метать не собираюсь.
Адьюс Амиго.
RPP VS ALL!!!!!!!!
RPP VS ALL!
Cмотрим на все конверторы сразу c примерами:
http://www.openphotographyforums.com/forums/showthread.php?t=11318
Обработка равов с Сони А900 разными конвертерами и тестовые картинки на предмет обработки шумов:
http://www.luminous-landscape.com/reviews/cameras/a900-one-month.shtml
Вообщем лично мне кажется все это на уровне подсознания! кому-то рпп милее, а кому-то и простой и добрый ЛР!!!
Цых - миру мир!
зы
Я боюсь киБорга! :D
Cмотрим на все конверторы сразу c примерами:
http://www.openphotographyforums.com/forums/showthread.php?t=11318
Обработка равов с Сони А900 разными конвертерами и тестовые картинки на предмет обработки шумов:
http://www.luminous-landscape.com/reviews/cameras/a900-one-month.shtml
Вообщем лично мне кажется все это на уровне подсознания! кому-то рпп милее, а кому-то и простой и добрый ЛР!!!
Цых - миру мир!
зы
Я боюсь киБорга! :D
Re[hatul]:
Я уже повторяюсь, но для CANON родная Digital Photo Professional сейчас покрывает 95% всех потребностей, и по цвету переплёвывает многие конвекторы и проги(тот же Lightroom).
Re[Evgeniy_B]:
от: Evgeniy_B
Я уже повторяюсь, но для CANON родная Digital Photo Professional сейчас покрывает 95% всех потребностей, и по цвету переплёвывает многие конвекторы и проги(тот же Lightroom).
Вы это не мне, а Цыху скажите! Но он Вам не поверит!
Re[hatul]:
от: hatul
Вы это не мне, а Цыху скажите! Но он Вам не поверит!
Конечно не поверит, у него Никон. 8)
Re[hatul]:
от: hatul
Вы это не мне, а Цыху скажите! Но он Вам не поверит!
Я не только вам, я всем. Некоторым не стоит ничего говорить, они сами всё знают и усложняют, когда ненужно.
Re[olegtal]:
от: olegtal
Конечно не поверит, у него Никон. 8)
Поймите, Олег, Lr например, делает дематризацию 2 раза: первый на стадии импорта, когда генерирует превью, второй - на стадии получения готового продукта, т.е. изображения в виде стандартизованного файла. Результаты всех операций по обработке последовательно отображаются на превью - оно имитатор работы. Много операций накапливают ошибку отображения, это неизбежно. Lr хитра, она делает незаметные коррекции, но этого недостаточно. Поэтому выходной файл отличается от той картинки, которую вы видите на экране конвертера, иногда неуловимо, а иногда существенно. Разве вы этого никогда не замечали? Только опыт позволяет вам знать с большой долей вероятности результат заранее. Зато работа комфортная и быстрая.
RPP всегда находится в стадии цикла в ожидании "выполнить". И каждая операция (почти!) или сумма операций есть как бы входной фильтр к дебайеру. Поэтому видимость результата операции всегда тождественна самой операции.
Жмете "Apply" - дебайер. Потом, например, баланс белого - "Apply" - дебайер и т.д. А еще там есть новые модернизированные уникальные инструменты.
Но за все приходится расплачиваться. Чем-то. И это еще не вся правда.
И если результат в любимом конвертере вас устраивает, то чего тогда копья ломать?
Re[KSerX]:
от: KSerX
Поймите, Олег, Lr например, делает дематризацию 2 раза....
Фууу(Выдох)," вкурили" наконец то, т.е. все таки два раза эта "хрен" происходит(Цых и иже с ними грит об одно разе и о промежуточном массиве и конвертация т олько один раз), так кто утвердил что "промежуточный массив" который преобразован из рав +коррекция(с учетом недостатков РАВ-сигнал с матрицы+АЦП) не является "истиной") и что этот массив в процессе сдвигания движков меняется?
Вам этот бред не надоел от ГУРУ из народа(не Цых)? Изобрели очередной ДИСИРО и вешают лапшу на уши, жесть. Каждый крутит на монике свои цвета и создает свою гармонию картинки и пофиг инструмент, какой он ее(гармонию) создал автор в момент редактирования, такой мы ее и видим(клаберы) и балдеем. Все в руках автора, а не в недрах инструмента(конвертора).
И еще, фотать надо уметь - то есть экспозицию правильно померять, как по меряешь, таков и рав получишь.
ЗЫ надеюсь написал доступно :)
Re[olegtal]:
от:olegtal
Фууу(Выдох)," вкурили" наконец то, т.е. все таки два раза эта "хрен" происходит(Цых и иже с ними грит об одно разе и о промежуточном массиве и конвертация т олько один раз), так кто утвердил что "промежуточный массив" который преобразован из рав +коррекция(с учетом недостатков РАВ-сигнал с матрицы+АЦП) не является "истиной") и что этот массив в процессе сдвигания движков меняется?
Вам этот бред не надоел от ГУРУ из народа(не Цых)? Изобрели очередной ДИСИРО и вешают лапшу на уши, жесть. Каждый крутит на монике свои цвета и создает свою гармонию картинки и пофиг инструмент, какой он ее(гармонию) создал автор в момент редактирования, такой мы ее и видим(клаберы) и балдеем. Все в руках автора, а не в недрах инструмента(конвертора).
И еще, фотать надо уметь - то есть экспозицию правильно померять, как по меряешь, таков и рав получишь.
ЗЫ надеюсь написал доступно :)Подробнее
Все, что вы двигаете в классическом конвертере - это по сути пустышка, имитация. Но можно расплатиться неточностью как бы обработки, считаем, что все сделали как надо, ан не совсем. Но система хитрая. Например, стек операций: заполняем - погрешность накапливается, откатываем - вычитается, так как операции точные, материал вот слабоват. Мы не можем из середины стека "выдернуть" операцию, только все, что сверху, включая ее. В РПП можно. Более того, я подозреваю, что может быть несколько превью для одной картинки, а также самопроизвольная перегенерация их без нашего желания.
В РПП - процесс обработки - честный, как писал Цых. Но конечный результат отличается на уровне нравится-не нравится (ИМХО). Инструментарий там интересный, более гибкий, судя по объяснениям авторов.
Кстати, первый дебайер в Lr - упрощенный какой-то. Он полноразмерные заготовки строгает за 2-3 сек и грузит их в модуле редактора мгновенно, и с ними можно мгновенно же "работать" и листать, а выходной Жипег - 6-8 сек (i5-2500) - даже без обработки. Неужели он столько пишет уже готовое?
Тогда это была бы клоунада низкого пошиба.
Re[Evgeniy_B]:
DPP действительно для кэнона один из лучших конверторов. Заметно лучше Лайтрума. Спорить не буду )
А сам я сижу в С1 (95%) и в RPP (5%), а то я прям все думают что я бескомпромиссный фанат рппшный. Просто у меня потоки большие поэтому приходится воркфлоу делать в С1, тем более что он ICC профили понимает входные.
Кстати, был у Дмитрия Новака топик занятный, пытка конверторов красным цветом )
http://dmitry-novak.livejournal.com/31455.html
результаты
http://dmitry-novak.livejournal.com/31785.html
А сам я на лайтрум пытался пересесть 3 раза начиная с самого его анонса, но блин не могу я терпеть эту убогую работу с цветом. То что в РПП или в С1 делается моментально - в ЛР приходится крутить и крутить и крутить очень долго.
А сам я сижу в С1 (95%) и в RPP (5%), а то я прям все думают что я бескомпромиссный фанат рппшный. Просто у меня потоки большие поэтому приходится воркфлоу делать в С1, тем более что он ICC профили понимает входные.
Кстати, был у Дмитрия Новака топик занятный, пытка конверторов красным цветом )
http://dmitry-novak.livejournal.com/31455.html
результаты
http://dmitry-novak.livejournal.com/31785.html
А сам я на лайтрум пытался пересесть 3 раза начиная с самого его анонса, но блин не могу я терпеть эту убогую работу с цветом. То что в РПП или в С1 делается моментально - в ЛР приходится крутить и крутить и крутить очень долго.
Re[olegtal]:
Делаю последнюю попытку, через аналогию )) Так обычно понимают даже дети.
Вот вы нарисовали градиент от черного к белому допустим. Потом накинули на него яркости, потом кривыми обработали поканальными, потом насыщенности накинули, потом контраст понизили. Что у нас получится в итоге? Так вот так делает лайтрум и другие конверторы. Работают с тем что он сгенерилось в самом начале. Пусть даже хитро сгенерил подрисовав снизу несклько бит для большей точности. РПП после каждого APPLY перерисовывает градиент заново с учетом выполненных преобразований. Т.е. в итоге вся последовательность яркость-кривые-насыщенность-контраст просчитывается сразу (32-bit floating point), высчитываются коэффициенты ББ и делается дебаер.
Вот иллюстрация этих действий. В итоге получаем рваный градиент. Последний градиент это нарисованый с нуля. Так делает RPP.
ферштейн? Поэтому какие вы там контрольные точки хотели мерять я не совсем понимаю. Я не говорил что если 300 раз дернуть попеременно ползунки яркости и контраста все сложится. Естесственно все там делается не настолько тупо как вы себе представляете списав это якобы на мои слова. ))
Вот вы нарисовали градиент от черного к белому допустим. Потом накинули на него яркости, потом кривыми обработали поканальными, потом насыщенности накинули, потом контраст понизили. Что у нас получится в итоге? Так вот так делает лайтрум и другие конверторы. Работают с тем что он сгенерилось в самом начале. Пусть даже хитро сгенерил подрисовав снизу несклько бит для большей точности. РПП после каждого APPLY перерисовывает градиент заново с учетом выполненных преобразований. Т.е. в итоге вся последовательность яркость-кривые-насыщенность-контраст просчитывается сразу (32-bit floating point), высчитываются коэффициенты ББ и делается дебаер.
Вот иллюстрация этих действий. В итоге получаем рваный градиент. Последний градиент это нарисованый с нуля. Так делает RPP.
ферштейн? Поэтому какие вы там контрольные точки хотели мерять я не совсем понимаю. Я не говорил что если 300 раз дернуть попеременно ползунки яркости и контраста все сложится. Естесственно все там делается не настолько тупо как вы себе представляете списав это якобы на мои слова. ))
Re[Minato]:
Да всё это хрень полная...
Никому никогда ничего никто не докажет.
Кому-то просто цвет по барабану в принципе ему разница несущественная... Кому-то существенная и он будет искать и пробовать...
Ещё тут 99% обоих камер в руках не держала.
Ну и пусть кто хочет думает, что обработка позволяет получить с любой камеры одинаковый цвет. Пусть это будет так...
Если кто-то считает разницу в 10% между камерами несущественной, тогда какой смысл вообще что-либо обсуждать. С таким подходом можно снимать любой камерой, выпущенной с 2001 года - разница будет не более 10%?
Автору темы?
Ну а Вы что думаете вообще?
Никому никогда ничего никто не докажет.
Кому-то просто цвет по барабану в принципе ему разница несущественная... Кому-то существенная и он будет искать и пробовать...
Ещё тут 99% обоих камер в руках не держала.
Ну и пусть кто хочет думает, что обработка позволяет получить с любой камеры одинаковый цвет. Пусть это будет так...
Если кто-то считает разницу в 10% между камерами несущественной, тогда какой смысл вообще что-либо обсуждать. С таким подходом можно снимать любой камерой, выпущенной с 2001 года - разница будет не более 10%?
Автору темы?
Ну а Вы что думаете вообще?
Re[Цых]:
от: Цых
DPP действительно для кэнона один из лучших конверторов. Заметно лучше Лайтрума. Спорить не буду )
Можно с этого места поподробней?
Цвет вроде в лайтруме легко делается как в DPP, а по шумам лайтрум все конкуренции.
Re[Александр Лэм]:
от: Александр Лэм
а по шумам лайтрум все конкуренции.
+1
А вообще, баталий по поводу конвертера не понимаю.
Для работы, когда обрабатыать нужно кучу снимков - лучше тот конвертор, который позволяет сделать это не только качественно, но и быстро, без лишних движений...
А личные, еденичны файлы обрабтывать и вылизывать, не знаю кому как, а мне уже просто тупо лень пялиться в монитор :) До ряби в глазах
Re[Александр Лэм]:
от: Александр Лэм
Можно с этого места поподробней?
Цвет вроде в лайтруме легко делается как в DPP, а по шумам лайтрум все конкуренции.
Для меня лучше цвет в Digital Photo Professional, чем в ЛАЙТРУМЕ, только по личному опыту, мнению и по отзывам.
Как правило, у большинства фотографии сделаны на низких ISO, тут неплохо справляется Digital Photo Professional , а функционала у свежих версий хватает.
Re[Minato]:
[quot]Так делает RPP. [/quot]
При предварительном просмотре возможно, хотя и сомнительно т.к. в таком случае картинка визуально бы деградировала прямо в процессе двигания ползунков, а это не так.
При окончательной конвертации любой конвертор применяет все операции к исходному битовому массиву.
Так что преимущество RPP только в том, что он (вероятно) позволяет видеть более корректную картинку в момент редактирования (предварительного просмотра) Для получения окончательного файла это не имеет значения.
Расплачиваться же за эту более корректную картинку в момент просмотра приходится нажатиями Apply и клавиатурным вводом. Тут дело личных предпочтений.
По поводу операций с плавающей точкой в RPP.
Во-первых этот конвертор далеко не единственный, который выполняет пересчеты с плавающей точкой. Другие примеры - DCRaw, Raw Therapee, Aperture (тут не уверен).
Во-вторых, пример с 5/2 является абсолютной профанацией. На входе конвертора целочисленный массив информации с АЦП. На выходе конвертора опять же целочисленный массив информации.
Т.е. как бы мы не считали с плавающей точкой, в итоге все равно переводить это значение в целое число. Все равно в какой-то момент придется принять решение куда округлять 2.5: в 2 или в 3.
Далее, вы, как я понимаю, весьма далеки от программирования. И вам будет любопытно узнать, что проблема потери точности в целочисленных операциях давно решена специальными алгоритмами целочисленных вычислений. Есть специальные целочисленные алгоритмы и деления, и умножения, и возведения в степень, позволяющие добиться достаточно малой потери точности при таких вычислениях.
Даже такая операция как интерполяция может выполняться целочисленно.
Само собой, вычисления с плавающей точкой точнее, однако же разница не настолько потрясающа, как вам кажется.
Следующий момент, вы почему-то представляете целое число как противоположность числу с плавающей точкой. Путаете понятия.
Есть целые числа и вещественные числа (1 и 0.5).
Есть числа с фиксированной точкой и с плавающей точкой. Это уже вопрос хранения информации в программе.
Вещественные числа могут храниться как в формате с фиксированной точкой, так и с плавающей точкой.
То, что конвертор Борга использует плавающую точку, совершенно не означает что другие конверторы используют целые числа. Они вполне могут использовать вещественные числа, храня их в формате с фиксированной точкой.
При предварительном просмотре возможно, хотя и сомнительно т.к. в таком случае картинка визуально бы деградировала прямо в процессе двигания ползунков, а это не так.
При окончательной конвертации любой конвертор применяет все операции к исходному битовому массиву.
Так что преимущество RPP только в том, что он (вероятно) позволяет видеть более корректную картинку в момент редактирования (предварительного просмотра) Для получения окончательного файла это не имеет значения.
Расплачиваться же за эту более корректную картинку в момент просмотра приходится нажатиями Apply и клавиатурным вводом. Тут дело личных предпочтений.
По поводу операций с плавающей точкой в RPP.
Во-первых этот конвертор далеко не единственный, который выполняет пересчеты с плавающей точкой. Другие примеры - DCRaw, Raw Therapee, Aperture (тут не уверен).
Во-вторых, пример с 5/2 является абсолютной профанацией. На входе конвертора целочисленный массив информации с АЦП. На выходе конвертора опять же целочисленный массив информации.
Т.е. как бы мы не считали с плавающей точкой, в итоге все равно переводить это значение в целое число. Все равно в какой-то момент придется принять решение куда округлять 2.5: в 2 или в 3.
Далее, вы, как я понимаю, весьма далеки от программирования. И вам будет любопытно узнать, что проблема потери точности в целочисленных операциях давно решена специальными алгоритмами целочисленных вычислений. Есть специальные целочисленные алгоритмы и деления, и умножения, и возведения в степень, позволяющие добиться достаточно малой потери точности при таких вычислениях.
Даже такая операция как интерполяция может выполняться целочисленно.
Само собой, вычисления с плавающей точкой точнее, однако же разница не настолько потрясающа, как вам кажется.
Следующий момент, вы почему-то представляете целое число как противоположность числу с плавающей точкой. Путаете понятия.
Есть целые числа и вещественные числа (1 и 0.5).
Есть числа с фиксированной точкой и с плавающей точкой. Это уже вопрос хранения информации в программе.
Вещественные числа могут храниться как в формате с фиксированной точкой, так и с плавающей точкой.
То, что конвертор Борга использует плавающую точку, совершенно не означает что другие конверторы используют целые числа. Они вполне могут использовать вещественные числа, храня их в формате с фиксированной точкой.
Re[Evgeniy_B]:
от:Evgeniy_B
Для меня лучше цвет в Digital Photo Professional, чем в ЛАЙТРУМЕ, только по личному опыту, мнению и по отзывам.
Как правило, у большинства фотографии сделаны на низких ISO, тут неплохо справляется Digital Photo Professional , а функционала у свежих версий хватает.Подробнее
Я пока тоже сижу в DPP, так чиста на всякий случай :) (раньше с кеноном дела не имел).
Но пару экспериментов в лайтруме показали, что цвет подгоняется на раз.
Одно но, чтоб знать в какой сторону крутить, нужно сначала сконвертить в DPP )))). А то можно накрутить огого ))
Вот почему я всегда против выражения, что на цифре цвет можно накрутить любой.
Вспоминается сразу:
Завод КриворожСталь начал выпускать трубы разного диаметра.
Первая труба разного диаметра сошла с конвеера.........
Это, кста, и по поводу всех конвертеров дающих самую сырую картинку. Ну ее в ж эту сырую картинку, уж лучше стартовать с более реальных вариантов.
Re[Александр Лэм]:
Для RAW-ов с Canon-а в DPP приемлемый цвет получается сразу, его можно подогнать при желании еще лучше в фотошопе. В других конверторах мне ,например, приходилось возиться, чтобы получить тот же цвет.
Возможно кривые мои руки виноваты, но зачем тратить драгоценное время ?
Непонятно зачем мучиться с "правильным" конвертором только ради того, что он "правильный", а "правильный" он только потому, что так сказал сам Великий Борг. Тем более, что Цых, расхваливая RPP, тут же пишет, что использует его в 5% случаев.
Возможно кривые мои руки виноваты, но зачем тратить драгоценное время ?
Непонятно зачем мучиться с "правильным" конвертором только ради того, что он "правильный", а "правильный" он только потому, что так сказал сам Великий Борг. Тем более, что Цых, расхваливая RPP, тут же пишет, что использует его в 5% случаев.
Re[Crimson23]:
от:Crimson23
[quot]Так делает RPP. [/quot]
По поводу операций с плавающей точкой в RPP.
Во-первых этот конвертор далеко не единственный, который выполняет пересчеты с плавающей точкой. Другие примеры - DCRaw, Raw Therapee, Aperture (тут не уверен).Подробнее
+1. LightZone например тоже все пересчитывает в (как пишут их маркетолухи) 16 bit linear color space. При любом изменении любого ползунка любого инструмента в стеке все пересчитывается. Надо сказать, очень прилично тормозит, когда стек инструментов большой. И инструменты, кстати, можно явно менять местами в стеке, и тоже все при этом пересчитывается.
