FastRawViewer 1.4.4-1167 (beta2)

Обновлено 17.09.17

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

В результате фичу "одни и те же кнопки работают и с одним файлом и с несколькими" мы переработали и теперь она работает "как в Лайтруме". Если совсем в двух словах то

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

Подробное описание:

Single file operation shortcuts/menu - могут работать и с несколькими файлами.

В FRV версий 1.3.0 - 1.4.3 операции с файлами (copy, move, rating, label и т.д) производились двумя разными наборами действий

  •  - Menu - File, Menu - Adjust, Menu - XMP Metadata работали с текущим файлом
  •  - Menu - Select/Batch - с набором отмеченных файлов.

Такое поведение было выбрано, чтобы пользователям старой версии не пришлось переучиваться. Вместе с тем, это достаточно необычно и не всем удобно, поэтому начиная с версии 1.4.4 мы (постепенно) эти наборы пунктов меню/горячих клавиш объединим.

 Это заключается в следующем:

  •  Menu - Select/Batch переименовывается в Select, оттуда убираются все действия (copy, move, поворот, итп)
    Групповые действия пропадают и из хелпа (F1) и из назначения шорткатов
  •  в режиме просмотра одного файла (Single view) - старые действия (copy/move/...) работают с текущим открытым файлом
  •  в режиме просмотра плиткой (Grid mode), если "текущий файл" (выделенный яркостью фона, показанный в заголовке окна и на нижней панели)    входит в группу отмеченных файлов, о все действия происходят над группой файлов.

Работа контекстных меню не меняется.

 Индикация группового режима:

  • Menu - File - у каждого действия появляется счетчик (Move 33 files to...)
  • Menu - Adjust, Menu - XMP Data: в меню появляются заголовки Rotate NN selected files/ Rate/Label nn files
  • Панель XMP Metadata
    • заголовок панели меняется на XMP Batch: change nn files
    • кнопки установки рейтинга - меняется иконка (звездочка на снежинку),
    • кнопки установки метки - из залитого окна становятся цветной рамкой
    • поле XMP Title обнуляется, в поле XMP Description выводится сообщение о batch mode
  • Кнопки в нижней строке программы ведут себя аналогично
    • XMP Rating - меняется иконка
    • XMP Label - заливка становится рамкой.

Включить эту новую функциональность можно через Preferences - Other - Single file keys works for multiple files too (в данной версии она уже включена по умолчанию).

08/09/17: В отличие от большинства программ, в FastRawViewer возможна ситуация, когда текущий файл не находится в группе отмеченных  файлов. Работа пунктов меню/горячих кнопок в этом режиме регулируется настройкой
   Preferences - Other - If the current file is not in the group of selected files, single-file shortcuts will work with:

  • 11/09/17 - этот режим снова работает корректно если текущий файл входит в группу выделенных current file - кнопки будут влиять на текущий файл
  • selected group - на выделенные (отмеченные) файлы.
  • 08/09/17: Both - и выделенные и текущий считаются одной большой группой

14/09/2017: дополнения:

  • "снежинки" в панели XMP Metadata и в нижней строке выводятся иконкой, а не шрифтом (не у всех шрифтов, оказывается, есть нужный символ)
  • XMP Rating - Reject возникало в контекстных меню даже если Reject отключен в настройках.
  • В меню и в контекстных меню порядок кнопок рейтингования не соответствовал таковому на панели XMP Panel (на панели было: Reject, clear, 1; в меню Clear, Reject, 1...)
  • Если какой-то шаг "больших перемещений" установлен в 0, то соотв. пункты меню/горячие клавиши запрещаются.
  • Progress bar-ы при смене рейтинга/метки/итп для большого кол-ва файлов выводятся более гибко:
    • Если изменяемых файлов более 99 (было более 5)
    • Либо если 20% работы не сделано за первые 150 миллисекунд

16/09/2017, дополнения:

  • Поддержка Sony RX10-4
  • Кэш метаданных: при записи XMP файла, которого нет в кэше - оно попадает в кэш.
  • XMP Rating undo: в некоторых случаях ставился reject вместо 0

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

Comments

> если выделены несколько файлов и текущий файл в группе выделенных

А хорошо ли это... раз выделил то выделил для операций... не важно какой там текущий уже... хотя если цель совместимость с массовым сознанием = LR и там так оно и есть, то в этом есть смысл

N/A

В Lr если есть выделенные, то текущий - обязательно в них входит. У нас "selection model" другая - и в этом месте пахнет настройкой уже.

См билд 1161 (и выделено красным в тексте) - это место стало регулироваться.

душевно... а вот еще - я не знаю как другие пользователи... но я испорчен UI в других программах где по больше части - текущий файл он же и selected автоматически... никак нельзя заполучить опцию чтобы выбор (обе операции select/de-select) файла в FRV его бы автоматом делал и текущим при этом ? т.е. чтобы текущий файл не болтался где-то там сам по себе хрен знает где (раз уж он у вас не считается selected по умолчанию)...

N/A

Ну "select/unselect' в том смысле что "покрасить его красным и добавить в список выбранных" - это плохая идея т.к. если мы сначала текущим файлом попали на уже selected (с галочкой), а потом перешли на следующий - нам что ли галку снимать? Или завести там некий tri-state (выбран явно, выбран переходом)... ну это сильно усложнит все внутри.

Поэтому то что вы хотите надо делать иначе, добавлением третьей опции к этому выпадающему новому списку вариантов (на кого действуют хоткеи/пункты меню/кнопки на панелях): current+selected (в добавление к имеющимся current, selected).
Это потребует переделок унутре больше чем в 1-2 местах, но количество переделок поддается осмыслению.

Остается единственный вопрос: контекстные меню (на selected файлах), через которые можно сделать все то же самое.
Если мы оставляем их как есть, а именно контекстные меню работают только на selected (но зато и в single view режиме, т.е. на Filmstrip), то я пожалуй поддерживаю всю идею с третьим вариантом в настройках (т.е. я вот контекстные меню вовсе не хочу трогать - они сейчас все еще работают и не сломались и хочу и дальше не менять им логику)

> а потом перешли на следующий - нам что ли галку снимать?

я про операции select/deselect, а не про выбор текущего (на котором "фокус")... например у меня текущий файл "А" где-то далеко там и я сделал ctrl-click мышкой (select/deselect) на другом файле "B" (или попал ему в чекбокс в углу просто кликом) - и текущим сразу стал этот файл "B" ... это никак не отменяет ситуации возможной в FRV что текущим может опять стать другой файл "C" без того чтобы он стал selected (например мы в него просто кликнули мышкой, но не попали в чекбокс или сказали через меню/клавиши "(De)Select and move to next")...

N/A

Ну да, у нас осознанно разнесена отметка (select) и перемещение.

Я там задал другой же вопрос, ну да ладно уже.

Да, Ctrl-Click или чекбокс не делают файл текущим

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

Вот так и оставим.

А 1063 - правит ошибку в первом режиме.

А 1066 наводит еще больше общей красоты (особенно на маках)

В LR удобный инструмент для кропа/выравнивания. Но LR тормозит...
В C1 кроп ужасно неудобный, и раздельный с выравниванием.

А может этот функционал добавить в FRV? Он же независим от камеры и цвета, и пишется в XMP?
На основании того, как выглядит картинка в кропе, можно делать выбор. У меня в LR отбор кадров первым проходом всегда связан с кропом и горизонтом, реже - с цветом или экспозицией. Потому что последнее можно вытянуть, а композицию - уже нет...

Кроп/выравнивание запланированы на версию 1.5

Там не все так просто, как хотелось бы т.к. адобовский "полный кадр" и наш отличаются (наш чуть побольше, поля не оставляем), но для ~700 актуальных камер (из 1000 поддержаных) решим вопрос.

> Кроп/выравнивание запланированы на версию 1.5

т.е. даже не v2 ? а вот тогда вопрос - например режим (опционально) отображения thumbnail's с учетом этого и например ББ выбранного (ну это где-то сидит например в sidecar'ах) ?

N/A

Может и на 2
Как пойдет. То есть теория гласит что сделать просто.

WB - мы пробовали. Распрямить JPEG, поправить WB, загнуть обратно гамму - получается жопа.

Я хотел UniWB-шные жопеги так править в нормальные.

> Я хотел UniWB-шные жопеги так править в нормальные.

было бы хорошо с такой опцией... а thumbnail'ы генерировать постепенно из raw (медленно и кэшировать где-то как bridge например) совсем не кошерно в будущем ?

N/A

Их надо хранить тогда.

И это превращает FRV в бридж

>>> И это превращает FRV в бридж

но на стероидах же ... и почему собственно плохо быть бриджем в этом случае ? зато thumbnail's ближе к ...

N/A

FRV (пока) хорош тем, что делает ровно то, про что его просят (+ небольшой префетч). Что ценно, например, если работать от батарейки.

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

А рендерить в фоне все (да даже и все видимое) - это довольно накладно по ресурсам.

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

вопрос привычки, мне LRовский кроповорот противен и нелогичен, а в C1 он таки сделан в виде единого инструмента где-то в районе 9 версии.

Куда смотреть? В 10-й версии вынесенные на верхнюю строку Crop/Rotate/Keystone - на мой личный взгляд совершенно и невероятно чудовищны..... Но наверное я смотрю не то.

не смотреть - включать crop tool, кропать и пользоваться. кручение в комплекте.

keystone - возможно, но я им редко пользуюсь в силу специфики съемок.

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

Crop tool - это же кнопка C (кручение - R)?
Или я вовсе не туда смотрю?

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

Тогда я не понял в чем прикол.

В ACR (а значит и в лайтруме?) работает - в смысле принципа действия - в точности так же. Покропаное можно покрутить (прямо сразу, ничего не переключая никуда).

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

в разной механике работы оных инструментов, подозреваю.

А, то что крутится картинка и вы видите как оно будет?

Вот это да, возможно.

ну видно и там и там - но грубо говоря в C1 ты двигаешь рамку, а в руме - картинку.

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

В лайтруме crop/rotate как-то приятнее сделан, imho.

Странные какие-то числа (расходится количество фоток с суммарным количеством XMP Rating)
https://1drv.ms/i/s!AribPYni9kAoi0jCGLHAYLNELf20

Что значит "Metadata unread"?

То и значит:
2841 Файл всего
2194 - метаданные (включая XMP) не читали
У тех у кого читали:
569 - нет рейтинга
78 - единичка
2194 + 569 + 78 = 2841, сумма сходится.

А если о сути, то:
- метаданные (включая XMP) не читаются, если они не нужны. Если вы, к примеру, поставите галочку "покажи мне только одну звезду" - тогда прочитает все 2841 файл. Это если при стандартных настройках.

Если нужно прочитать однократно для каталога - кнопка recycle (стрелки по кругу) и там "Forced full metadata read"
Если нужно читать всегда (вам такой ленивый режим не нравится), то Preferences - File Handling - группа "sorting & filtering" - снять галку "Lazy metadata read"
Ну и другой вариант чтобы читало метадату всегда - сортировать по ней (например, по EXIF timestamp)

А если я к этому моменту уже поставил рейтинг для ~200 файлов, это не считается (показывает 78)?

Остальные 130 - в метадате тех файлов, которые не прочитали??

Прочитайте таки все, я написал как

То есть история такая
- если вы поставили 200 файлам рейтинг
-и не уходили в другой каталог (и не закрывали программу)
То оно все помнит.
А если сессия прерывалась - то помнит только то что прочитали
А если уходили в другую папку - то кэш метаданнных могло почистить.

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

Ага, поигрался еще.
Значит там в некоторых случаях при установке рейтинга - оно мимо кэша делается, сразу в XMP.

То есть хотите видеть в этом месте корректные цифры - включите один из режимов который требует метаданных явно
- сортировка по EXIF (рейтингу, метке)
- фильтрация по чему хотите (кроме Selected, понятно)
- или выключить Lazy read

Я тот случай когда мимо кэша - конечно тоже починю к релизу 1.4.4

Вот в 1170 это место улучшено.
Если вы в большой папке (много файлов) сделаете Select All и поставите всем рейтинг, то metadata unread не будет.

Это по делу ни на что не влияет (потому что как только вы реально начинаете метадату использовать для сортировки/фильтрации - она прочитается), но выглядит аккуратнее.

я конечно может в последнее время много отмечал... и могу быть mentally impaired... но, a почему thumbnail который соотв. raw с меньшей экспозицией в FRV визуально более bright чем тот который соотв. raw в большей экспозицией ? может я что-то, где-то не так настроил ? xnviewmp например все показывает культурно ...

N/A

Без примера ничего не могу сказать (кроме того, что не включили ли вы часом автояркость для thumbnails?)

> не включили ли вы часом автояркость для thumbnails?

да !

а каков там алгоритм работы если не секрет - и нет ли места оному быть лучше ? таки странно все же что менее экспонированный raw выглядит более экспонированным... ладно бы ~таким-же по яркости в thumbnail, так ведь выглядит на 1+ более ярким... сцена если что - та же, менее экспонорованный он на ~2.5 стопа менее...

N/A

Он включается не сразу, а только если там есть 1.5 стопа пустоты в светах (в JPEG-иконке, не в raw)

Глобально эта штука для разбора ночных снимков, на которых ничего не видно. Давать туда еще и настройки - я вообще не вижу смысла, нормальное положение этой галочки: "выключено".

> Давать туда еще и настройки

зачем настройки - не проще ли все выравнивать вправо (даже если меньше 1.5 в JPEG) и все ? ну это так, некритично...

N/A

Там одного ETTR недостаточно, если сильный недодер, нужно и гамму менять.

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

Выбор по Shift-Click не работает так, как это привычно во всех других программах.

К примеру, есть десять файлов. FRV только что запущен, никаких действий с файлами ранее не производилось.
Кликаю мышкой на 5-й. Потом Shift-click на 7-й. Ожидается, что выберутся файлы 5, 6 и 7. На самом деле выбираются с 1-го по 7-й.

Усложняем. Ставлю мышкой галочку на 5-м файле (или сочетанием Ctrl-/, или Ctrl-click). Файл выбирается. Потом Shift-click на 7-й - выбираются файлы с 5-го по 7-й. Снимаем все галочки (Ctrl-D). Кликаем мышкой на 7-й, потом Shift-click на 10-й - выбираются файлы с 5-го по 10-й... т.е. от последнего ранее когда-то руками отмеченного, хоть в данный момент на нём нет галочки.

Потому что click и ctrl-click в FRV - это разные действия.

Причина этого проста: в стандартной selection model (Explorer, Finder, да все программы) случайный клик не туда сносит всю выборку. Чудовищно же бесит. Соответственно, или клик в галочку, или Ctrl-Click.

Что касается второго момента, то при стандартных настройках Shift-Click отмечает диапазон от Last-Control-Clicked до Shift-Clicked. Это так и в Explorer (проверил даже в очередной раз в десятке), даже если выделение снималось перед этим через Select none.

Поведение ShiftClick может быть настроено скрытой настройкой ShiftClickSelectionMode (см. мануал, искать по этой строке)

Add new comment