FastRawViewer 1.5.5 Beta

lexa - 30/Ноя/2019 12:22

Продолжаем немного улучшать FastRawViewer. Это бета, там достаточно много мелких правок в LibRaw и в разборе метаданных, по нашим тестам все хорошо, но жизнь бывает богаче. Качайте, тестируйте, жалуйтесь... Нет жалоб - нет исправлений.

Помимо вышеупомянутых мелких правок:

Поддержка камер

  • Panasonic S1H

Новые фичи и настройки

  • Новая настройка: Image Display - Crop to manufacturer recommended margins
    Если включить, то при показе RAW-файлов они будут обрезаны в соответствии с камерными настройками кропа (может не работать со всеми камерами, пишите пожалуйста  /с примерами/ если у вас не работает).
    DNG-тэги DefaultCrop обрабатываются теперь в соответствии с этой (новой) настройкой.
    Старая скрытая настройка DNGDefaultCrop удалена.
  • Новый режим обработки ситуации, когда кнопки навигации (следующий/предыдущий файл и т.п.)   быстро нажимаются несколько раз подряд:
    • С настройками по умолчанию, FRV запоминает до 5 нажатий кнопок навигации и исполняет; их последовательно (это можно отключить/включить скриптами DisableNextPrevQueue/EnableNextPrevQueue).
    • добавлена новая настройка Preferences - Interface - Combine multiple next/prev file keypresses into one jump
      Если она включена, тоНовая настройка работает "не так гладко", но отрабатывает перемещения быстрее.
      • размер очереди в которой запоминаются кнопки не ограничен
      • очередь исполняется "в одно действие" - файл к которому нужно переместится рассчитывается исходя из записанного в очереди и текущего открытого файла.
  • Debug log:
    • Увеличена производительность подсистемы логирования.
    • Новая настройка Preferences: Other - Flush log to file immediately
      (доступна, если включена запись лога в файл).
      Эта настройка предназначена для ловли крашей FastRawViewer (последние записи в логе не будут потеряны при крэше). Во всех прочих случаях ее не стоит включать т.к. она уменьшает производительность (особенно на медленных дисках).
  • Несколько улучшена производительность кэша JPEG.
  • Улучшена поддержка файлов DNG содержащих 8-битные изображения сжатые JPEG-сжатием.
  • Grid View (показ плиткой): размер шрифта в верхней строчке (текущая папка, количество файлов)  изменяется вместе с изменением размера шрифта у превьюшек.
  • При ручном открытии (до того закрытой) панели Folders, дерево папок будет
      спозиционировано на текущую папку.
  • Touchscreen (только Windows)
    • Новая настройка Touchscreen - Highlight toolbar item under mouse
      Умолчание: включена
      Если выключить, то кнопка toolbar под мышкой не будет подсвечена. Предназначена для использования совместно с (настоящим) touch screen: при нажатии на кнопки тулбара пальцами последнее место нажатия запоминается (системой) как позиция курсора мыши и последняя нажатая кнопка на тулбаре остается подсвеченной даже если у нее не меняется состояние. Данная настройка выключает таковую подстветку.
    • Новая кнопка в нижней строчке программы, для включения/выключения поддержки touchscreen одним пальцем.
      Включается через Customize bottom bar - Toggle touchscreen features.
      Нажатие этой кнопки полностью аналогично включению/выключению соотв. галочки в Preferences.

Исправлены ошибки

  • XMP sidecar не перемещался/не копировался вместе с родительским файлом если был включен режим XMP read-only.
  • Исправлена (очень редкая) ошибка, когда в паре RAW+JPEG показывался неверный JPEG-файл.    Эта ошибка влияла только на показ, операции copy-move делались верно.

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

Берите из более свежего анонса

Comments

blacklion - 01/Дек/2019 00:26

Вопрос у меня к тебе такой: я тут на одном сайте спорю, что нельзя сравнивать Core-X/Threadripper с Core/Ryzen потому что 4 канала памяти а не 2, а в современном мире память медленная и упереться в неё просто. Мне рассказывают, что это, наоборот, редкость, на Blender и Cinebench не влияет.

А как по твоему опыту вот например с FRV на очень быстром диске?

lexa - 01/Дек/2019 08:13

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

Ну и на конверсии FP32->FP16 конечно тоже упирается и на просто нарезке данных в слайсы - тоже упирается.
Только с гистограммой можно надеяться что-то сделать (у меня большие надежды на AVX512CD, но еще даже и не приступал), а там где просто mem->mem или mem - одна инструкция - mem, там вообще ничего не сделать.

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

Если их каким-то чудом удалить, производительность на текущей архитектуре FRV вдвое не вырастет.

lexa - 01/Дек/2019 08:22

Ну и поскольку у меня Core 9700 на столе, а Core-X 7960x под столом и частоты у них, так получилось, одинаковые (9700 чуть придушен по TDP, а Core-X разогнан) и базовые частоты памяти одинаковые (3200), вот про прочие тайминги памяти не знаю - то я, получается, периодически сравниваю (в уме, не бенчмарками) 8 и 16 ядер (и 2/4 канала памяти).

Сравнивать их впрямую непросто, потому что на 9700 у меня макос, а на 7960x - винда. Т.е. даже банальная скорость компиляции несравнима (clang/microsoft). Блендеров и синебенчей не гонял (и не проси, не буду)

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

И всякая простая многопоточность, вроде OpenMP (и подобного: QtConcurrent) - на очень многих ядрах не блистает.

Я не знаю как сделан блендер/синебенч, но вообще заглянуть в профайлер на 16-24-32 физических ядрах было бы очень полезно. Просто тупо посмотреть на wait в VTune (это можно и на бинарнике без символов). Совершенно не исключено, что там есть огромные резервы.

И возвращаясь к первому абзацу и к твоему вопросу: я бы сказал, что очень мало задач, где 16 ядер прямо вот вдвое быстрее чем 8. Их, скорее, нет, таких задач. Амдал не дает. Соответственно в среднем по больнице нагрузка на память у 16ядер/4 канала - как бы не меньше (но это не значит что 16 ядер/2 канала памяти не будут тормозить)

blacklion - 01/Дек/2019 12:45

Блендер и циебенч как раз самые распространённые многопоточные «не синтетические» бенчмарки и их результатов в интернете хоть ложкой ешь, никого дополнительно просить не надо. И у них как раз прекрасная масштабируемость по ядрам (до 32 — точно) и практически никакой зависимости от числа каналов памяти. На что и напирает оппонент, утверждая что задачи, где каналы памяти важны — большая экзотика, и потому Райзен (простой, с 2 каналами) универсально лучше Core-X (с таким же числом ядер, но четырьмя каналами).

Моя общая чуйка (memory is new disk) и опыт в многопоточном программировании всяких интересных задач с учётом mechanical sympaty, говорит мне о том, что задач, которые выиграют от удвоения пропускной способности памяти довольно много. Понятно, что не в двое, но статистически значимо. Но так как это очень редкий вид бенчмарков во-первых, а во-вторых, моя интуиция говорит что это задачи типа массивной компиляции на очень быстрых носителях и всякие инженерные рассчёты типа нагрузок или гидродинамики в CAD'ах высокого уровня, что тоже редко (~никогда) вообще бенчмаркают в обозрах, то я не могу найти ни подтверждений своей чуйке ни опровержений…

lexa - 01/Дек/2019 16:49

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

blacklion - 01/Дек/2019 19:44

По идее, pointer chasing должен ещё выигрывать, компилятор, например, который с графами работает, а в случае C++ и тонн шаблонов там графы будут очень развесистые.

lexa - 01/Дек/2019 20:10

В такой ситуации latency же а не bw. А latency у этих HEDT как бы не похуже?

(ну и графы эти будут в кэшах конечно ж)