FastRawViewer 1.0.5 beta2

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

В FRV 1.0.5 Beta2 исправлены следующие проблемы (они были всегда):

  • Исправлена ошибка в разборе EXIF-данных в JPEG-файлах панасоника (c RAW-файлами проблем не было)
  • Исправлена проблема, приводившая к пропаданию отдельных (не в dock area) информационных окон (EXIF/Histogram/etc) в Mac OS X после вызова диалога настроек (или других модальных диалогов). Проблема была плавающая, связанная с таймингами, не все с ней сталкивались (в частности, мне пришлось постараться для воспроизведения).

Comments

Уважаемый lexa, можно выпросить ещё фичу к программе: счётчик кадров так называемый?
В файлах записана эта информация, правда кто во что горазд в разносе этой информации по файлу, но её можно найти.

Вот именно "кто во что горазд". А камер мы поддерживаем 780 уже.

Для камер Sony есть небольшая помощь:
| | | | Sony_Tag9050_0x0032 = 60
| | | | Sony_Tag9050_0x0033 = 60
| | | | Sony_Tag9050_0x0034 = 0
(65536 * 0) + (256 * 60) + 60 = 15420
онлайн проверка лежит [utl=http://tools.science.si/index.php]тут[/url]
Могу помочь найти для других камер такую информацию...

Вот смотрите, задача FRV - разбор фотографий, а не анализ камеры при покупке.

Для разбора фотографий счетчик кадров камеры не нужен. Следовательно, мы на ЭТО тратить время не будем, потратим на что-то полезное.

Во-во.
А то у меня какие-то непонятки с кэшированием.
Win 7, SP1, 64
i7-4790k, 16Гб, GTX 970, 3 - HGST HUS724020ALA640

40 RAW, 6 threads
Вешаем листание по файлам на колесо мыши.
Если крутить колесо на счёт "22" всё идет нормально.
Но если увеличить скорость верчения ;) , При первом просмотре, для отбора трэша иногда хочется быстро пробежаться по файлам.
Очень быстро наступает "спотыкач", причём довольно серьёзный, и никак 40 файлов в кэше не корелируют с количеством файлов до "спотыкача", там иногда и через 10 наступает....

Вы занимаете 6 ядр CPU (из 4) декодированием вперед. Одновременно 8 ядер (из 4), потому что hyperthreading, пытаются заниматься показом.
Кроме того, у вас HDD и эти 6 потоков декодирования дерутся еще и за диск. А он не SSD и к конкуренции относится плохо.

Имеет смысл попробовать уменьшить количество decode threads, скажем до двух.

Уменьшил, стало получше. (кстати не помню по умолчанию сколько стояло, а всё сбрасывать не хочется...)
Не такой явный, и сильный, но проскакивает, и как-то не складывается с 40 файлами.
Может дать возможность для эксперементов поставить количество файлов побольше в 64 разрядной версии?

Паттерн то работы какой? Пролистали (больше чем) на 40 вперед, а потом назад?

Нет, просто листаем вперёд, быстро.
Вечером поэксперементирую, с анализом загрузки процессора...

При листании (только) вперед увеличение размера кэша ничего не даст. Что за радость с того, что ранее прочитанное остается в кэше.

Проблема, повторяю, в HDD: если один линейный поток данных с HDD может читаться ну скажем на 100Mb/sec (c трех, в зависимости от организации - может и 200-300), то несколько потоков декодирования одновременно - дергают головку, мешают друг другу и типичная скорость падает "на порядок" (зависит от диска, от RAID-контроллера если есть, от умности soft-raid/файлового кэша если есть)

Вдогонку.
Просматриваю файлы из FastStone Viewer.
Потом по клавише на нужном файле зову FastRawViewer.
Потом знаю, что через файлов 20 есть следующий нужный файл, пытаюсь быстро прокрутить до нужного. вот тут наблюдаетсся "спотыкач".
Меня больше всего смущает, что по ощущениям "спотыкач" происходит ну не на 40 файле...

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

Соответственно, спотыкач происходит от того, что у вас запущено много decode threads и они дерутся даже не за процессор, а за диск (потому что HDD очень плохо относится к параллельным запросам на чтение).
Соответственно, чем меньше одновременных threads в случае HDD - тем лучше (ну от формата данных зависит, если сильно жатое одна история, если дешевое по декодированию - другая; какая камера, кстати?).

Для листания "на 20 вперед" - Alt-O, стрелку вверх или PgUp (размер шага и того и другого зависит от количества файлов в каталоге), Enter.

>> при листании (только) вперед увеличение размера кэша ничего не даст.
Вот теперь всё стало на свои места, это фактически кэш назад.

>> какая камера, кстати?
Sony ILCA-77M2

> Alt-O, стрелку вверх или PgUp
20 файлов было для примера....
Проще тогда закрыть, в FastStone Viewer встать на нужную превьюшку, и опять позвать...

Будут вам превьюшки (filmstrip) в следующем major update. Сроков не обещаем, но вот в 1.0.5 хвосты текущие подчистили вроде, следущая версия должна быть с Filmstrip.

А, еще.
Закрывать не обязательно. Preferences - File Handling - Run single program instance.
Тогда окна не размножаются.

И еще вдогонку.
У меня нет и не могу сделать 3-дисковый массив, есть 8-дисковый (RAID6 на адаптеке) и вот сунул один 10k rpm диск в корзину.
Остальной компьютер близкий к вашему: i7-4770k@4.2, 32GB RAM, gtx970. Использую OpenGL-версию FRV, но в данном случае никакой разницы нет.

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

Результаты:
8-дисковый массив: при любом количестве decode threads (1-8) оно успевает. 'Highest disk time' пл Perf Monitor - дорастает до 80% но практически никогда не упирается в 100%

1 диск 10k rpm (он будет медленнее массива по линейному чтению, но быстрее по seek)
1 thread - упираемся в ожидание декодирования при листании, диск не насыщается, но оно просто много ждет завершения декодирования т.к. префетч по сути не работает.
2 threads: среднее время капельку лучше, но есть разброс (спотыкач). По process monitor видно, что highest disk time: 100% и уперто именно в диск.
...
промежуточные тестировать не стал, на 8threads видна еще более жестокая драка за диск.

Рекомендации
SSD, конечно. Уж как минимум, для рабочих файлов
Если нет, то threads=2.

У меня не массив.
1. Операционка и темп.
2. каталоги(Ligtroom)
3. исходники

А диски Hitachi Ultrastar 7200rpm 64Mb - довольно быстрые..
Просто теперь поняв принципы кэширования, и подход будет и к тестированию, и к работе чутку другой.
Может в документации, чуть больше уделить этому моменту внимания.

>Закрывать не обязательно. Preferences - File Handling - Run single program instance.
> Тогда окна не размножаются.
А оно открывается мгновенно...

Если не массив, то мой однодисковый тест даже в лучших условиях. Т.е. линейное чтение у современных дисков скорее всего быстрее чем у этого WD-раптора, а вот seek - медленнее ну и rotational delay больше.
1-2 threads и куку.

Q&A секцию пора делать и этот вопрос там отразим обязательно.

UPD: Crucial MX100 256M стоит чуть больше 100 баксов. Уж рабочие файлы на нем не страшно держать, если бэкапы есть.

Сейчас могу посмотреть только Legacy версию на XP.
И ненашёл настройку ассоциации файлов.(дома OpenGL)
Поэтому пишу по памяти(вроде этого нет, хотя могу ошибаться)
В ассоциации файлов хочется кнопку - выбрать Только РАВ файлы.

А в XP этого диалога и нет. Это не мой диалог, а системный.
IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI (вот я про это писал: http://blog.lexa.ru/2014/11/16/q_windows_file_associations.html )

И кнопок там тоже нету: я системе предъявляю список расширений, которые умею (на инсталляции, не на рантайме), а диалог оно само.

Поэтому check all, потом uncheck .jpg, OK

>>> Crucial MX100 256M
Не - мы любители, и весь архив лежит в доступном месте (+бэкап)
Периодически к разным съёмкам возвращаемся, попечатать, походы вспомнить.. ;)
А гонять туда сюда не... - Поэтому SSD пока для меня не актуально.

Ну вот могу сказать, что такому компьютеру (примерно вот как у меня) - SSD очень к месту.
Сначала под систему.
Потом втянетесь.

Ну тогда уже на M.2 смотреть ;) .....

Если есть слот M.2 с PCI Express, а не просто с SATA, то да.

Но даже на SATA разница огромная.

А почему нам нужно декодировать в таком количестве потоков?
Стоит прокручивать, хоть по 30 хоть по 50 файлов в секунду но не декодировать их в полное разрешение!
Остановились на каком то кадре, вот тут и стали его декодировать. Крутим дальше, снова не нужно декодировать, остановились, снова декодим картинку.
Просто при старом подходе нам не хватит никогда мощей процессора и дисков. Тут же стоило только остановиться на 1-3 секунды (не эталон по времени, хоть 0.5 секунды) и тут можно...
Что пролистать, пока крутим колёсики, это уже другой вопрос, хоть просто перебор названия файлов, а может внутренний Jpeg превью...

Будет filmstrip - будет именно так. Крутите в отдельной дырочке jpeg-и, пожалуйста.

А декодировать RAW частично (ну там с частичным разрешением) - для большинства форматов нельзя.

Остановились, работаем с картинкой, продолжаем работать на кэш, декодим остальные в пару тройку потоков...

Add new comment