Photoshop CS4: первые впечатления

lexa - 26/Окт/2008 19:43

Два дня всерьез пользую CS4, впечатления смешанные:

  • 64-битный - сцуко, быстрый. Если быть точным, то сохранение (layered tiff, PSD, PNG) не кажется быстрее прошлых версий, а вот работа с большим количеством здоровых открытых файлов - не тормозит.
  • Естественно, ни один из старых 3rd-party плагинов под 64-бита не работает. В результате двустадийный Workflow (RPP - Lab - Photoshop - RGB) стал трехстадийным (RPP - Lab -PSx64(основная обработка) - Lab - PSx32(плагины)). На каждом шаге количество обрабатываемого падает в разы, поэтому жить можно.
  • 32-битный по ощущениям медленее.

Но есть некоторое количество довольно мерзких багов.

  • Ctrl-0 делает картинку больше, чем экран. Точнее, в старом фотошопе все было бы отлично, а вот если использовать новомодное окно с табами, то поправку на высоту табов не делают.
  • В ряде случаев, сохранение файла Фотошопом сбивает рейтинг, поставленный бриджем. Пока кажется, что это бывает если файл не открывался через бридж, но буду изучать.
  • Перетаскивание окна Bridge между окнами не меняет экранный профиль "в который" рендерит бридж.
  • Настройка 'Remember Panel Location' ужасающа - Panel можно чуть-чуть сдвинуть с места, а дальше оно не дается. Уроды.

Ну а вообще, принципиальное отличие - это скорость работы. Действительно многое сильно быстрее. Остальное - косметические удобства (или я пока чего-то важного не нашел).

Comments

lair (not verified) - 26/Окт/2008 14:17

А 32-битный четвертый медленнее 32-битного третьего или быстрее?

lexa - 26/Окт/2008 14:21

Я никаких тестов не проводил, поэтому не знаю.

64-битный - я оттранслировал свою методу работы с предыдущей версией (открыть штук 15 файлов, поработать, нажать Save All и пойти пить чай) - органолептически сильно быстрее

lazybird.ru (not verified) - 26/Окт/2008 20:42

Ты RAM-диск не используешь теперь? Он скратч все равно сразу создает при открытии файла?

lexa - 26/Окт/2008 20:47

RAM-диск теперь не использую. Скратч создает, но он поменьше, насколько я могу судить.

lair (not verified) - 26/Окт/2008 16:18

Кстати, занятно. У меня первый баг не воспроизводится.

lexa - 26/Окт/2008 16:27

У меня окошко с табами - на отдельном мониторе на весь экран.

Когда в пределах рабочего поля фотошопа - все вроде работает.

photo_vs (not verified) - 26/Окт/2008 17:04

сегодня только обрабатывал фото в 230 мегапикс
4GB RAM и дикий свопинг.

вот эта фотошопохеротация что то может исправить или все это в морг и переходим на мак?

lexa - 26/Окт/2008 17:19

на маках - хуже. CS4 на маках - только 32 битный, независимо от количества памяти. Т.е. если памяти - гигабайт 8-16, то PC и 64-битный фотошоп будут лучше.

У меня 230Mpix нету под рукой, нашлось только 60. Я бы сказал, что _очень_ бодренько (пробовал всякие adjustment layers). памяти - 8 гигабайт, еще ~4 14-мегапиксельных файла были открыты ибо в работе.

photo_vs (not verified) - 26/Окт/2008 18:39

насолько я помно то виндоуз 32 бит может отдавать фотошопу не более 1,750Gb RAM, оттого работать с файлами выше 1Gb в XP весьма гиморно.

kerozin (not verified) - 26/Окт/2008 22:46

Речь о PSx64, соответственно - Win64. И понятно, что во всем этом появляется смысл когда памяти больше 4Г.

lexa - 27/Окт/2008 01:18

У меня - 64-битные windows давно. Они могут отдать 32-битному фотошопу ~3.5 гигабайта, а 64-битному - скока есть.

photo_vs (not verified) - 27/Окт/2008 02:20

Ну вот блин.
Как ни отмахивайся, а все идет к тому что надо переезжать на новую ос :(

lexa - 27/Окт/2008 02:42

Ну так 21-й век на дворе, пора уже.
3-4-5 лет назад сервера перевели на 64 бита, теперь очередь десктопов.

И в современных условиях - уже можно смело ставить Висту-64бита, а 64-битную XP забыть

Anton Petrusevich (not verified) - 28/Окт/2008 02:41

> а 64-битную XP забыть

Не флейма ради, но информации для. А что, в висте уже можно работать? А что плохо в XP/64? Я винду только в виртуалке вижу, так что мне стало интересно, кому уже можно больше 2г отдать.

lexa - 28/Окт/2008 07:23

Да, можно работать.
Я не вижу никакой значимой разницы с XP x64 - драйвера есть, программы работают, все быстро.
http://twitter.lexa.ru/2008/10/oskoromilsja.html

Anton Petrusevich (not verified) - 28/Окт/2008 15:04

У меня не проблемы с драйверами -- vmware вполне стандартное "железо". Но поставлю пожалуй висту, на перспективу, чтобы понять как именно надо vpn клиента запускать чтобы рутинг работал (почему-то не работает для некоторых интерфейсов перенастройка дефолта), под икспи проблемы нет, а лечить проблему на ситеме, которую в глаза ни разу не видел, довольно трудно.

Lev Serebryakov (not verified) - 28/Окт/2008 16:49

Я тут обнаружил первую засаду. Точнее, вторую, но на практике первую. Нет Cisco VPN Client'а. Вообще. Напрочь. А я им на работу хожу.

Первая же, пока теоретическая -- под мой слайд-сканер драйверов x64 нету. Но, думаю, он мне не понадобится уже. Надеюсь. Но обидно :)

lexa - 28/Окт/2008 17:00

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_qanda_ite...
... but 64-bit support is available for the Cisco AnyConnect VPN Client...

Lev Serebryakov (not verified) - 29/Окт/2008 19:11

Авотфиг! После того, как я его добыл (пиратским методом -- просто так не скачать) он не поставился со словами про неподдерживаемую систему.

Anatoly Skoblov (not verified) - 27/Окт/2008 18:30

/3GB в boot.ini увеличивает этот лимит.

Anatoly Skoblov (not verified) - 27/Окт/2008 18:38

/3GB в boot.ini увеличивает этот лимит.

Anatoly Skoblov (not verified) - 27/Окт/2008 18:47

У меня файл в 200Mпикселей был всего 1 раз, не помню уже впечатления, но что не дикий тормоз - это факт. А вот 2Gb файлы - это норма, а сразу после сборки панорамы до удаления лишних слоев бывает и 5Gb. На машине 2Gb памяти и криминально фотошоп не тормозит. Открывает/закрывает медленно - это факт.

mak_ (not verified) - 27/Окт/2008 00:26

как-то я потихоньку отползаю с фотошопа (за исключением панорам) в лайтрум. а не для панорам мне 64 бита вроде бы ни к чему:)
чай, не баре, по 15 файлов открывать и чай каждый раз пить...

lexa - 27/Окт/2008 01:19

Я в лайтруме небольшой специалист, но
- часть стадий обработки делаю в Lab
- correction layer с маской - совершенно обычно дело

mak_ (not verified) - 27/Окт/2008 14:45

я небольшой специалист в фотошопе - да и рисовать совершенно не умею:( и если у меня обработка карточки занимает больше 5-7 минут, я плюну и возьму другую:) лаб и слои - оно, конечно, сильно умное, воля ваша, профессор, да больно непонятное :) стараюсь снмать так, что бы обрабатывать было поменьше. сейчас обычно хватает crop и shadow/highlight.

lexa - 27/Окт/2008 14:55

Ну так на цифру нельзя снимать "так, чтобы обрабатывать поменьше". Как минимум, нужно тоновую кривую пленочную (как у слайда). Ну и "поднять насыщенность в светах" мне кажется вполне жизненной задачей.

А S/H не люблю, не умею и не пользую.

mak_ (not verified) - 27/Окт/2008 17:06

почему нельзя? можно.
а в тоновых кривых уже совсем ничего не поинмаю:) это уже многовато для простого любителя.
а вот поднять насыщенность в светах - это как раз s/h и есть.

lexa - 28/Окт/2008 07:44

В RAW? Не, нельзя, это полуфабрикат.

Ну вот, например, у вас есть конфликт между тем, что во многих сценах надо сжать света (они светлее, чем 2.7-3 стопа от среднего тона), ну а средний тон должен же тоже быть на месте.
Значит недодерживаем, потом кривую прикладываем.
http://www.libraw.su/articles/ettr-underexposure-wedges.html

mak_ (not verified) - 28/Окт/2008 15:55

я же не сказал - "совсем не обрабатывать" :)

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

Pasch (not verified) - 29/Окт/2008 13:24

Чего-то я наверное не понимаю с этими кривыми.
У нас при ETTR света и так прижаты к правому краю гистограммы.
Обычно хочется их потемнее при обработке сделать, а после применения такой кривой (для 2 стопов, скажем) они же просто уходят в "молоко". Или надо эти кривые применять с каким-либо маскированием по средним тонам?

lexa - 29/Окт/2008 13:36

Последовательность действий:
- замеряем средний тон
- замеряем света
Выясняем, что дельта больше трех стопов т.е. при проработке светов (ETTR) средний тон будет недодержан (относительно своего правильного замера).
- Снимаем (экспонируя по светам), недодержку знаем
- кривыми возвращаем средний тон на место

При этом света сожмутся, но не выбьются.

Необходимое замечание - Adobе-вские продукты помещают средний тон не на место.

Lev Serebryakov (not verified) - 30/Окт/2008 09:47

- замеряем средний тон
- замеряем света
Выясняем, что дельта больше трех стопов т.е. при проработке светов (ETTR) средний тон будет недодержан (относительно своего правильного замера).
- Снимаем (экспонируя по светам), недодержку знаем
Ты в блокноктик для каждого кадра недодержку записываешь?
И как быстро средний тон найти, не подкладывая карточку в сцену? :)

lexa - 30/Окт/2008 09:51

Зачем в блокнотик? Я же знаю, что должно стать средним тоном и вижу где он (по шкале L) на самом деле находится.

А подкладывать карточку - не надо, это аналог замера по падающему, что мы осуждаем. Всегда ведь понятно, что должно быть средним (=самым проработанным) тоном. Ну, почти всегда.

Lev Serebryakov (not verified) - 30/Окт/2008 10:08

Не-а, мне вот далеко не всегда :) Кручу-верчу, и так плохо и эдак :)

Кстати, о L. Я тут набрёл на сайт, где человек убедительно показывает, что ни L в LAB ни режим смешения Luminosity (что, по логике должен быть тот же L) в PhotoShop не есть чистая тональная кривая. И даёт экшены, которые собирают из пятка слоёв настояющую тональную кривую. Правда, экшены делают аткие слои, что мне кажется что и 16-ти бит не должно хватать -- они сначала всё утрамбовывают в узкий диапазон а потом его декомпрессируют, а собственно заданную пользователем кривую применяют между этими действиями.

Поискать ссылку, интересно?

Pasch (not verified) - 30/Окт/2008 13:18

Согласен, что не выбьются, а сожмутся. "Молоко" - не вполне удачный термин :)
Но контраст по светам сильно понизится - оно надо? Редко когда небо хочется сделать светлее, обычно - наоборот.
Просто ETTR применяют как раз чтобы света сохранить, а при последующей обработке - и усилить (ИМХО).

lexa - 30/Окт/2008 14:00

Ну невозможно одновременно и рыбку съесть и на качелях покачаться.

"Аксиомы"
1) Средний тон (снимка) должен быть на отпечатке/мониторе в районе L=50. Там лучшее место для восприятия
2) Света не могут быть выше L=100 по определению (пространства Lab)

Если мы вспомним, что от L=50 до L=100 - меньше трех стопов, то что нам делать, если этих стопов в реальности больше (пример - неосвещенная солнцем гора на фоне голубого неба с освещенными солнцем облаками)?
Классики в таких случаях понижали контраст градиентными фильтрами, либо не снимали (ждали более благоприятного света). Но мы не классики и вообще не профи, мы в этой точке больше никогда не будем, снимать надо, а градиентных фильтров у нас нет.

Мы в любом случае должны привести средний тон на место (L=50, в крайнем случае на стоп темнее, не более). Сделать это можно за счет сжатия либо всех светов (когда там что-то есть по всему диапазону), либо если нам повезло и между "небом-облаками" и "горой" ничего нет по яркости - можно сжимать эти несуществующие промежуточные тона.

Второе легче всего достигается съемкой двух кадров и склейкой (через HDR или просто наложением по маске или еще как).
А первое - этими самыми кривыми.

Ну еще нам полстопа-стоп подарит разбаланс чувствительности по каналам и (некоторые) конверторы нейтральный тон порекаверят (а не-нейтральный - хуже).

Но лучше с блендой и фильтрами. http://www.libraw.su/articles/real-programmers-dont-use-filters.html

Pasch (not verified) - 30/Окт/2008 15:39

Увы, серебряной пули пока не придумали.
Но все-таки s/h часто помогает.

Anatoly Skoblov (not verified) - 29/Окт/2008 14:21

Света уходят не в молоко, а в низкий контраст, как на пленке. Приемлимость этого зависит от сюжета. Если света важны - то неприемлимо (и надо масками исправлять яркости), если не важны - можно использовать.

Pasch (not verified) - 30/Окт/2008 13:23

Согласен, но если света неважны - зачем тогда использовать ETTR?
Экспонировали бы просто по средним тонам и нет проблем.
А если уж постарались света сохранить, то жалко их потом портить низким контрастом.
Так что да, остаются или маски, или S/H.

Anatoly Skoblov (not verified) - 30/Окт/2008 22:27

Ээээ, батенька.

"Света не важны" и "светов нет" - это 2 большие разницы, как говорят у нас в Одессе.

Меня вот проработка пятен на солнце совсем не волнует, но мерзкое пятно в полкадра вместо солнца не нравится :)

Anatoly Skoblov (not verified) - 28/Окт/2008 22:10

s/h научиться полноценно пользоваться нельзя :) Эта дура очень ограниченного применения. Как и fill lights в ACR/LR. Чуть-чуть можно, тут особо учиться не надо.

Кривые плюс-минус накладываются в лайтруме, но я предпочитаю локальную коррекцию и проработанные света, поэтому твои кривые у меня не прижились.

Лайтрум вообще может очень много. Я сегодня с утра даже пост про это сделал:
http://skoblov.livejournal.com/37030.html
как любят писать фанаты: no photoshop, никакого Маргулиса :)

lexa - 28/Окт/2008 22:15

В Lab умеет?

Потому что мне синий (на небе) в твоей статье конкретно очень не понравился...

Anatoly Skoblov (not verified) - 29/Окт/2008 00:08

Lab не умеет. Я бы не отказался от некоего Lab layer :)

Кое для чего Lab нужен. Но когда очень нужен - можно и в фотошоп сходить.

А чем синий не понравился? Меня устраивает, соответствует моим ожиданиями. Можешь переделать так, как тебе кажется верным? А я посмотрю, можно ли это сдлеать в LR.

Я, пожалуй, даже в восторге, учитывая то, что мне предлагалось "по умолчанию". И пришел к ощущению, что возможности своей 350d я научился использовать на 100% и пришло время апгрейдиться.

Anatoly Skoblov (not verified) - 29/Окт/2008 23:14

Опппаааа
опросил народ
похоже что-тос небом не то
а я не вижу

ж-па :(

Anatoly Skoblov (not verified) - 28/Окт/2008 22:00

Лайтрум умеет "корректирующие слои с масками", но после пары слоев становится фантастическим тормозом.

Я практически перестал пользовать фотошоп для отдельных кадров после выхода второго лайтрума.

lexa - 27/Окт/2008 01:29

Вдогонку,

~300мегабайт (а это 14-мегапиксельный файл с 2-3 слоями) сохраняются довольно долго. Когда он один - это просто бесполезное время. Когда их 15 - это в самый раз ненадолго отойти.

photo_vs (not verified) - 27/Окт/2008 02:25

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

lexa - 27/Окт/2008 02:47

Насколько я знаю, в раньшие годы (когда несколько-гигабайтные сканы уже были, а компьютеров сегодняшних не было) работали как-то так:
- или записывали последовательность обработки в action (на low-res картинки), а потом применяли к полноразмерной картинке
- или делали все корректирующими слоями (тоже на маленьком образце), а потом resize до нужного размера и paste полномасштабный исходник в нижний слой.

Все от бедности, конечно....

photo_vs (not verified) - 27/Окт/2008 02:57

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

Меня больше психологические вещи напрягают - что есть 2гб свободной памяти но при этом фотошоп притормаживает свопингом.

lexa - 27/Окт/2008 03:08

Психологически - 64-битная винда (любая из имеющихся, хотя Сервер не рекомендую) - и 32-битный фотошоп (и новый CS4 и CS3) увидят ~3.5 гига.
Кроме того, сама винда увидит все 4 гигабайта памяти, а не "4 минус окно под PCIe/AGP" (на одной из моих машин 32-битная винда видит 2.7Gb из 8-ми т.к. эти самые 1.3 съедаются под окно видеокарты и RAID-контроллера).

Больше памяти и 64-битный фотошоп - только если не используются какие-то сторонние плагины (ибо старые плагины с 32-битной версией совместимы, а с 64-битной - нет)

mak_ (not verified) - 27/Окт/2008 14:48

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

Lev Serebryakov (not verified) - 28/Окт/2008 17:03

Слушай, а не опишешь свой Workflow с комментариями?
А то все эти статьи про кривые для ETTR и прочего -- хорошо, но они не дают цельной картины и, в результате, в голове образовалась некоторая каша :)

lexa - 28/Окт/2008 17:08

ну а что - воркфлоу? обработка - сортировка и так несколько раз, на каждой стадии количество уменьшается

Lev Serebryakov (not verified) - 28/Окт/2008 17:24

Блин. Какая обработка? Вот что и как ты делаешь для картинки, которая доходит до конца? Ясно, что к какждой картинке так или иначе свой подход -- но есть же общие принципы, нет?

У меня вот сложился подход (после того, как я осознал что из Юго-Восточной азии что бы удовлетворить всю группу с разными интересами мне надо сделать порядка 500 картинок) явно противоречащий твоему опыту -- всё в ACR, кроме самых сложных случаев + шарп/ресайз/шарп в фотошопе.

Но вот ты пользуешься явно другими техниками -- и дело даже не только в ACR, но и во всех вот этих кривых которые выкладываются в статьях на libraw.su, etc...

lexa - 28/Окт/2008 17:47

Ну смотри, у меня из 1000 картинок с отпуска получается десяток отпечатков и сотня-полторы для показа с экрана.

Показ с экрана - unsharp-resize-unsharp и все (вся обработка в RPP).

Ну а печать - это может быть и склейка нескольких кадров (не HDR), и десяток корректирующих слоев с маской.

А все workflow - это как с одной стороны не перетрудиться, а с другой - не сравнивать сырые картинки из серии/сессии, ибо сырые непоказательны.

Lev Serebryakov (not verified) - 28/Окт/2008 18:13

Да, речь про экарн, конечно.

"Вся обработка в RPP" -- т.е. даже PhotoKit Sharpener в такой ситцации не применяешь?

lexa - 28/Окт/2008 18:23

Я написал "unsharp - resize". Вот unsharp - это и есть PK Sharpener

Но экранные меня мало интересуют на самом деле, их задача именно помочь селекции печатных.

Lev Serebryakov (not verified) - 28/Окт/2008 18:45

А, т.е. тоже самое фактически, что у меня только RPP а не ACR.

Lev Serebryakov (not verified) - 28/Окт/2008 17:26

Кстати, а есть ли причины закрывать код RPP и вообще делать его Mac-only? ну, второе ясно -- у автора Mac, GUI в другом месте ему делать не хочется, понимаю. А выложить движок в OpenSource? Уж раз оно всё равно бесплатное? GPLv2, etc? уж GUI-то нарисуем...

lexa - 28/Окт/2008 17:48

Это надо у автора спрашивать.

Но "он так хочет" - достаточная причина.

Lev Serebryakov (not verified) - 28/Окт/2008 18:06

Но очень обидная.
потому как MacOS X у меня в VMWare так и не завелась -- виснет на установке...

lexa - 28/Окт/2008 18:14

Я давал ссылку на готовую вмварную машину (на mininova)

Lev Serebryakov (not verified) - 28/Окт/2008 18:47

Хм. пропустил, пойду поищу. Но всё равно это кривизна.
А у готовй машины с torrents.ru нет сети :) Т.е. смысла нет :)

lexa - 28/Окт/2008 18:52

не, там с сетью бага, а не фича. Оно периодически отваливается, нужно пойти в System Preferences - Network, удалить адаптер, добавить адаптер, нажать Apply (это для pcwiz-овской 10.5.2 машины так). Там где-то в драйвере таймаут, который на реальном железе не возникает.

Lev Serebryakov (not verified) - 29/Окт/2008 10:35

У меня там вообще нет адаптера и добавлять даёт только VPN, PPPoE и 4 to 6.
pcwiz, 10.5.2, да...

Lev Serebryakov (not verified) - 29/Окт/2008 11:14

А, там вообще в VM с какого-то бодуна адптера не было. О! Оно научилось PRO/1000! Круто.
Вот только, блин, что же оно ТАК торозит.... Работать абсолютно нереально...

Iliah Borg (not verified) - 29/Окт/2008 15:12

Вопрос рисования GUI и наличие исходников движка - вещи столь тесно связанные, или есть способы их развязки? ;)

Lev Serebryakov (not verified) - 29/Окт/2008 15:55

Эмм... Не понял вопроса, особенно с подмигивающим смайликом.

Без исходников дивжка GUI рисовать не к чему.

Или вы про то, что там дивжок и GUI плотно переплетены? Это обидно :( Потому что вообще-то, не видно к тому причин.

Или вы предлагаете дать мне H-файл движка и скомпилированную библиотеку для винды? Да, это, пожалуй, самая вероятная трактовка :)

Но всё же поясните, пожалуйста, свою мысль.

Iliah Borg (not verified) - 29/Окт/2008 16:26

Лев, на самом деле рисование GUI для raw-конвертора - задача совершенно отдельная и страшно сложная. Сцилла и Харибда - понимание процесса конвертации и понимание уровня и ожиданий целевой группы пользователей. Я допускаю, что многие имеют основание считать, что знают вторую сторону вопроса (хотя и с этим не всё так уж хорошо в местах пересечения первого со вторым; Дан, например, на днях пишет мне: "many additions I would like to see, particularly channel curves and some form of channel mixing capabilities" - но зная, как приличные конветроры внутри устроены, остаётся лишь ответить, что каналов, как таковых, там нет - можно лишь к исходным данным, в крайнем случае после экспокоррекции и баланса белого такие кривые прменять, причём по 4 каналам, а не по трём, да и не вполне RGGB эти каналы; а баланс белого - и есть channel mixer); но вот с первой - точно большие проблемы. Различные GUI на базе dcraw - тому пример. Я готов подарить исходники движка RML тому, кто сможет написать к ним верный GUI. Имел же я в виду то, что любой движок в значительной мере устроен как SDK - и, да, действительно, можно его оформить в виде .h, скомпилированного кода и рекомендованной последовательности вызовов.

Lev Serebryakov (not verified) - 29/Окт/2008 16:36

Я ни в коей мере не являюсь ни GUI Guru ни RAW Processing Guru. Всё, что лично я могу сделать -- повторить ваш интерфейс из MacOS X (неидеальный, это очевидно, но вполне работающий) для Windows, не более того :)
Тупо перерисовать те же контролы на .NET 2. Или даже, кстати, на Java, что будет достаточно переносимо.

lexa - 29/Окт/2008 17:20

Лев, тут путаница. У RPP есть автор, это не я и не Илья

Lev Serebryakov (not verified) - 29/Окт/2008 18:47

Хм. Я думал, что Илья. Действительно путаница. Что не ты -- я знал.

Lev Serebryakov (not verified) - 29/Окт/2008 18:50

А автор чего -- Илья? Ему же вон пишут про конвертеры :)

Iliah Borg (not verified) - 29/Окт/2008 19:17

Двух дочерей и сына, в соавторстве :)

Также соавтор RML. Андрей Твердохлеб - автор RPP. О роли Алексея и моей он пишет сам здесь - http://www.raw-photo-processor.com/RPP/Overview.html

Lev Serebryakov (not verified) - 29/Окт/2008 19:31

RML -- ? http://www.rml.co.za/ ? :)

Iliah Borg (not verified) - 29/Окт/2008 20:05

RML - это RawMagick Lite :)

Lev Serebryakov (not verified) - 29/Окт/2008 20:27

Хм. А почему Lite, если нет Full?
Это уже чистое любопытство :)

И, да, как же DNG? Скачал триал и даже не попробовать -- PEF Вы умеете, но я снимаю на Pentax K10D в DNG. А у его брата-близнеца от Samsung PEF'а вовсе нет, только DNG :)

Iliah Borg (not verified) - 29/Окт/2008 20:47

Я лично не собираюсь DnG поддерживать, людей в соблазн вводить. Смысл raw-файла именно в том, что его никакой посторонний конвертор по дороге руками не трогал.

lexa - 29/Окт/2008 22:11

Илья, проблема в том, что есть камеры у которых DNG - единственный формат raw-данных.

Не получится не поддерживать.....

Lev Serebryakov (not verified) - 29/Окт/2008 23:41

А никто и не трогал. У меня камера в DNG прямо на карту пишет. Да, у меня есть выбор -- переключится на PEF. А у тех, кто купил Samsung GX-10 и -20 -- выбора нет. Это перемаркимрованный Pentax, с оторванным PEF -- там ТОЛЬКО DNG.
И это уже не единственная модель с DNG.

Lev Serebryakov (not verified) - 29/Окт/2008 23:51

Ну и потом DNG Converter банально перетасовывает один TIFF-подобный формат (а он у всех практически камер) в другой, без влезания в битовые данные... Так что ничего страшного. Почти :)

А у меня вот 107 гигабайт DNG лежит. $35 сумма небольшая, если RML действительно так лучще ACR хотя бы в деталях и к тому же будет корректно давить бандинг в тенях, который у моего K10D присуствует в полном объёме -- можно и заплатить без прблем. Только смысла нет -- не открывает он DNG

Iliah Borg (not verified) - 30/Окт/2008 00:03

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

Lev Serebryakov (not verified) - 30/Окт/2008 00:09

Ну, в моём случае никакие конвертеры в данные не вмешивались. Не поддерживать DNG из конвертера -- я понять могу. Но не поддерживать родной DNG, когда поддержан родной PEF -- это мне непонятно. Это примерно как поддерживать тольок не-сжатый NEF...

Iliah Borg (not verified) - 30/Окт/2008 00:49

IMHO полноценный DnG родным не бывает, а укороченный DnG - просто оксюморон. На самом деле компании, которые вставляют DnG в камеру в качестве единственного выходного формата, с моей точки зрения сильно неправы и я лично им в этом заблуждении потворствовать не хочу.

Lev Serebryakov (not verified) - 30/Окт/2008 09:49

Что понимается под укороченным DNG?

Ты, пожалуй, единственный такой. Все, озверев от выкрутасов собственных форматов, DNG только приветствуют.

Lev Serebryakov (not verified) - 30/Окт/2008 10:33

Кстати, могу прислать DNG и PEF Сделанные с разницой в 30 секунд, а ты посмотришь, действительно ли чего-то не хватает в DNG, что есть в PEF. Было бы интересно...

Lev Serebryakov (not verified) - 29/Окт/2008 20:37

Смог открыть DNG через "File|Open" выбрав принуждительно маску *.*. Он открыл, правда показал всё, не образел края с мусором и явно перешёл в какое-то некорректное состояние -- даже на закрытие окна не реагировал :)

polyestr (not verified) - 29/Окт/2008 17:06

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

Насколько я понимаю сложность: сначала надо _правильно_ показать результат на мониторе, т.е. преобразовать RGGB->профиль камеры*ББ->дебайер->профиль монитора. Что уже не просто на этапе профиля камеры. Применение кривых желательно делать прямо к RGGB, насколько я понимаю. Что, как мне кажется, может давать странный результат на мониторе? Илья, может быть будет статья на тему что и как должен делать "правильный GUI"?

Я, кстати, так и не дождался статьи по поводу правильного workflow в ACR.

Anonymous (not verified) - 29/Окт/2008 17:22

> преобразовать RGGB->профиль камеры*ББ->дебайер->профиль монитора

Какой профиль камеры Вы имеете в виду? Очень схематически, в первую очередь применяется вычитание (не в прямом, арифметическом, смысле этого слова) чёрной рамки из собственно данных об изображении. Затем производится мэппинг дефектов сенсора. Следом данные линеаризуются (включая вычитание порога чёрного). Настаёт очередь четырёхканального баланса белого, экспокоррекции, тональной коррекции, цветопреобразования (здесь можно говорить о профиле, но лучше - не о том именно, который специфицирован ICC, И. конечно, не с помощью стандартных CMM; да и ведётся это преобразование в пространство, используемое при демозаике, то есть вовсе не в RGB), и, наконец, собственно демозаики.

polyestr (not verified) - 29/Окт/2008 18:22

> Какой профиль камеры Вы имеете в виду?

Не, про чёрную рамку и точку чёрного в своей "схеме" я даже не заикался. Это по идее делается сразу после чтения файла. "Профиль камеры" я имел в виду понятие о том, что же за цвета именно с сенсора прочитаны. Т.е. что в красном канале есть отклик из синего, что G1 и G2 могут отличаться по спектру. Т.е. цвета с сенсора уже изначально смешаны.

Я правильно понимаю, что чёрную рамку можно использовать для интерполяции шума/бэндинга и довольно качественно это вычесть (вейвлеты?)?

Lev Serebryakov (not verified) - 29/Окт/2008 19:16

да и ведётся это преобразование в пространство, используемое при демозаике, то есть вовсе не в RGB
А в какое? Хочу, хочу большую и толстую статью!

Iliah Borg (not verified) - 29/Окт/2008 17:25

Виноват, предыдущий комментарий - мой.

Lev Serebryakov (not verified) - 29/Окт/2008 16:00

Ну, и мне кажется, что без windows-программиста и движок не соберётся так просто -- у вас же там multithread как минимум используется.

Iliah Borg (not verified) - 29/Окт/2008 14:49

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

Iliah Borg (not verified) - 29/Окт/2008 18:37

Профили ICC и аналогичные им не будут работать с поканальной информацией даже минимально удовлетворительным образом. Вы можете легко проверить это, открыв дамп данных raw в Photoshop'е и поприсваивать там профили. Вообще большая част операций конвертации легко эмулируется в Photoshop'е и это очень полезно для верификации операций. Можно и Matlab'ом пользоваться.

Цвета сенсора не то, чтобы просто смешаны - они, как замечательно выразились ребята с Sekonic'а, основаны на human visual response, то есть на красной селёдке.

> Я правильно понимаю, что чёрную рамку можно использовать для интерполяции шума/бэндинга и довольно качественно это вычесть (вейвлеты?)?

Да, и не только wavelets. При этом существенно понимать организацию этой чёрной рамки, так как она зачастую включает и интегральную, и построчную информацию о шуме.

polyestr (not verified) - 29/Окт/2008 22:13

Про профили ICC я даже не заикался, я догадвался, что их применяют только к полноцветным изображениям. Я говорил про профиль камеры и ни слова про ICC.

> Цвета сенсора не то, чтобы просто смешаны - они, как замечательно выразились ребята с Sekonic'а, основаны на human visual response, то есть на красной селёдке.

Чувствую себя очень необразованным :) Цвета-то в итоге поддаются обратной операции? Я именно это подразумевал под "профилем камеры", что с его помощью можно выделить именно первичные цвета.

> Да, и не только wavelets.

Но это всё есть в RML?

polyestr (not verified) - 29/Окт/2008 22:18

> что с его помощью можно выделить именно первичные цвета.

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

Iliah Borg (not verified) - 29/Окт/2008 23:28

Любой профиль в этом месте - до получения полноцветного изображения - а. недостаточен, потом приходится всё равно преобразовывать ещё раз; б. приводит к расщеплению каналов и существенно увеличивает объём данных; в. в силу коммутативности операций - не обязателен.

Цвета, разумеется, полноценно обратной операции не поддаются - камера теряет информацию о спектре сигнала.

В RML есть почти всё перечисленное, но реализованное примерно в том объёме, в котором я это знал 5 лет назад. Кроме собственно демозаики и работы с чёрной рамкой RPP сильно лучше. Над чёрной рамкой Андрей думает, насколько мне известно.

polyestr (not verified) - 30/Окт/2008 02:01

> Кроме собственно демозаики и работы с чёрной рамкой RPP сильно лучше. Над чёрной рамкой Андрей думает, насколько мне известно.

Всё замечательно, но мака у меня нет и не будет. Андрей, видимо, тоже "не потворствует пользователям других ОС".

Iliah Borg (not verified) - 30/Окт/2008 04:03

> Андрей, видимо, тоже "не потворствует пользователям других ОС".

О резонах Андрея судить не могу, тем более с употреблением столь определённых терминов, как "видимо", и к тому же в "утвердительном наклонении".

Конверторы же под любые операционные системы есть в изобилии и будут появляться всё новые. Вот, например, под Windows http://www.my-spot.com/RHC

Lev Serebryakov (not verified) - 30/Окт/2008 09:53

Понимаешь, какая штука -- только Андрей и ты с Алексом пишете вещи про конверсию, которые выглядят здравыми, а не маркетинговым буллшитом. И указываете на ошибки у других. Поэтому хочется попробовать пользоватся результатами этой теории. Так-то конвертеров уже как грязи -- но какой смысл переходить с удобного ACR'а на что-то ещё, если про это что-то ещё вообще неизвестно -- понимали люди, что делали, когда его писали или так, dсraw в очередной раз завернули в GUI. Всего в жизни не перепробуешь, поэтому хочется сразу пробовать то, под чем видна разумная научная основа.

polyestr (not verified) - 31/Окт/2008 01:51

> Всё замечательно, но мака у меня нет и не будет.

Попробовал, наконец, RPP. Per Pixel Sharpness заметно лучше лайтрумовской, но готовый продукт получить в RPP трудно. Сравнивал на дневной картинке, iso 100, лайтрум умудряется детали в кашицу таки размешивать. Или это настолько интеллектуалный шарпен? Интересно, если всё бездумно в tiff из RPP гнать, это будет потом удобно? В смысле tiff потом пачкой обработать в PS.

Андрей (not verified) - 31/Окт/2008 03:03

Ничего там трудного нет - надо просто прочитать доку разок и вникнуть в процесс. Дальше все будет просто. Если чего неясно - пишите письма. Я всем отвечаю.

polyestr (not verified) - 31/Окт/2008 14:45

Я честно сознаюсь, документацию не читал, мне интересно было попробовать результат конвертации, действительно ли стоит заморачиваться изменением workflow. Про "готовый продукт" я имел в виду, что в LR можно наложить градиентный фильтр, выровнять горизонт и т.п. Я попробовал только на двух картинках, на одной сразу получил хороший результат, на другой он слишком был похож на то "как в реальности", а хотелось "что б красиво" :)

Может я конечно из-за непрочитанной документации чего-то не понял, но есть несколько очевидно неудобных моментов. Почему-то при изменении некоторых параметров не перерисовывается картинка, приходится давить на ручки, от которых она перерисовывается. Нет подстройки под разрешение экрана, мне неудобно работать на 1280, нет зума 1:1 для оценки детальности/шарпа.

Когда в след раз запущу макось, я посмотрю, конечно, документацию и прочитаю есть ли там пакетный режим, но мне кажется, что нет, я прав?

Меня не пугает плавающая точка, в конце концов, Core2 Duo E8500 не самый тормозной проц, да и разогнать можно. RPP умеет использовать несколько ядер?

Iliah Borg (not verified) - 31/Окт/2008 03:04

Вы посмотрели ту маленькую инструкцию, что приложена к дистрибутиву RPP и примеры на сайте Андрея? Это может несколько помочь получать готовый продукт и заодно объяснит, почему получение готового продукта, по нашему мнению, не задача raw-конвертора, а задача постпроцессинга. Однако, учитывая, что операции в RPP делаются в плавающей точке, получить из него полуфабрикат, требующий минимально возможной доводки в Photoshop'е стоит затраченных усилий. Для доводки в Photoshop'е из RPP лучше экспортировать файлы в Lab или RGB 32-bit. Sharpen улучшенная демозаика в RPP дают преимущество перед LR/ACR, однако с точки зрения проработки деталей и микроконтраста роль играет и использование плавающей точки.

Pasch (not verified) - 30/Окт/2008 15:38

Увы, серебряной пули не придумали, это факт.
Но все-таки s/h часто помогает.

Андрей (not verified) - 31/Окт/2008 18:51

RPP и непредназначена чтоб давать готовый продукт - в простых случаях это конечно возможно, но в общем случае это просто этап проявки. Доводка до конечного продукта в зависимости от целевого носителя картинки это уже дело фотошопа. Т.е. по минимуму надо стараться вывести баланс, экспозицию, яркость и контраст поскольку они задают тоновую кривую и влияют на демозаику. Так же надо соптимизировать насыщенность под профиль будущего носителя если он известен.
Добивать до "красиво" тоже можно разумеется.
Что до зума, то это опция "zoom to fit" но RPP всегда показывает имидж в половинном разрешении (как half интерполяция). Это компромис для скорости, но в общем никаких проблем это создавать не должно. Sharpness будет адаптирован под разрешение после интерполяции чтоб давать похожий результат. Его как и local contrast можно вообще обнулять и доводить в ФШ если нужна более тонкая работа.
Кнопка Apply это как бы суть процесса - автообновления у нас нет как такового, хотя я над этим вопросом работаю.
Пакетный режим есть разумеется и таже дока с примерчиками есть на сайте.
Она умеет использовать все доступные ядра, но в базовом варианте лимитирует до 2-х - для всех ядер и других вспомогательных фич надо делать пожертвование произвольного размера через paypal, хотя я конечно понимаю постсоветскую специфику и если с этим есть проблемы, то пишите письма. Эти фичи влияют только на скорость для некоторых компов и удобство работы - качество обработки будет идентичным.

polyestr (not verified) - 31/Окт/2008 19:20

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

Нет никаких проблем, paypal есть, пожетвовать не жалко. Проблема в MacOSX ONLY. Native у меня Linux, но Windows в окошке VMWare устраивает тоже, поддержка OSX в vmware заметно слабее, с экранными разрешениями просто беда. Про дефолтную half для зума я догадался, я говорил именно про 1:1 и что нет её. Если я правильно понял идею, то Вы не считаете, что это необходимо.

Если удачно сложатся знаки на небе, то я в воскресенье чего-нибудь пофотографирую и попробую через пакетную обработку RPP пропустить, более предметно сравню с LR. Заодно затраты на изменение workflow попробую оценить.

lexa - 31/Окт/2008 19:31

Экранные разрешения легко настраиваются. Я давал там ссылку, мне нетрудно повторить:
http://pcwizcomputer.com/index.php?option=com_content&task=view&id=31&It...

Максимум, который мне удалось поставить - в районе 1800x1300. Маловато, конечно :), но жить можно.

Что же касается RPP - у меня привыкание заняло несколько месяцев, но результат того стоит (есть некоторые проблемы, автору я про большинство вроде рассказывал, но для всего сложнее "копии документа" я использую RPP).

polyestr (not verified) - 31/Окт/2008 21:06

1280x1024 я выставил по этому рецепту. Я так понимаю, что есть какой-то стандартный набор возможных разрешений у OSX, и если не попал, то работать не будет. Ну и не помешало бы нормальные vmware tools для OSX, чтобы мышка и экран нормально работали.

lexa - 31/Окт/2008 21:21

Может и есть стандартный набор, я не знаю. Я сначала через командную строку загрузчика попытался поставить 2300x1500, его обрезало до 1856x1372, что меня устроило.

polyestr (not verified) - 01/Ноя/2008 01:09

Всё, разобрался. Это vmware почему-то в настройках машины поставила 1280x1024, вот и не получалось больше. Сейчас сижу 1920x1200, пробую RPP. По скорости, кстати, не тормознее LR, мне кажется.

Андрей (not verified) - 31/Окт/2008 21:12

Т.е. LR тоже запускается в виртуале? Вмварь это темный лес для меня - непонятно как там с корректностью цветов все будет и насколько я знаю больше двух процессоров в руки она не дает. Зато линукс и винда в виртуале под макосом работают отлично! :)

lexa - 31/Окт/2008 21:41

Я честно спрофилировал прямо в окошке, никаких проблем.

polyestr (not verified) - 01/Ноя/2008 02:07

> RPP всегда показывает имидж в половинном разрешении (как half интерполяция).

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

Ещё хочется Fill light. Я подсвечивал тени вспышкой, но местами не хватило всё-таки света. Если подобрать exposure чтобы тени (лица) нормальные были, то света выбиваются сильно.

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

polyestr (not verified) - 01/Ноя/2008 02:19

Если интересно, то могу продолжить про пожелания.

Batch mode хочется более человеческий. Чтобы помимо возможности применения Default/Directory Default, можно было пройтись по картинкам и посмотреть что именно получается, чтобы проще было подобрать индивидуальные параметры коррекции. Т.е. как я вижу это сейчас: делается Directory Default на основе Default, генерируется через half результат, внешним просмотрщиком выделяются недостатки по каждой картинке, которые затем поодиночке открываются в RPP для коррекции. Может у меня руки не оттуда растут, но мне такое неудобно, мне удобнее, когда RPP даёт выбрать картинку для коррекции не только через диалог open/драг-н-дроп, вариант интерфейса как в ACR мне кажется заметно удобнее. Из-за отсутсвия режима 1:1 внешний просмотрщик просто необходим получается.

Андрей (not verified) - 01/Ноя/2008 02:58

Доку всеж надо было прочитать.
Засветы - это опция show clipping.
Exposure - это чистая экспокоррекция, если использовать compressed exposure вместо нее то можно света компрессировать вместо выбивания. Плавность регулируется числом в маленьком поле.
Можно тоже самое делать чере brightness и компенсировать contrast.
Диалог Open в макосе достаточен для выбора - там есть и режим с маленьким превью. Можно также ходить по файлам кнопкой next когда оно просто автоматом переходит на следующий файл в каталоге, но эта и другие фичи доступны только через unlock code (то что серое в менюшках).
Про сценарии использования батча в доке тоже написано.

Iliah Borg (not verified) - 01/Ноя/2008 03:01

> Если подобрать exposure чтобы тени (лица) нормальные были, то света выбиваются сильно.

Вместо движка exposure воспользуйтесь compressed exposure - проблема должна исчезнуть. Первое число в compresserd exposure должно превышать второе хотя бы на полстопа. В RPP очень хорошая гистограмма, она в стопах градуирована и показывает, гле пикер. Таким образом выставление экспозиции, яркости и контраста становятся достаточно простыми задачами.

lexa - 01/Ноя/2008 10:36

Граждане отдыхающие,

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

Переходите вот сюда: http://www.libraw.su/node/137 это я на libraw.su завел спец-топик. Анонимно писать можно (с капчей), зарегистрированным чуть больше пряников.
Там, в числе прочего, есть E-mail уведомления о новых комментариях.

polyestr (not verified) - 01/Ноя/2008 14:10

Ок, переехал туда.