FastRawViewer 1.0.5 beta2

lexa - 09/Фев/2015 13:56

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

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

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

Comments

RuStn - 09/Фев/2015 20:04

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

lexa - 09/Фев/2015 20:08

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

RuStn - 09/Фев/2015 20:18

Для камер 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]
Могу помочь найти для других камер такую информацию...

lexa - 09/Фев/2015 20:22

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

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

DVall (not verified) - 11/Фев/2015 22:29

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

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

lexa - 12/Фев/2015 00:12

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

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

DVall (not verified) - 12/Фев/2015 06:58

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

lexa - 12/Фев/2015 09:08

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

DVall (not verified) - 12/Фев/2015 09:17

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

lexa - 12/Фев/2015 10:41

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

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

DVall (not verified) - 12/Фев/2015 09:25

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

lexa - 12/Фев/2015 10:33

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

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

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

DVall (not verified) - 12/Фев/2015 11:40

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

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

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

lexa - 12/Фев/2015 11:44

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

lexa - 12/Фев/2015 11:45

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

lexa - 12/Фев/2015 12:35

И еще вдогонку.
У меня нет и не могу сделать 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.

DVall (not verified) - 12/Фев/2015 12:56

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

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

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

lexa - 12/Фев/2015 13:14

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

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

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

DVall (not verified) - 12/Фев/2015 13:18

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

lexa - 12/Фев/2015 14:07

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

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

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

DVall (not verified) - 12/Фев/2015 13:28

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

lexa - 12/Фев/2015 16:20

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

DVall (not verified) - 12/Фев/2015 17:06

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

lexa - 12/Фев/2015 17:56

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

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

RuStn - 12/Фев/2015 16:21

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

lexa - 12/Фев/2015 16:36

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

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

RuStn - 12/Фев/2015 16:24

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