FastRawViewer 2.0 (beta1)

Сим начинаем (почти) открытое тестирование FastRawViewer 2. Подробное описание новых возможностией получилось весьма объемным (17 страниц с оглавлением), поэтому тут, в блоге, только краткое предуведомление, а собственно описание/документация - отдельным документом в PDF (см. ниже раздел "ссылки для скачивания")

Кратко: что нового в версии 2

FastRawViewer 2.0 добавляет следующую функциональность (подробнее описанную в детальном анонсе, см ниже):

  1. Многооконный режим с синхронным зумом, focus peaking, показом областей передержки/недодержки и с возможностью копирования параметров рендеринга (обработки) RAW-файлов
  2. Переименование файлов: одного и группы, с (возможным) использованием шаблонов.
  3. Улучшенную производительность, особенно при использовании одновременно и медленных и быстрых носителей данных.

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

Предуведомления

Ограничения бета-версии

На данном этапе бета-тестирования нас интересует отклик от пользователей FastRawViewer v1 (уже знакомых с концепцией программы, ее подходами и так далее).

Поэтому: FastRawViewer 2.0 (beta1) сможет активироваться только если у вас уже установлен FastRawViewer 1.x с лицензионным ключом (т.е. не пробная версия), этот ключ передается на сервер активации. Ручная активация так же отключена, вам необходимо будет обеспечить однократное соединение с интернетом на том компьютере, на котором вы тестируете.

Бета-версия активируется в пробном режиме на 90 дней, за это время мы надеемся закончить тестирование.

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

Унаследованные настройки

Бета-версия устанавливается «поверх» версии 1, это сделано чтобы избежать бардака с ассоциациями файлов, default programs и т.п.  Мы считаем это безопасным: базовая функциональность FRV проверена многолетней эксплуатацией версии 1 и не изменилась; новая архитектура производительности проверена на достаточной аудитории в версии 1.8 TechnicalPreview

Настройки программы, настройки горячих клавиш, списки ‘last used folders’ – общие у двух версий, даунгрейд с версии 2 на версию 1 производится путем деинсталляции новой версии и установки старой.

Измененные (по смыслу) настройки (графический режим и некоторые настройки производительности) – разделены и смена настроек версии 2 не будет влиять на версию 1 (и наоборот).

Поддерживаемое оборудование и операционные системы

Мы отказались от поддержки устаревших операционных систем (и, в случае Windows, старых графических режимов), поэтому требования к оборудованию таковы (подробнее см. ниже раздел Совместимость/системные требования):

  • Mac: macOS 10.12 и новее, процессоры Intel или Apple M1.
  • Windows:   Windows 7 – Windows 10/64 бита, «относительно новая графическая карта» с поддержкой DirectX11

Более подробное описание системных требований - в прилагаемой PDF-ке, в разделе Совместимость/Системные требования.

Ссылки для скачивания

Ссылки быстро устаревают, пользуйтесь поиском по рубрике FastRawViewer и берите из самой свежей публикации

Comments

О здорово! На фейсбуке спросить не могу (коменты для меня забанены наверно), спрошу тут - ББ и подстройки экспозиции можно будет к каждому окну отдельно применять? И можно ди будет показывать один и тот же рав в разных вариантах?

Комменты на FB у меня friends only, иначе невозможно.

Что касается вопроса - я советую все-таки потратить 5 минут времени и прочитать описание многооконности. Оно работает немного не так, как вы себе представляете.

Например: представим что в 4 окнах открыт один файл и мы начинаем там крутить ББ. У FRV, если помните, нет кнопки "save" (или там 'apply') поэтому изменения сохраняются (в XMP) сразу. Поэтому многооконно крутить (один файл) неудобно: или во всех окнах будет ОДИНАКОВО, или у нас в XMP пошло последнее изменение (из какого, б..., окна?)

Исходя из вышесказанного, сделано иначе. Как именно - описано в описании. Если непонятно, пишите, описание подправим (но не реализацию)

Понял - пошел читать.
Насчет комментов - я ж вроде раньше писал и нормально. Или чего то поменялось?

UPD: проштудировал - понравилось, пошел ставить бету.

Теперь осталось дождаться когда же вы с Ильей решите Fast Raw Converter сделать (ну или что то в этом духе ;)

Да, я некоторое время назад (месяц или три, не помню) переключил, потому что набегают странные люди.

Но собственно friend request - дело секундное же?

Переключил у того постинга комментарии на public (не знаю это на все влияет или на конкретный...)

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

Да, если бы для винды был нормальный аналог RPP, это было бы счастье.

Это к Андрею (но шансов, сами понимаете, оно же у него сделано на Native-интерфейсах).

Даже если мы вдруг, внезапно, сделаем RAW-процессор (а для этого надо завершить FRV в точке "дальше только поддержка" - на что шансов в обозримом будущем просто не видно, у пользователей МНОГО хотелок) - он не будет никаким аналогом RPP, у нас же своя голова :)

Под "аналогом" я имел в виду подход к обработке изображения, не крутилочки всякие, а именно подход к цвету-свету.

Другого подхода с цвету и свету ожидать трудно :)
Вот профили - можно на другом принципе делать, если не спешить уложиться с render в сотню миллисекунд. Но это все не сейчас, тут думать и пробовать год минимум, а пока с FRV много работы, да и для RD есть что поделать.

> он не будет никаким аналогом RPP, у нас же своя голова :)

Я к примеру именно этого и ожидал бы - чего-то в духе показанного FRV только с конвертацией и прочими классными плюшками ;)

Я кстати FRV исрользую уже и не по-назначению - как очень быстрый и удобный image viewer (у меня jpeg в основном - поэтому просто). Одно приложение и ничего дополнительного не надо - красота.

Вот чего точно нет в планах - это расширять возможности FRV по управлению рендером, есть Exposure+WB+Contrast и хватит.
Плюс - конвертору нужна совершенно иная демозаика (особенно для X-Trans).

Не-не, увы, но полноценный конвертор - это совсем другой проект, прям совсем.

Не я не о том чтобы FRV расширять - то что туда не вяжется это понятно. Я о том что вот вы с Ильей хотели смотрелку и сделали FRV - ну и в духе того же рав корвертор (быстрый, кроссплатформенный итп)

Немаленькая работа. А FRV не дает на нее отвлечься.

Тут вот еще Apple подогнал айпады на M1 - и невозможно больше говорить, что "платформа слабовата для FRV". А это тоже отдельный проект, клавиатурно-ориентированный FRV впрямую не перенесешь. И спрос есть (особенно если будет работать и на, к примеру, ipad mini текущего поколения - а скорее всего таки будет)

Там (в конверторах) Адоб подогнал еще прям очень хорошую демозаику на ИИ - и надо делать не хуже. А это тоже время и/или ресурсы....

> Там (в конверторах) Адоб подогнал еще прям очень хорошую демозаику на ИИ
Это где? Что-то я не в курсе и вроде на последнем LR/PS сижу (может пропустил чего)

Они вот в принципе как лазилка по хранилищу фоток меня устраивают, оно не быстро и импортировать надо - но как для архива то пойдет. Ну и некоторые вещи - вот вытягивание пересветов к примеру, хорошо сделано. Но DCP эти меня сказочно достали - ББ через зад. Чтобы построить нормально профиль надо занибаться (именно так) с СM.

В более-менее свежих ACR (думаю что и Lr).
Прям хорошо-хорошо, особенно на всяких странных текстурках (ткани, мох) и на высоких ISO.

Владельцы X-Trans хвалят тож, но говорят GPU жрет прям жрет (я на 2080Ti не вижу :)

Гмм, я что-то не заметил. Вот орхидеи снимал в пару дней назад - так с РПП все равно лучше получается и шарпить меньше надо. Поковыряю, может там поменять чего надо в установках

Читал вот про это https://www.diyphotography.net/ai-powered-super-resolution-upscaling-is-now-available-in-adobe-camera-raw/ но там напрямую с проявкой рава не связано, только если upsize делать.

AFAIK, ACR должно работать на GPU для этого

А это наверно Enhance Details - оно новый DNG генерирует с поправками из рава и не применяается как демозаика. У меня GPU вроде есть. Поэкпериментирую вечером

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

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

это же может только быть в случае нового "process" ... а его нет. (последний process v5 с 2018 в ACR 11)

N/A

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

> Память мне подсказывает, что раньше было таки хуже (а не лучше!)

появления process v5 в 2018 ? это возможно конечно - или таки кажестся что на одних и тех же raw демозаика в 2018 была хуже чем в 2021 (при одном и том же процесс v5) ?

N/A

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

N/A

очетяпки не считаются !

N/A

> Да, если бы для винды был нормальный аналог RPP, это было бы счастье.

делать raw converter с UI наверное достаточно гиблое дело - массы захотят же плющек из области пост-процессинга иначе сложно продать массово ... проще пробовать побить Transformer'ы от Iridient ...

а RPP должен работать по идее в OSX в чем-нибудь типа VmWare на PC если что-то кардинально не поменялось - у меня во всяком случае работал лет сколько-то назад когда я его использовал.

N/A

RPP работает в виртуалке, да. Но радости не приносит :)

Вообще совершенно не приносит, особенно когда равы по 80 мп.

все субъективно ~5 лет назад на технике тех лет 42mp вполне терпимо было... все равно ж RPP не в real time рендерит... a больше mp у меня и сейчас нет - хотя если кто-то хочет batch конвертировать 1000 свадебных фото то да - но зачем при этом RPP ?

N/A

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

> писало на винт медленно.

я пользовал RAM диск в этих целях откуда брал PS

N/A

Штука в том, что на приличном железе (ну там 8 ядер интела, на М1 не пробовал) оно рендерит почти в реалтайме таки.

Попробовал, есть ньюансы. Вот скажем выбрал я рав, поподстраивал - ББ и экспозицию, засунул в окно №2, попрбовал другой ББ, в основном окне - засунул в окно №3, поклацал на похожих равах из серии, решил вернуть вариант из окна №2 в основное а оно возвращает но установки берет как последние поменяные (в окне №3). Я понимаю почему так - но все же операция вернуть в основное окно как бы подразумевает восстановление той версии что в это окно засунули? Или не так.

Ну вообще отдельно "вернуть настройки" и "вернуть файл".
Но для того и бета, чтобы понять чего в супе не хватает.

Спросонья непонятно написал.
Да, нужно два действия
1) copy secondary window to main (кнопка <-)
2) copy settings to main (кнопка "ентер наоборот")

Теперь понял - она в тексте как 1 выглядит я и не понял что нажимать. Имхо не совсем интуитивно (потому как когда копируется из основного окна то копируется все, а обратно нет) - но привыкнуть можно вполне.

Вообще мгогооконие это - отличная штука, буду использовать!

Копировать или не копировать настройки (обратно) - это как бы от workflow зависит, смотря что мы делали в этих окнах: выбирали один файл из многих (серии) или подбирали настройки (ББ, экспозицию).

Если желающих "копировать с настройками" будет много - ну решим. Или настройкой в Preferences (как именно копировать, с настройкой или без), или к примеру Shift+click в <- (копировать с настойками) + отдельный шорткат, ну посмотрим.

Подновил PDF-ку, только вот символы-стрелочки, действительно там плохо читалось (я через insert-symbol подбирал слегка похожие, а надо было не лениться и прям уникод вбить). Стало читаться хорошо!

Добавили Shift-Click для "копировать из дополнительного окна/обменяться с дополнительным окном", с шифтом - передаются (вспоминаются) параметры RAW (и сразу пишутся в XMP): https://blog.lexa.ru/2021/05/29/fastrawviewer_20_beta1_2.html

Я, кстати, сделал над собой усилие и полностью пересел на FRV для сортировки и рейтингования. До этого сидел на Бридже (не на LR/LRc!).

И мне всё же ОСТРО (вот прямо ОСТРО) не хватает фичи группировки, как умеет Бридж :-(

В остальном всё отлично, но вот невозможность схлопнуть серию в стопку (и вытащить наверх произвольную картинку этой серии) — вот прямо 5 раз за каждый час работы вспоминаю.

На втором месте — keywords. Очень уж они в Бридже хорошие, деревянные (в смысле, tree а не wood) и мощные.

FRV неизмеримо быстрее, особенно прямо с NAS, лучше видны технические огрехи, всё отлично, но всё же ПОТОМ, когда очевидный мусор удалён а на очевидные «шедевры» расставлены звёзды, приходится идти в тот же Bridge для до-организации... Очень это огорчает.

Группировка - хорошая тема, но плохо вяжется с идеей "мы тут не имеем каталога и подобного...."

Бридж всё хранит в XMP, без каталога. Ну, а в DNG, понятно, прямо внутри (но этого вы делать не будете, это я понимаю, и это как раз не проблема).

Нет, группы хранятся в .bridgesort

Что в сочетании с возможностью FRV просматривать под-папки - ну несколько поперек шерсти.

А, ну да. У бриджа, впрочем, эта фича (под-папки) тоже вполне есть.
(хотя почему бы не хранить в XMP, туда можно добавить свой неймспейс, получится даже сделать кросс-папковые группы, ужас какой).

Потом смешав файлы (но не все!) из нескольких папок - можно получить чудесное.

Да, несомненно, поэтому если бы я имплементил фичу, то ключом группы у меня были бы "папка+UUID". Ибо нефик.
Причём, понятно, папка в XMP не пишется, что бы при внешнем переносе файлов оно не ломалось.

Там безумно сложной логики.

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

Внимание, вопрос: а что происходит, когда мы меняем порядок сортировки и "первый схваченный файл" оказывается из другой группы?

По всей видимости таки FRV:GroupID писать в XMP. Но как узнать тогда, что у нас полная группа?

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

> По всей видимости таки FRV:GroupID писать в XMP. Но как узнать тогда, что у нас полная группа?
Именно. Ну как узнать — XMP'шки мелкие, их можно прочесть все очень быстро в каталоге. Если наложить ограничение, что группа строго в одном каталоге (UUID группы в XMP, но «в памяти» к нему дописывается каталог откуда XMP'шку прочли и так получается полный ключ), то просто понять, что она полная :-)

Вообще, отключение чтения XMP дает у меня процентов 20 к бенчмарке на листание в full-scren режиме.
Типа 34 и 40 fps на файлах Sony A7R-III uncompressed.
Чтение то быстрое - а вот открытие файла в большом каталоге - нихрена не быстрое (ReFS, в каталоге 10к файлов, RAID0 из четырех NVME SSD)

Ну давай честно - 10K файлов в одном каталоге - ситуация нездоровая по любому. 10K файлов по 24, скажем, мегабайта это 240 гигабайт, да? Ну, такие SD'шки есть, но вообще 10K файлов за день - это кадр за 2.8 секунды весь 8-ми часовой рабочий день. Думаю, даже самые адовые свдебщики и предметчики так не снимают :-)

Хотя ReFS, боюсь, вообще не показателен :-) Даже интересна раскладка по FS у ваших пользователей, но, понятно, её не собрать.

И, подозреваю, что не на RAID0 из 3xNMVe будет совсем другой расклад - потому что каталог в любом случае у нас система втягивает в память, и скорость открытия файлов - это структура данных + локи в памяти (в ядре OS), они не будут зависеть от носителя, и останутся такими же быстрыми (ну или медленными, как посмотреть) и на одиночном HDD на 5400rpm. А вот у любого человека с системой хранения попроще чтение станет заметно медленней твоего и на этом фоне открытие файлов станет играть всё меньше и меньше.

Ну не забывай, 10к файлов - это 3к штук RAW, 3k JPEG и 3k XMP

Какой-то пользователь писал нам спасибы, что вот он снял 27 тысяч кадров на авиашоу (за два дня, правда, не за один) и с помощью FRV их за подъемное время разобрал.

Возвращаясь к фиче: штука в том, что мы, когда группируем файлы (RAW+JPEG) мы не читаем метадату, группировка чисто по имени. Ну то есть вот придется читать теперь (и, к примеру, всегда зачитывать все XMP из каталога - что вообще то не обязательно если нет сортировки/фильтрации по метадате).

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

Ну вот два дня - два каталога! :-) Так-то и все 2 терабайта можно в один каталог свалить :-)))

Да, про JPG я не подумал, так как ни разу в жизни их не хранил (ну, для каждого файла) а те, что результат обработки у меня живут рядом с RAW а в отдельных каталогах, так как RAW может быть 500 а обработано - 2, так зачем их там, среди 500, держать?

у меня темп съемки 1000/час вполне себе бывал - спорт, мать его... 6к+ кадров, благо разбирали сами спортивящиеся.

В общем, мысль заронена, пусть думается

Спасибо!

Я не говорю, что задача тривиальная и на 5 минут программирования, но, мне кажется, если делать не идеально а на уровне «чуть лучше Bridge'а» то это вполне подъёмная задача.

Там, я боюсь, месяца на два. И еще перед этим месяца три подумать.

Пипец там конечно логика в бридже.
Если у меня группа свернута и я ставлю ей "три звездочки" - то они ставятся только главному файлу в группе.
А если я группу развернул и поставил "две звездочки" какому-то файлу - они ставятся всем в группе.

Открываются бездны.....

Смотри аккуратней, там бывает выбор файла в группе а бывает - всей группы. Когда ты её развернул она вся заселектилась. Можно заселектить один файл. А можно как-то даже свёрнутую группу.

Но вообще, повторять всё это в точности мне не кажется плодотворной идеей. Я бы, например, хотел, что бы по дефолту был верхним не первый кадр в группе а с маскимумом звёздочек (при равенстве - первый по имени среди равных). А ещё у бриджа группе можно поставить FPS, т.е. это скорее какая-то фича для сборки анимаций а не для HDR/Панорам/Серийной съёмки зверей (это три моих юзкейса, каждый из которых не требует FPS вовсе).

Add new comment