FastRawViewer 1.0.5

Для полноты картины, чтобы не анонсировать в блоге только беты

FastRawViewer 1.0.5 вышел, качаем с оф-сайта

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

Comments

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

т.е. использовать не для целей отбора в постобработку, а конкретно для задачи "отрендерь мне все и быстро!"

p.s. как дальнейшее развитие, конечно, каталогизация, но это оверхед

Да, нас периодически про это просят. И это есть в планах, хотя вот конкретные формы ЭТОГО непонятны пока.

Написал много всякого и стер. Пусть полежит в планах, пооформляется.

А какой механизм планируется? Построение в реальном времени,
или сохранение в промежуточную базу и уже от туда показывать?

Механизм чего?

>>> filmstrip
>>> Будут вам превьюшки (filmstrip) в следующем major update.

Как эти превьюшки будут формироваться, на лету, или формируем в базу, потом из неё показываем...

В качестве превьюшек будет показываться встроенный JPEG (за исключением кодаков, где превьюшка - тоже RAW, но мелкого размера). Рендерить десятки(тысяч) raw на лету (с полной распаковкой, основные тормоза в ней) - нет возможности.

Пока необходимости в базе не видно, дальше посмотрим.

Я не имел ввиду рендерить реальные RAW.
Всё равно будет тратится время на ресайз даже из встроенного JPEG. Будет превьюшка - допустим 300*300 (те. 300 по длинной в каждой ориентации)и каждый раз ресайз. А если проресайзить и загнать в базу, потом уже показывать только имеющиеся превью.

Я вот и говорю "посмотрим".
Пока я необходимости особой не вижу: распаковывать JPEG можно сразу с даунсамплом, компьютеры сейчас быстрые, ядер много.

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

Это понятно. Мне нравится(почти) как это реализовано в FastStone Image Viewer.
Логично имя файла с каталогом.
На этапе работы наплевать на дубли и дырки, размеры там мизерные. Хотя врядли дубли, скорее дырки...
Просто потом есть функция Оптимизировать базу которая и подчищает весь мусор. Которую сам пользователь запустит когда хочет.

>>>> компьютеры сейчас быстрые, ядер много.
Даже на быстрых чувствуется скорость работы с сохранёнными превьюшками.

FastStone показывает 'grid', то есть одновременно нужно показать много (десятки)
А для показа strip - нужно показать одновременно - десяток (один). Это совсем другая история, этот десяток можно достаточно быстро прочитать (и декодировать).

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

Но приделать базу, потом, если скорость не будет устраивать - ну реально же несложно. Чуть сложнее будет, если сжимать в нее на лету, но и тут никакого рокет-сайенса нету.

Ну вот эксперименты с JPEG-ами, пока. Быстрый компьютер, но HDD.

Даже префетч не нужен, 56 превьюшек в окне - декодируются и показываются за комфортное время. Быстрее, чем я могу их отсмотреть и ткнуть в нужную. Это в 8 потоков, медленное место - HDD.

Сделать ЭТО быстрее, чем делает faststone оказалось совсем просто.

Там если Выставить 200х200 то не так и много.(а хотелось бы и поболее 300х300)

Про дырки не понял.

Неправильно выразился, это излишек в базе, или "дырка" от raw.
Был raw, построилась превьюшка, Удалили raw, другим способом, в базе превьюшка есть. файла нет.
Или переструктурировали каталог. Даже если удалять из FastStone, база превьюшек не трогается.
На этапе просмотра превьюшки только добавляются.
А вот "чистка мусора" отдельная операция.

Но приделать базу, потом, если скорость не будет устраивать - ну реально же несложно.

Наше дело раскачать, чтоб мысли в разные стороны смотрели ;)

Вот меня лично эти базы достают. Что ACDSee, что FastStone.
Буду делать это место только если будет необходимо. Пока я необходимости не вижу, примитивный photonic с одного HDD с каталога с 3000+ файлами (jpeg) - показывает все приемлемо по скорости.

Путей как его ускорить видно сходу много (даунсамплить при декодировании, декодировать в много потоков видимую часть, затем пустить в фоне одну нитку декодировать дальше).
Если этого не хватит - будет база, конечно. Sqlite прикрутить - дело ну на день.

Легкое тестирование на быстродействие.(продолжение)
6 threads.
Plextor PX-G256M6e M.2 PCI-Express.
Освободил колесо крысы и крутанул что дурное - Красота.(ни тебе спотыкача, ни тебе медленной работы....)

Ну вот в теории, работу с HDD можно улучшить, убрав параллельные запросы.
На практике, в 2015-м году, даже заниматься этим не хочется. Потому что все уже.

Чего бы хотелось, но это похоже можно будет сделать после filmstrip'а
выбираем несколько файлов, и показываем их одновременно, зумим синхронно, синхронно перемещаемся по полю кадра.
Показываем с пикингом и без.
Это все для сравнения кадров....

Не в версии 1.x.
Для одновременного показа нужно очень серьезно менять потроха программы. Вот такая вот выросла.

В очередной раз, прописывая 5-6 тегов в Bridge, плакал. Мышкой туда — мышкой сюда.

Поясни подробнее. Это ты про keywords?

да. Там нельзя на них шорткаты повесить. В результате оно очень мучительно (или сначала расставляем лейблы а потом их конвертируем в keywords, но лейбл может быть только один, так что тоже мучительно).

А у меня есть несколько ситуативных keywrods — ну типа people, cat, car, вот такое. Обычно частых в пределах 5-6, можно было бы повесить на шорткаты и расставлять быстро. А из-за того, что на клавиатуру их не повесить, надо тыкать мышкой в дерево keywords и потом обратно в filmstrip.

Если бы в FRV можно было такое настроить (с поддержкой иерархии и настроек про разделители и родителей как в Bridge) было бы очень круто.

В планах есть. Естественно, с шорткатами. Когда, чего и сколько - посмотрим.

Относительно разделителей не понял, все что я видел в дикой природе выглядит так
- файлы экспорта-импорта keywords - разделитель табуляция
- в XMP есть два тега, в один все свалено кучей, во втором разделители - вертикальная палка.

UPD: увидел в бридже настройку про разделители. Да, это несложно и так и нужно.

А ты посмотри в настройки Бриджа. Там может быть не только вертикальная палка.

И, да, есть ещё выбор, добавлять ли A, A|B и A|B|C когда пользователь добавил A|B|C|D :)

Все увидел уже. Никогда не пользовался этой настройкой, всегда хватало defaults.

Вот сейчас заметил что меня немного раздражает при открытии в Win7 FRV сначала открывается в оконном режиме, а затем разворачивается в полноэкранный, если была закрыта в полноэкранном. Это все хорошо и правильно, но раздражает анимация разворачивания.

Вот для сравнения XnView сразу появляется на экране развернуто(полноэкранно). FRV появляется, а спустя мгновение разворачивается.

Я перепутал, не полноэкранный, а просто Maximize.

Т.е. если запускается в Maximize, то появляется не Maximize и разворачивается.

Это вот для чего:
- когда мы maximize 'нажмем обратно' - операционка вернет нам предыдущую геометрию.
- чтобы было чего возвращать - эта геометрия должна быть. Вот ее и ставим первоначально.

Анимация на OS X - отключается (но глобально, для всех программ)

Вероятно есть какой то хак, т.к. XnView минимизируется корректно, после запуска сразу в maximize.

И вот еще такую мелочь вчера заметил — мне было бы удобно по Esc выходить из полноэкранного режима, а вторым нажатием закрывать программу, ну или первым нажатием сразу закрывать, если не включен полноэкранный режим. Я так понял сейчас в настройках это нельзя сделать?

Увы - один shortcut - одно действие. Плата за произвольные настройки этих самых шорткатов.

Алексей, а Вы планируете добавить в FRV функцию браузинга файлов? Мне ее очень не хватает, хотелось бы иметь возможность открывать папку с равками и видеть их превьюшки, чтобы выбрать нужную и открыть. А если бы в программу еще добавили функцию пакетного переименования файлов, то я бы смог полностью отказаться от использования Adobe Bridge.

Filmstrip: будет в следующем major update. Собственно, у бета-тестеров уже есть :)

Batch-операции ("переместить все файлы с рейтингом 3 в каталог") - в планах.

Batch rename сложный (на основе EXIF-данных) - просят, но в планы пока не попало.

Про Filmstrip - отлично, буду ждать. А вот про групповое переименование - жаль, но буду надеяться на появление в более поздних версиях.

Вот я смотрю на бридж и чего-то тоскливо мне.

Делать как там - выглядит глупо и недоделано. К примеру:
- XMP-данные нельзя брать, рейтинги, метки, ключевые слова
- зато можно брать EXIF-метаданные, только вот выбор какой-то странный, вот Color profile есть (а он практически всегда будет untagged для raw), а (тупо) Camera make/model - нету.

Делать как-то правильно - нужно знать как, а я не понимаю т.к. никогда ничего батчем не переименовывал. Надо чтобы кто-то спроектировал эту фичу, оставив там 95% нужного и выкинув 80% ненужного.

Add new comment