Свежие комментарии
| Title | Comment |
|---|---|
| В FastRawViewer реализована |
В FastRawViewer реализована собственная "Selection model" (это так называется) в которой Все это описано (сюрприз) в документации: https://www.fastrawviewer.ru/usermanual14/multiple-files Для желающих иметь точно "виндовый" (/маковский) вариант, нужно в Preferences - Grid/Filmstrip снять галочку с []Advanced selection mode.... и получить "стандартную модель выделения". Shift-Click в ней тоже работает стандартно, настройка ShiftClickSelectionMode игнорируется. |
| уточнение небольшое. такое |
уточнение небольшое. такое встречается тогда когда меняем фолдер и не один файл еще не выбран (галочка в пву не стоит нигде) как только выбираем один файл, кликая на галку, далее все пляшет уже от него. что в целом кмк тоже неверно. типа я "галкнул" файл в середине моей задуманной выборки, далее выбираю первый файл выборки и последний, а активируется с первого по "галкнутому". и наоборотот в конец. если я плохо объяснил, могу "кино" заснять :) |
| решил рапортануть о баге (или |
решил рапортануть о баге (или фиче) на которую натыкался и раньше. |
| Пока мы пополняем on demand и |
Пока мы пополняем on demand и при отсутствии - просто работаем без кэша, вроде все ок. |
| главное чтобы в "каталоги |
главное чтобы в "каталоги лайтрума" не превратилось. хотя я смотрел их базу вроде там норм было, и индексы правильные имелись. |
| То есть да, чешутся руки |
То есть да, чешутся руки покэшировать еще и EXIF (и xmp-блоки встроенные в файлы, если такие есть), так станет еще быстрее (и будут и другие плюсы). Но это - в следующей итерации. |
| Оно и на NAS, подключенном по |
Оно и на NAS, подключенном по 10G, 7 дисков, SSD-кэш на NAS - тоже заметно. Особенно при заходе в те папки архива, куда годами не заходили и в SSD-кэше, соответственно, пусто. |
| Удобство использования |
Должен сказать, что на относительно медленной машине с единичным HDD пользоваться FRV с кэшированием превьюшек стало заметно комфортнее. Раньше при открытии папки с несколькими сотнями RAW приходилось ждать несколько десятков секунд, так как превьюшки скакали по сетке. Что было не критично, но не очень приятно. Сейчас же работать с ранее открывавшейся папкой можно практически сразу, а размер базы превьюшек растёт у меня крайне гуманно. |
| При настройках по умолчанию ( |
При настройках по умолчанию ("класть в кэш только если декодировалось дольше 500мс") можно ничего и не отключать - если у вас все нормально, кэш будет пуст (а однократно на каждую превьюшку сходить в пустую базу - практически бесплатно) |
| Она конечно есть и конечно мы |
Она конечно есть и конечно мы ее не публикуем. |
| -> До версии 1.5 не было |
-> До версии 1.5 не было никакого кэша - и тоже ничего так жили. А есть какая-нибудь, хоть ориентировачная "Дорожная карта" по развитию FRV? |
| Ну а давать десяток ручек |
Ну а давать десяток ручек пользователям при том что Понятно что MRU-стратегия не(всегда)оптимальна. Но я предпочитаю дождаться реального use case когда она плоха (кроме очевидного - однократный просмотр файлов и более никогда не возвращаемся, но для этого случая ручка то есть) и добавлять ручки (или просто менять алгоритм, без ручек, что более вероятно) только тогда, а не исходя из абстрактных рассуждений что "хочется другого". До версии 1.5 не было никакого кэша - и тоже ничего так жили. |
| Что-то тут неправильно. |
Что-то тут неправильно. |
| Они со временем выпадут из |
Они со временем выпадут из базы сами т.к. выпадают по времени "последнего использования" |
| --- > Ручная уже есть: menu - |
--- > Ручная уже есть: menu - file - reload - clear thumbnail cache. |
| И это тоже да. |
И это тоже да. |
| > Планируется ли возможность |
> Планируется ли возможность управления этими 5 минутами, типа зачем постоянно дёргать, если ничего не добавлялось. > Планируется ли уборка "Мусора"? Про автоматическую: если на диске мало места, то файлик с превьюшками должен бы постепенно уменьшаться. В остальных случаях он просто не растет. |
| 1. ->"Автоматическая |
1. ->"Автоматическая очистка просыпается раз в 5 минут" |
| я так полагаю время на |
я так полагаю время на открытие, сик и чтение 2-х кусков тоже уйдет достаточно, вместо чтения метаданных файла без открытия. |
| Там как я понял, если это |
Там как я понял, если это даже "передатчик" (Wifi, Bt, телефон) - если есть нотификация ФСБ, то тоже прокатит. |
| Ну да, радиосинхронизатор, |
Ну да, радиосинхронизатор, конечно. При этом, почта легко сей товар пропустила, никаких таможенных заморочек не произошло, и написал я именно о том, что шопфанс активно пытается помочь в доставке, хотя проблема возникла на пустом месте |
| А это радиосинхронизатор? |
А это радиосинхронизатор? Если да, то действительно же рация? |
| Мои 5 копеек о шопфансе. |
Мои 5 копеек о шопфансе. Попробовал и я вывезти из-за океана синхронизатор бронколор для моноблока. Фитюлина на ебее заявлена в 145 баксов, продавец в Россию не поставляет. Вариантов не было, как везти перевозчиком. (Сняли они свои RFS первой реинкарнации с производства, сейчас годокс для них синхронизаторы лепит). Ну и обратился в шопфанс, создал посылку, заплатил 27 долларов (3,8% берут комиссии за перевод с PayPal). Через 4 дня отлуп от таможенного брокера шопфанса, мол, низзя везти этот синхронизатор. Пишу объяснительную, говорю, что это накамерный синхронизатор для вспышки. Опять "индейский домик" (фигвам). Но, к чести, техподдержка активно пыталась помочь. Быстро сменили мой пользовательский аккаунт на расширенный, зарядили на возможность отправлять не только в пункт выдачи, но и почтой, на любой адрес, переоформили посылку на USPS, и вот, синхронизатор на месте. Спросил, какого хрена их брокер не принимал на отправку. Пояснили, что в названии присутствует слово TRANSMITTER!!! А для них эти буквы обозначают РАЦИЯ, а это запрещено доставкой шопфанса. Вот такие пироги... Почтой доставляли с 7-го по 22-е января, при этом ушла посылка только 16-го со склада шопфанса. Брокер чудил. Не попадитесь при отправке. Сразу покойный Задорнов вспоминается 😃 |
| Этот магический параметр |
Этот магический параметр будет достаточно маленьким и все превьюшки пойдут в базу. 20-Mpix превьюшка распаковывается сейчас на "гипертрединговом" ядре примерно 100ms. Это включая чтение с быстрого носителя. Т.е. даже 4 ядра * HT - 80 превьюшек в секунду. Это - 2-3 секунды на "самые мелкие превьюшки на 4к мониторе, окно на весь экран". Реально такие мелкие на таком большом экране не используют, их скорее будет штук 40 на экране максимум и соответственно (даже) на 4-ядерном CPU экран заполняется за полсекунды. HDD (и тем более NAS по гигабиту) - другая история, там все уперто в диск (и тогда попадет в базу) Толстые TIFF (без встроенного превью небольшого размера)/толстые PNG (там просто нет превью, AFAIK) - это совсем другая история, там могут быть и секунды и десятки секунд. Соответственно, стандартно все настроено так, чтобы RAW в базу не попадали (там и так "достаточно хорошо") и база не пухла. |
| Просто предложение, вы, |
Просто предложение, вы, наверное, уже думали о таком варианте автоматизации. |
| Ну в том смысле что "не будет |
Ну в том смысле что "не будет узнавать". |
| чтобы ориентироваться не только на дату\размер |
Не знаю. |
| А вот какой есть use case, |
А вот какой есть use case, чтобы значит метаданные файла не менялись, а превьюшка вдруг становится другой? |
| Чтобы понимать что файл изменен |
Для идентификации можно дополнительно учитывать хэш первых и последних n килобайт. Или это не поможет? |
| А глобально - нет смысла |
А глобально - нет смысла исключать свитч из проверки, поскольку Т.е. тратить время на вообще всякие абстрактные проверки - не хочу. |
Pages
