FastRawViewer 1.5 technology preview: кэширование превьюшек

До версии 1.4 включительно, FastRawViewer ничего не писал на диск (кроме XMP-файлов) и это было хорошо, потому что диски не замусоривались. При этом, превьюшки даже самых толстых RAW декодировались достаточно быстро с быстрых носителей и вменяемо быстро - с медленных (вроде одиночных HDD или флеш-карточек)

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

Thumbnail database и ее настройки

В силу вышесказанного, в FRV 1.5 таки было решено сделать кэш превьюшек (сразу для почти всех форматов) и его уже можно попробовать (для RAW).

Управляется он настройками Preferences - Thumbnails cache (см. картинку слева), раздел Disk thumbnail cache.

На картинке показаны значения по-умолчанию, кроме пути до базы:

  • Thumbnail database path - папка с файлом FRVThumbs.db.
    Стандартное расположение:
    • Mac: ~/Library/Application Support/libraw-llc/FastRawViewer
    • Windows: $HOME/AppData/Local/LibRaw LLC/FastRawiewer
  • Database size limit -  предельный размер базы (о котором ниже), умолчания: 4000Mb для 64-битных систем, 2000Mb для 32-битных
  • Stored thumbnail size - какой размер превьюшки писать в базу:
    • Current thumbnail size: максимальный из двух размеров, используемых в Grid/Filmstrip
    • Maximum thumbnail size: максимальный размер, который бывает в FRV (800x800, для ретина-мониторов соответственно 1600x1600 физических пикселей).
  • Thumbnail image compression: вид сжатия (несжатый, JPEG-90%, JPEG-30%).
  • Save cached thumbnail if image thumbnail extraction was longer than - основной магический параметр - в базе с превьюшками будут сохраняться только те превьюшки, на распаковку которых затрачено больше (или равно) времени, чем указано в данном параметре. Соответственно, в базу пойдет только то, что распаковывалось долго, а сама база будет медленнее расти.
    Если вы хотите писать в базу превьюшек все - поставьте этот параметр в 0 миллисекунд.
  • Mark cached thumbnails with red dot - отладочный параметр, если он включен, то к превьюшкам при записи в базе добавляется красная точка в верхнем левом углу (до всех поворотов т.е. угол в "природной ориентации превью". Соответственно, все что взято из кэша (а не расспаковано на лету) будет иметь эту точку.

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

Как идентифицируются файлы

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

Очистка базы данных: ручная и автоматическая

Для ручной очистки базы можно удалить файл (при незапущенном FRV), а можно использовать Menu - File - Reload - Clear thumbnails database. Этот вариант очистки скукожит файл до минимального размера.

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

Автоматическая очистка просыпается раз в 5 минут и проверяет размер файла базы и свободное место на диске. Если база доросла до 85% от лимита, либо до 10% свободного места на диске, то из базы будет удалено 10% записей. Если текущий размер базы больше трети свободного места, либо больше 90% лимита, то после удаления записей, файл базы будет скукожен (если для скукоживания есть достаточно свободного места).

Автоматичеcкая очистка работает "в фоне", программа не блокируется, но на время очистки кэш превьюшек отключается и FRV работает "по старому".

Есть ли в этом толк

Тестировалось, прямо скажем, на ограниченном наборе компьютеров (собственно, публикуем промежуточную версию - для расширенного тестирования), естественно с Save cached thumbnail if image... установленным в 0, чтобы в базу писалось все. Что можно сказать:

  • если ваши RAW уже на быстром SSD, то толк от кэширования есть только если JPEG-превью в файле очень большое. Ну вот 50Mpix у Canon 5Ds. Конечно, распаковка мелкой превьюшки из базы будет быстрее распаковки 50Mpix JPEG и это прямо заметно.
    Для 4-8-12-20Mpix превью я, на быстром компьютере, существенной разницы не вижу.
  • Если ваши RAW на относительно медленном сторадже (в моем случае это быстрый NAS с доступом по 10G), то разница будет и для 10-20Mpix (мы не кэшируем метаданные, только превьюшки, т.е. чтение EXIF/Makernotes в любом случае происходит из самого RAW).
  • Наверное, в случае совсем медленного (для сегодняшнего дня) носителя, вроде единичного HDD, будет разница и для более мелких файлов.

Важно: подразумевается, что база превьюшек лежит на быстром SSD. Класть ее на одиночный HDD - возможно и есть какой-то толк, но вообще - сомнительно.

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

Тестовая версия требует для своей работы активации триала, либо релизного ключа. Если вы пробовали FRV раньше, но не покупали и триал протух, то пишите на support@fastrawviewer.com, выдадим временный ключик.

На этот же адрес нужно писать жалобы на работу новой фичи.

Разное

Понятно, что наличие БД превьюшек открывает всякие другие возможности. Например, при смене параметров рендеринга RAW (экспозиция, ББ) можно записать результат в эту базу и потом показывать оттуда. Это все понятно, но к FRV 1.5.0 делаться не будет (и не просите), крупные изменения в 1.5 - это поддержка TIFF/PNG.

Comments

Для идентификации можно дополнительно учитывать хэш первых и последних n килобайт. Или это не поможет?

А вот какой есть use case, чтобы значит метаданные файла не менялись, а превьюшка вдруг становится другой?

Не знаю.
Я писал к вопросу о "Но если и размер и даты остались прежними - узнать что файл изменен FRV не может."

Ну в том смысле что "не будет узнавать".

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

wbr, Deesy

И это тоже да.

Просто предложение, вы, наверное, уже думали о таком варианте автоматизации.
FRV при запуске читает из базы данных некую стандартную превьюшку максимального размера (ну, там, в зависимости от выбранных настроек Stored size) и замеряет время, необходимое на её показ. Вот это время и выставляется в значение магического параметра.

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

20-Mpix превьюшка распаковывается сейчас на "гипертрединговом" ядре примерно 100ms. Это включая чтение с быстрого носителя. Т.е. даже 4 ядра * HT - 80 превьюшек в секунду. Это - 2-3 секунды на "самые мелкие превьюшки на 4к мониторе, окно на весь экран". Реально такие мелкие на таком большом экране не используют, их скорее будет штук 40 на экране максимум и соответственно (даже) на 4-ядерном CPU экран заполняется за полсекунды. HDD (и тем более NAS по гигабиту) - другая история, там все уперто в диск (и тогда попадет в базу)

Толстые TIFF (без встроенного превью небольшого размера)/толстые PNG (там просто нет превью, AFAIK) - это совсем другая история, там могут быть и секунды и десятки секунд.

Соответственно, стандартно все настроено так, чтобы RAW в базу не попадали (там и так "достаточно хорошо") и база не пухла.

1. ->"Автоматическая очистка просыпается раз в 5 минут"
Планируется ли возможность управления этими 5 минутами, типа зачем постоянно дёргать, если ничего не добавлялось.
2. Планируется ли уборка "Мусора"?

> Планируется ли возможность управления этими 5 минутами, типа зачем постоянно дёргать, если ничего не добавлялось.
Раз в 5 минут проверяется размер, если оно не вырос за норму, то и все. Если файл не менялся, операционка его размер из кэша отдаст т.е. никакой особой нагрузки/дерганья вроде бы нет.

> Планируется ли уборка "Мусора"?
Ручная уже есть: menu - file - reload - clear thumbnail cache.

Про автоматическую: если на диске мало места, то файлик с превьюшками должен бы постепенно уменьшаться. В остальных случаях он просто не растет.

--- > Ручная уже есть: menu - file - reload - clear thumbnail cache.
Или описание неточное, или..
Я имел ввиду удаление "зависших превьюшек", когда основной файл удалён где то-там, или перемещён и создалась новая превьюшка, а старая осталась.....

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

Что-то тут неправильно.
А если база большая, а если диска хватает, а если превьюшки долго невостребованы, но они нормальные, и не хочется чтобы они из базы уходили.
А управление временем "последнего использования", для кого-то оно одно приемлимое, для другого другое.
Я бы вообще на отталкивался от него....

Ну а давать десяток ручек пользователям при том что
1) 99% будут использовать умолчания
2) а половина из оставшихся в них не разберется и задолбает поддержку вопросами
Тоже ж ничего хорошего.

Понятно что MRU-стратегия не(всегда)оптимальна. Но я предпочитаю дождаться реального use case когда она плоха (кроме очевидного - однократный просмотр файлов и более никогда не возвращаемся, но для этого случая ручка то есть) и добавлять ручки (или просто менять алгоритм, без ручек, что более вероятно) только тогда, а не исходя из абстрактных рассуждений что "хочется другого". До версии 1.5 не было никакого кэша - и тоже ничего так жили.

-> До версии 1.5 не было никакого кэша - и тоже ничего так жили.
Кэш Отключить можно будет, ну и ладушки. Бо лично для меня он будет ненужен (пока онли RAW)...

А есть какая-нибудь, хоть ориентировачная "Дорожная карта" по развитию FRV?

Она конечно есть и конечно мы ее не публикуем.

При настройках по умолчанию ("класть в кэш только если декодировалось дольше 500мс") можно ничего и не отключать - если у вас все нормально, кэш будет пуст (а однократно на каждую превьюшку сходить в пустую базу - практически бесплатно)

Должен сказать, что на относительно медленной машине с единичным HDD пользоваться FRV с кэшированием превьюшек стало заметно комфортнее. Раньше при открытии папки с несколькими сотнями RAW приходилось ждать несколько десятков секунд, так как превьюшки скакали по сетке. Что было не критично, но не очень приятно. Сейчас же работать с ранее открывавшейся папкой можно практически сразу, а размер базы превьюшек растёт у меня крайне гуманно.

Оно и на NAS, подключенном по 10G, 7 дисков, SSD-кэш на NAS - тоже заметно. Особенно при заходе в те папки архива, куда годами не заходили и в SSD-кэше, соответственно, пусто.

То есть да, чешутся руки покэшировать еще и EXIF (и xmp-блоки встроенные в файлы, если такие есть), так станет еще быстрее (и будут и другие плюсы). Но это - в следующей итерации.

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

wbr, Deesy

Пока мы пополняем on demand и при отсутствии - просто работаем без кэша, вроде все ок.
Но опасность такая есть, это правда. Тут легко увлечься.

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

wbr, Deesy

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

wbr, Deesy

В FastRawViewer реализована собственная "Selection model" (это так называется) в которой
а) случайный клик (без модификаторов) не сбивает выделение (ради этого и делалось)
б) как следствие, "текущий" файл не обязан быть частью selection
(и отсюда появляется настройка "а что же делать, если текущий файл не в selection, а на нем вызвали контекстное меню")
в) как следствие, Shift-Click выделяет диапазон между "последним файлом на котором был Ctrl-Click/смена позиции галочки" и Shift-Click-нутым, а если такого не было, то от начала списка. (это достаточно близко повторяет поведение виндов, но именно что близко, а не 100%)
г) На самом деле, есть еще скрытая настройка ShiftClickSelectionMode (про нее смотреть тут: https://www.fastrawviewer.ru/usermanual14/program-settings искать поиском, но там опечатка и она названа ShiftClickSelectionModeDefault, ща пойду править), которая позволяет поведением Shift-Click управлять еще более тонко

Все это описано (сюрприз) в документации: https://www.fastrawviewer.ru/usermanual14/multiple-files

Для желающих иметь точно "виндовый" (/маковский) вариант, нужно в Preferences - Grid/Filmstrip снять галочку с []Advanced selection mode.... и получить "стандартную модель выделения". Shift-Click в ней тоже работает стандартно, настройка ShiftClickSelectionMode игнорируется.

Поправка: в документации не ошибка, а название скрипта, который эту настройку ставит в стандартное положение.

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

wbr, Deesy

Ну вот решение "клик в превьюшку без shift/ctrl не сбивает отметку" - повлекло за собой последствия, в количестве больше одного.

Пользоваться стандартным выделением после привычки к своему - мне неудобно :)

я думал выделение файлов через шифт/клик и потом могу галкнуть их уже. выделяю второй диапазон и снова кликаю на чекбоксе одного из файла в текущем выделении - они помечаются согласно: если файл был чекнут - все чеки тушатся для всех файлов в выделении. если файл был анчекнут - то чек ставится на все файлы в выделении.
до кучи можно ввести что-то типа
Ctrl-Shift-A -чекнуть все файлы в текущей папке
Ctrl-Shift-D анчекнуть все файлы

wbr, Deesy

Ну то есть вы предлагаете сразу иметь два понятия
- Checked (в духе FRV)
- Selected (в духе Windows)
Извините, но наш средний пользователь не поймет этого.

Шорткаты такие есть, только без Shift, Menu - Select и там смотрите, они там все написаны.

Алексей, возможно я неправ. но как пользователь который rtfm в самом конце текущий режим чека и селекта для меня был (и немножко остается) не совсем однозначным. :)

wbr, Deesy

вот чесслово сижу принципиально копаюсь в выделении =( как-то неудобно.
я бы (не стоит меня за такое банить) сделал так
Ctrl-A - выделить все файлы не меняя статус (чекбокс в пву)
Ctrl-D - снять выделение всех файлов не меняя статус (чекбокс в пву)
Ctrl-Shift-A - выделить все файлы меняя статус активируя чекбокс в пву (тут и в следующей вопрос про выделение, надо подумать)
Ctrl-Shift-В - выделить все файлы меняя статус деактивируя чекбокс в пву
Shift/Ctrl/Click - выделяет/снимает выделение но не меняет активность файлов
Ctrl-Space - (например) активирует чекбокс в текущем выделении
Ctrl-Shift-Space - (например) деактивирует чекбокс в текущем выделении
Так же можно кликать мышой на чекбокс в выделенных файлах. если текущий активный файл был активирован (чекбокс он) то снимается активация всех файлов в выделении. ну и наоборот. если файл в выделении был неактивный и кликаем по чекбоксу - то активируются все файлы в выделении.

вот как-то так.
про бит 2 пошел читать и попробую. спасибо

wbr, Deesy

поправочка
Ctrl-Shift-В - выделить все файлы меняя статус деактивируя чекбокс в пву
читать как
Ctrl-Shift-D - выделить все файлы меняя статус деактивируя чекбокс в пву

wbr, Deesy

Я одного не могу понять, но сразу глобально.
Вот сейчас есть понятие "выделенная группа файлов", отмечать можно привычными действиями (Shift-Click, Ctrl-Click) и над этой группой мы делаем всякие групповые действия. Это - более-менее привычно (есть особенности - текущий файл может не быть в выделенной группе). Эта выделенная группа отмечается и цветом фона и галочками.

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

Но что дальше то? Вот когда у вас есть файлы 1,3,5 выделенные (фоном) и файлы 2,3,4 отмеченные (галочкой) и вы вызываете контекстное меню на файле 3, то к чему относится это контекстное меню, к 1,3,5 или к 2,3,4?

1. начну с конца =) контекстное меню изначально может работает над:
б) отмеченными галочками, при отсутвии оных - над а) выделенной группой.
предвидя дальнейший вопрос: "а если мне надо над выделенной группой?" можно сделать Shift (aka выделение) + контекстное меню - и оно уже будет работать над выделением. чтобы не путаться - можно первым пунктом в контекстном меню показывать (и переключаться): Checked -> Selected или Selected-> Checked

2. по поводу двух понятий: да, раз уж ввели их в дело checked & selected то я бы и (со)держал мух отдельно от котлет

3. для чего все это? хочу например выделить портреты в папке. но где-то у меня портреты диапазонами а где-то пейзажка. и check будет слетать постоянно. поэтому придется тыкаться-чекать по одному файлу. не?

wbr, Deesy

забаньте меня :)

wbr, Deesy

1. Мы не вводили checked и selected, это одно и то же сейчас.
2. Уже сейчас у файла есть 4 состояния (два независимых признака: отмечен и текущий). Добавьте раздельные checked/selected - и возможных состояний станет 8.
3. Для постоянных выделений, независимых от текущей сессии есть rating и label (что дает 25 сочетаний), вот можно покрасить портреты красной меткой, а пейзажи - зеленой. И эта окраска останется и после закрытия/нового запуска FRV.

ушел в личку.

wbr, Deesy

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

wbr, Deesy

Ну если мы возьмем Windows Explorer, то там Shift-Click всегда выделяет один диапазон, снося старый.

А если мы возьмем FRV с его Selection mode, то:
Бит 2:
0 - Shift-Click всегда делает новое выделение диапазона, полностью снося старое выделение
4 - Shift-Click всегда расширяет выделение, не раз-выделяя старое.

а напомните мне - перенос настроек добытых мозолями на другую машину у FRV автоматизирован или мне надо ручками ветки регистри переносить ?

N/A

"C:\Program Files\LibRaw\FastRawViewer\scripts\BackupSettings.cmd - сделает три .reg-файла в %USERPROFILE%\Documents\FRV-backup
Preferences, Shortcuts, LastUsed
Ну а дальше - перенести на другую машину и дабл-клик на нужных

перенес... и в отличии от исходного пц созданные x-transformer'ом DNG в гриде не показываются (приходится ручками refresh)... разница на первый взгляд - в исходном пц каталог сидел на hdd, теперь на ssd ... куда бежать ? на всякий случай "EnableAllDrivesMonitoring.reg" применил - не помогло

N/A

PS: check for folders updates each - стоит > 0 ... (2 сек)

N/A

debug log послал мылом на "blog--admin@" с subject "https://blog.lexa.ru/comment/50773#comment-50773"

N/A

Ага. Поставьте 0.5

с 0.5 сек работает... это что ? разница между SSD/HDD где-то в коде ?

N/A

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

Можно добавить tunables, но если с 0.5 работает (и с 1.0 наверное будет работать), то зачем?

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

N/A

Ну возможно нужна таки галочка (скрытая?) "do not suppress folder refresh after external program run". Записал в TODO, дело копеечное, а проблему данную действительно решит.

может быть проще попробовать детектировать что внешняя программа делает на темы: продолжает ли она выплевывать много файлов в текущий каталог или нет + находится ли ее окно поверх FRV в режиме грида (типа если нет то пользоватеь таки смотрит на грид и ожидает увидеть) ...

N/A

Думаю, надо фронтальную камеру анализировать. Куда смотрит юзер, есть ли у него счастье на лице....

И не забудьте облачное API... чтобы FRV без коннекта не работал как надо !

N/A

> а после запуска внешней программы - сигналы об изменении в текущей папке игнорируются (утроенное время того параметра).

хочу уточнить - ну вот сейчас FRV запустил внешнюю программу - когда именно он начинает игнрорировать изменения - раз при короткой задержке auto refresh сработал значит не сразу после запуска - как соотносится эта задержка начала игнорирования с частотой проверки фолдера которуя я задал в настройках ?

N/A

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

N/A

Я ж написал там выше: "(утроенное время того параметра)"

чукча не читатель !!!... т.е. у если запущенная из FRV программа создает DNG, TIFF, JPG, PNG в исходном фолдере быстрее чем этот параметер * 3 (было 2 сек * 3 = 6 сек) то FRV не будет показывать (проигнорировав все изменения в содержиром фолдера) новоявленные объекты, а если медленне то будет... хммм... не проще ли тогда задавать 2 независимы времени в настройках явно - время межды последовательными проверками изменения содержимого и время в течении которогo FRV будет игнорировать проверку после запуска программы... я поставлю себе проверять не слишком часто (чтобы успеть чаю хлебнуть из стакана), а игнор поставлю в 0 (т.е. не игрнорировать) и буду счастлив что с SSD что с чем-то медленным где часто проверять не хочется...

N/A

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

N/A

Поллинга как такового нет. На самом деле этот параметр значит две вещи
а) "если событие прилетело быстрее чем - отложить обработку до". Чтобы не наяривало поллингом по диску.
б) 3*time - время игнорирования в случае когда 1) сами создаем XMP 2) запустили внешнюю программу.

Вполне может быть, что игнорировать в случае 2) просто не надо.

Вы уже уговорили, в это место стоит заглянуть.

Add new comment