FastRawViewer 1.1 (RC2)

Удивительное дело, но серьезных и воспроизводимых багов нам в FRV 1.1-RC1 не нашли, да и вообще почти никто не пишет.

Поэтому в RC2 изменения минимальны:

  • Обновлено руководство, идущее в комплекте поставки
  • Переведена на английский страничка What's new
  • Добавлена поддержка двух камер (Olympus SH-2 и TG-4), общее количество поддержаных камер теперь over 800 (а именно 801 :)
  • Еще в паре мест обновлена LibRaw, еще чуть лучше работает с битыми файлами.

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

(здесь были ссылки для скачивания) Версия 1.1 выпущена, качайте с официального сайта

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

Comments

Кстати, а вот

WARN: [24-04 16:03:00.637] QWindowsWindow::setGeometry: Attempt to set a size (334x132) violating the constraints(220x266 - 524287x26600) on window QWidgetWindow/'Window_FilmstripWindow'.
[24-04 16:03:00.700] Started: 1
WARN: [24-04 16:03:00.789] QWindowsWindow::setGeometry: Attempt to set a size (334x93) violating the constraints(124x103 - 524287x524287) on window QWidgetWindow/'Window_FoldersWindow'.

как-то связано с запоминанием размеров Folders и Filmstrip?

С запоминанием - нет, не связано.

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

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

Серьезных нет но на первом старте (Win7 64 + OpenGL) крахануло. В не бета стврой версии была открыта папка с запоротыми raw файлами, не знаю сказалось ли это как то или нет. Вторичный запуск пошел нормально и воспроизвести я не смог, поэтому и не писал.

Невоспроизводимое, увы, невозможно чинить.

Crash - сохраняйте дампы пожалуйста (не закрывая окошка с сообщением о падении, в Task Manager, по правой кнопке "create dump file")

Ок сделаю если упадет еще раз. Сейчас попытался открыть директорию с массивным количеством равов (штук 800), просмотр сильно замедлился пока генерировались превью - буквально жмем на фотке в filmstrip и ждем секунд 5. Все на внутреннем SATA диске, нормальный просмотр равок обычно молниеносный. Настройки кэшэй все - по умолчанию. Как все превью сгенерировались то стало нормально работать.

Кодаки?

Да они - - у меня других нет :)

Эта конкретно директория была с файлами ProBack с кучей кадров для панорамок (поэтому много)

Вообще, "все превью" не генерируются. Генерируется видимое + (по умолчанию) 30 штук вперед.

Но мне не удалось на файлах с SLR/c (800 штук положил на SATA-диск, 3Tb-барракуда) заставить тормозить.
Нет ли случайно кого-то еще, кто дерется за этот же диск?

Да нет. Что интересно - я пытался пробегать по ленте и в конце директория показывало ? как превью а ближе к началу все превьюхи показывались нормально. Чем долше работало тем больше показывалось превьюх и меньше ?. Пока потом последние пару отработали и все стало бегать быстро.

Странно - попробую еще (свалю кучу файлов в какие то директории и потренируюсь попозже) .

Что я на эту тему хочу сказать
1) Превьюшки строятся в N потоков (где N - число ядер CPU, считая гипертрединг). Регулировки не предусмотрено - во всех моих тестах, втч на дисках подключенных через USB enclosure - производительность не было смысла ограничивать. Понятно, что на HDD может быть драка за диск, но вроде бы она в пределах разумного.

2) Проверил на отдельном SATA: превьюшки для SLR/c строятся даже быстрее, чем вынимаются здоровые JPEG-и из олимпусовских ORF. Так, на глазок, примерно 50 превьюшек в секунду (я растянул окно filmstrip на весь второй монитор, туда влезают аж 160 превью 100x66, вот эти 160 строятся за ~3 сек).

3) Если у тебя это происходит существенно медленнее, хочется понять что именно тормозит, процессор или диск. Это можно узнать, к примеру, по performance monitor-у виндовому, если он показывает в районе 100% disk active time - значит диск. CPU - ну опять же по загрузке ядер там же.

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

То есть я конечно избаловался с SSD (у меня 4 штуки в десктопе), быстрыми массивами и т.п., но в принципе тестирую даже по сети по wifi (300Mbit) и даже так оно приемлемо (безобразно, конечно, относительно нормальной техники, но долгих ожиданий нет).

Попробовал и кеширование уменьшил и директории с разными файлами NEF и DCR попробовал и повыходил из всех программулин которые только могли этот диск использовать (включая антивирус - хотя там стоит опция не сканировать диск этот). Все равно медленно - NЕF чуть быстрее, DCR точно существенно медленнее. А тест такой - открваю папку с кучей равов, выбираю первый из ленты ()обычно показывается почти сразу). Скроллирую ленту в самый конец и выбираю рав один из последних - жду секунд 5-10 пока появится. Диск в это время что то читает судя по звукам - через какое то время (пару минут) перестает и все работает с нормальной скоростью

Так а с точки зрения Performance Monitor - кто виноват (загружен на 100%), диск или процессор?

Вообще, для такого паттерна доступа (сразу мотанули в конец) - глубину префетча превьюшек (Prefs - Performance - Thumbnail cache) надо уменьшать до нуля.

Еще вдогонку.
Возможно, на каких-то файловых системах (FAT?) чем дальше файл от начала каталога - тем дольше открывается. Оно примерно так у мака на SMB, но вообще конечно в 21-м веке принято кэшировать каталоги....

Тогда вот да, на больших каталогах будут тормоза.

Ок буду тестировать с Performance Monitor - файловая система extFAT (у меня она с Мак осью шарится через бут)

Ну так что ж из вас клещами то тянуть приходится! exFAT, HDD, большой каталог.

Вот взял ноутбучный диск, форматнул в макоси в exFAT, включил в USB3-enclosure, налил в один каталог 2000 файлов. Размонтировал (кэши сбросить). Сунул обратно.

Ну таки да. Тормозит. Resource Monitor кажет 100% highest disk time даже без просмотра raw, только на построении превьюшек.

Рекомендаций, на выбор, три:
- или увеличить размер кэша превьюшек (они хранятся 4 байта на пиксель, нежатые, т.е. стандартные 200x133 - 100kb на превьюшку) и глубину префетча до максимальной (там 100, могу пару тысяч поставить в максимум). И, открывая каталог, один раз потерпеть, пока оно все прочтет. Оно закэшируется, один раз на каталог, дальше будет легче.
- или уменьшить величину Thumbnail prefetch depth, наоборот, до нуля. Она тогда будет декодировать только то, что видно в окне filmstrip (+1 с каждой стороны).
- ну или убрать окно с превью совсем и жить по старому.

Кроме того, на медленном носителе (а single HDD - медленный!) стоит количество raw decode threads уменьшать. Где-то до 2-3. Не меньше 2. Тогда префетчи не будут драться за диск.

Поигрался. Нулевой префетч (только видимое на экране) + 2 raw decode thread работают плавно.

А вообще - пора привыкать, что single HDD или гигабитная сеть - это (в 2015-м году) медленный носитель. Оптимизировать под него стандартные настройки мы уже не будем, нет смысла.

Работает спасибо. Только в ленте превьюшки почему то не всегда отображаются. Но не тормозит зато.

Одиночный HDD - все очень просто, мне надо каталоги шарить между Мак осью и виндами, а заводить для этих целей хардверный RAID немного накладно. Вот и работаю. Пока особо нигде не тормозило.

Я тоже вот увидел не-отображение, буду разбираться.
Лечится нажатием гайки (gear) на панели превьюшек и там Refresh, но непорядок.

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

Для "медленных" с одним HDD думаю надо зажимать. Как мне кажется для многих кто покупает себе скажем iMac для обработки фоток со встроенным диском и не парится с RAID (иногда даже не зная что это) это будет довольно частая ситуация. Я могу ошибаться конечно...

Я вот, к сожалению, не умею еще программно отличить SSD от HDD, надо разбираться и с этим.

А кто покупает аймак с HDD, а не (хотя бы) с fusion drive - будет страдать.

Ну iMac это к примеру. На PC все еще хуже - особенно если не собирать самому. К примеру можно держать кучу фотографий за много лет на большом разделе который на SSD не влезает итп.

Свою проблему я понял спасибо, надо чего то быстрее.

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

Я таки тестировал на HDD, но он у меня сформатирован NTFS, там на больших каталогах все гораздо веселее. exFAT - да, все довольно печально выглядит.

В новом FRV стало хуже, потому что "со всеми потоками" старый FRV реально при листании с устоявшейся скоростью - префетчит по 1-2 (все потоки работают только при открытии файла или позиционировании в случайное место). А новый - префетчит превьюшки во все ядра (считая и виртуальные) - на моих экспериментах с NTFS это работало весело и я не стал делать ограничений по декодерам thumbnails.
И, да, несколько потоков чтения на HDD - убивают перформанс очень сильно. Головка дрыгается, а толку нету.

Но, как я уже где-то выше написал, если панель Filmstrip закрыть, то все будет как раньше, в закрытую панель превьюшки не декодируются.

Попробую переконвертить ФС на NTFS у меня вроде парагоновские драйвера теперь есть в мак оси. Просто кроме exFAT ничего лучше в голову не приходило года три назад когда я все это устанавливал чтобы работало с Мака и виндов.

Да я доведу работу с медленным диском в USB3-читалке до приемлемой.

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

Проблема уходит если в настройках включить Prefetch thumbnails for preceding images

Соврал - не помогает...

Это смотря в какую сторону вы мотаете ленту.

То есть вот смотрите мой комментарий от 12:59, это виндовая драка за файл-локи, я уже вот починил, осталось сделать так, чтобы один файл (допустим он битый и там превьюшка 0x0 таки) много раз не онанировало.

>>Только в ленте превьюшки почему то не всегда отображаются

О как я люблю такие баги, которые на concurrency:

1) под виндой файлы открываются в exclusive mode (и, скажем, для std::filebuf(), который используются - я не знаю как отменить блокировки, смешно).
2) Мы отменили префетч, поэтому когда мы мотаем filmstrip - у нас оно не префетченое и вот будет читаться прямо сейчас.
UPD: или мы не включили "префетч назад" а по filmstrip идем в обратную сторону.
3) Дальше мы наудачу ткнем в еще не прочитанную иконку - и этот же файл будет читаться в другом месте (thumbnail cache - сильно отдельный от отстального FRV)
4) Шансы что они вдвоем подерутся - на медленном носителе достаточно велики.
Они и дерутся.

В результате из файла достается thumbnail размером 0x0, который и кэшируется в thubmbnail cache.

Вот не стал сильно париться: эти которые 0x0 просто кладутся в retry queue и будут префетчены повторно, через пару секунд, по таймеру.

Спасибо - это будет работать нормально

Ну и надо на mmap() переходить конечно везде. Это прогрессивно и правильно.

Записал в отдельный TODO по техническому долгу, летом надо бы его сделать.

Пишу повыше к началу треда, чтобы другим читателям было легче найти. Попробуйте версию отсюда: http://updates.fastrawviewer.com/data/110rc3/

Настройки:

  1. Preferences - Performance - Thumbnail cache - Thumbnail decoder thread count.
    Для HDD ставить в 1-3 (чем больше - тем больший будет приоритет у построителя превьюшек относительно остального).
    Для SSD: в 2x CPU core count (больше нет смысла, внутри программы больше 2x core не поставится). На SSD дает чудесный эффект: превьюшки строятся быстрее, чем я мотаю мелкие превью 100x66 в большом окне (в котором ~160 превьюшек).
  2. Preferences - Performance - Thumbnail cache - Thumbnail prefetch depth
    Можно уменьшать, но при одном потоке можно оставить как есть, оно зачитает в один поток вперед свои 30 штук, не мешая остальному.
  3. Preferences - Performance - Memory usage and performance - Number of.. decode threads
    Для плавного листания (пробелом) на HDD надо ставить в 2-3, иначе будет рывками. Если типичный паттерн поведения "на файл все-таки смотрим", то можно ставить (оставить) побольше чтобы оно в фоне насасывало побольше.

Разное

Следует понимать такие два момента

  1. При выборе файла через Filmstrip он начинает показываться не мгновенно, а ждет долю секунды на предмет, "не выберет ли юзер что-то еще". Поэтому на соседний файл переключаться быстрее по старинке, пробелом.
  2. При выборе через Filmstrip "не соседнего" (дальше чем 'Number of decode threads') файла - префетч соседей не делается (потому что детектируется random walk, префетчить нет смысла).

Соответственно, если хочется пролистать 2-3-4 файла (и в планах дальше листать вперед) - это быстрее делать пробелом, а не тыканьем мышом в filmstrip.
 

Попробовал спасибо. На exFAT с префетчем превьюх все равно тормозит сильно, я его в 0 оставил - так нормально. Сейчас конвертирую ФС в NTFS, в ней погоняю.

А перевозьмите оттуда же (http://updates.fastrawviewer.com/data/110rc3/) 627-й билд.

Я ему еще оптимизма оторвал: если оно всегда префетчило +1 row (потому что когда light table, это нужно)/а юзерские настройки шли вдобавок к/, то теперь в режиме filmstrip оно +1 file.

Или вот RC4: http://blog.lexa.ru/2015/04/26/fastrawviewer_11_rc4.html
Добавлена кнопка Filmstrip Off/On (если он по большей части не нужен, так и выключить!)

Спасибо - инсталлирую

Нужны, нужны настройки префетча per drive (в режиме указания типа, "Fast SSD", "Single fragmented HDD with exFAT").
Но не в этой версии, потому что вот threads префетчеров пускаются на старте программы и их число на рантайме не регулируется. Записал в кондуит (может заодно автомат сделаем, программно отличить SSD вроде можно, вот с массивами хуже).

Можно попытаться их потестить. :)
Не факт, конечно, что имеется хороший кросс-платформенный способ, но продвинутым юзверям можно дать крутилку числа i/o потоков и рекомендации по расчёту её параметров из данных, выплюнутых умным скриптом, пускающим консольную утилитку замера io performance.
Сам то я в силу профдеформации всегда sqlio для таких целей пользовался, но наверняка же хватает и других.

Толку то с тестов. Вот вставили новую карточку из фотика, хотят две фотки глянуть. И тут - тест.

Можно же UUID карты запоминать? Или он только у полноценных USB устройств есть?
Тест всё равно можно тихонечко сделать. Начинать число читающих тредов инкрементить и смотреть на характер деградации общей пропускной способности. Я наивно полагаю, что на медленных носителях оно до четырёх дойти успеет от силы. На дешёвых флешках всё становится ясно на двух потоках, по моему опыту.
Но, вероятно, многое придётся переписать. :)

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

Рассуждения же общего плана, увы, не работают. Вот, казалось бы, одиночный HDD. Азбука - фигачить в один поток, потому что seek-и убивают. На практике оптимальными оказываются 2-3, потому что оно же не только читает, но и распаковывает, процессорные ядра надо чем-то загружать.
Массив, который по latency еще хуже одиночного диска (по идее) - 8 потоков (по числу ядер), потому что читается то быстро.

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

Ну, есть, в конце концов, и возможность некэшируемо читать. Но, видимо, это всё не сильно кросс-платформенно получится.:)

Ну вот смотри - мы договорились до того, что мы считаем статистику реальной работы юзера и адапативно подстраиваемся. Идея, в принципе, нормальная. Можно, к примеру, просто вариабельно менять число потоков +-1 и, если достигается улучшение, менять среднее. Вопрос в скорости этих изменений, но опять же можно решить (ну и идея то - хорошая!)

Но если при этом читать без кэширования - это наказать юзера.

В рабочем процессе нельзя, конечно. Тихонечко, тихонечко в idle.

В idle полезнее префетч просто сделать. В один поток и не парясь о статистике.

Ну и вдогонку. Как вы понимаете, писать ничего нельзя в таком тесте. Флеш-носители, еле живые, вот это вот все.

Читать, конечно же.
Флеши, да, с ними всё ясно. Правильная эвристика для removeable drive малых размеров - ОДИН поток. Дещёвые такие все, по моему.

Хм. А есть API для определения цены?

Потому что вот даже Class 6 (тормозной) в макбучном ридере (USB3, скорее всего, но не вдавался) хорошо работает в 4 потока.

Чтобы сейчас покупать Class 6 - нужно быть непонятно кем.

У меня есть Class 10, который деградирует на чтении в два потока не на десятичный порядок, но близко к тому. При этом, да, формально он свои 10 мегабайт НА ЗАПИСЬ даёт.
Эта мерка, она же для тепличных условий внутри камеры. Ничего про многопоточное чтение там нет, как я понимаю.

Ну тем более - и API по цене (или формальным характеристикам накопителя) не спасет.

Нужны "классы накопителей" (достаточно 3-4) и возможность назначить их на тома. Не автоматом.

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

"для сокрытия раскрытия" я спросонья не уверен что понял. Превратить панель из "окна" в заголовок? Зачем вам заголовок?

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

Перестанет лезть - сделаем, конечно. Но не так, как в лайтруме, конечно же. Скажем, если уж свернуть (но не убирать) EXIF, то на заголовке должно остаться EXIF Summary (экспозиционные параметры), ну и со всеми панелями где это осмысленно - аналогично.

[quote]То есть да, все (лайтрум, к примеру) приучили к такому интерфейсу, но мне он кажется вынужденным - у них так много в боковых панелях, что раскрытое - не лезет. У нас - даже на ноутбучном экране пока еще лезет.[/quote]

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

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

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

[q]Конкретно с фильмстрипом, расположенным внизу - как его прятать то, во что превращать?[/q]
А чем реализация в пресловутом лайтруме не нравится, бордюр в десяток пикселей треугольник, нажал на него, ушло, остался бордюр, нажал на него вышло ;)

[q]Для него придется или освоить стандартный хоткей[/q]
Да не проблема освоить, просто хочется часть операций выполнять не подключая вторую руку ;)

В пресловутом лайтруме для фильмстрипа - нет такой реализации.

[q]В пресловутом лайтруме для фильмстрипа - нет такой реализации.[/q]

Как это нету.
Правда пишу по памяти для левой, правой и верхней областей точно есть, для нижней вроде тоже...

Ну вот текущий Lr6, режим Library. Фильмстрип - внизу, переместить вбок - нельзя, закрыть-открыть треугольником нельзя, можно вот размер поменять и все: https://www.dropbox.com/s/v6m754f9ggkf8ao/Screenshot%202015-04-25%2010.1...

UPD: пардон, увидел треугольник ВНИЗУ. Но он жрет столько места по высоте, что ТАК мы делать не будем точно. Учите один хоткей. F6

[q]переместить вбок - нельзя[/q]
А вот это не надо.

[q]закрыть-открыть треугольником нельзя[/q]
Дома посмотрю. (на памяти осталось вроде всё скрывал)
А в режиме девелоп?

Как тут правильно цитировать?

Да и так видно - ну и прекрасно.

[q]увидел треугольник ВНИЗУ. Но он жрет столько места по высоте, что ТАК мы делать не будем точно.[/q]
У меня сейчас нет программы перед глазами, а если треугольник посередине(ну или не посередине) статусной линии.

[q]Учите один хоткей. F6[/q]
Дело не в учёбе. Для использования хоткея необходимо задействовать вторую руку, или перенести руку от мыши на клавитуру. А если у меня работа настроена на использование мыши. Следующая предыдущая мышиные кнопки, зум - колесо...

Если на мыши есть лишние кнопки - назначить на них.
Если нет - крестик закроет, Menu - Panels - Filmstrip откроет.

Просто вот потеря высоты под треугольник (1% по ширине, а остальные 99% просто пустые) - на маленьких экранах недопустима.

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

Посмотрим. Меня выезжающие панели бесят.

С другой стороны, вот есть уже иконки кликабельные в нижней строке, можно туда воткнуть.

(отвечаю тут, чтобы оба участника треда увидели ответ)

Сделал кнопку в статусбаре, рядом с включением/выключением всех панелей.
Удобно, кстати. Спасибо что настояли!
http://blog.lexa.ru/2015/04/26/fastrawviewer_11_rc4.html

[q]Если нет - крестик закроет, Menu - Panels - Filmstrip откроет.[/q]
Не...
Свойство, или действия над объектом в разных местах....

Ценой места.
Лайтрум на 15" макбуке (1400x900 эффективных) выглядит безобразно. Собственно картинка занимает четверть экрана по площади (померял). В том числе и за счет нижнего поля со стрелкой, совершенно бесполезного.

Еще кнопку можно разместить в углу, вот так:
https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip.png

Так она будет расположена рядом с крестиком после закрытия, что неплохо.

Как вариант визуально "оставлять" кусочек темной подложки:
https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip_2.png

https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip_3.png

[q]15" макбуке (1400x900 эффективных)[/q]
Понятно что у всех мониторы разные, у меня 1900х1200 24
Вот и хочется...
А всё таки, если всунуть в строку состояния-управления, ведь там место есть или только у таких как я...

Да, вот в строку состояния - наверное можно. Только Filmstrip, остальным много чести.

Add new comment