FastRawViewer 1.0.5
lexa - 14/Фев/2015 12:55
Для полноты картины, чтобы не анонсировать в блоге только беты
FastRawViewer 1.0.5 вышел, качаем с оф-сайта
Крупных изменений относительно анонсированных ранее (и еще тут) нету, поправлены мелкие шероховатости, дублировать текст еще раз не буду.
Comments
А вот подумалось
несмотря на то, что FRV позиционирует себя как альтернатива необходимости массового рендера превью, у него на самом деле для этих целей все козыри - используя имеющиеся возможности можно легко, быстрее чем остальные и без проблем эти самые превью отрендерить в любом размере и любыми настройками (хоть два рендера сразу +-1ev причем в один файл)
т.е. использовать не для целей отбора в постобработку, а конкретно для задачи "отрендерь мне все и быстро!"
p.s. как дальнейшее развитие, конечно, каталогизация, но это оверхед
Да, нас периодически про это
Да, нас периодически про это просят. И это есть в планах, хотя вот конкретные формы ЭТОГО непонятны пока.
Написал много всякого и стер. Пусть полежит в планах, пооформляется.
>>> filmstrip
А какой механизм планируется? Построение в реальном времени,
или сохранение в промежуточную базу и уже от туда показывать?
Механизм чего?
Механизм чего?
Механизм чего?
>>> filmstrip
>>> Будут вам превьюшки (filmstrip) в следующем major update.
Как эти превьюшки будут формироваться, на лету, или формируем в базу, потом из неё показываем...
В качестве превьюшек будет
В качестве превьюшек будет показываться встроенный JPEG (за исключением кодаков, где превьюшка - тоже RAW, но мелкого размера). Рендерить десятки(тысяч) raw на лету (с полной распаковкой, основные тормоза в ней) - нет возможности.
Пока необходимости в базе не видно, дальше посмотрим.
будет показываться встроенный JPEG
Я не имел ввиду рендерить реальные RAW.
Всё равно будет тратится время на ресайз даже из встроенного JPEG. Будет превьюшка - допустим 300*300 (те. 300 по длинной в каждой ориентации)и каждый раз ресайз. А если проресайзить и загнать в базу, потом уже показывать только имеющиеся превью.
Я вот и говорю "посмотрим".
Я вот и говорю "посмотрим".
Пока я необходимости особой не вижу: распаковывать JPEG можно сразу с даунсамплом, компьютеры сейчас быстрые, ядер много.
С базой же возникает понятная засада: если ключ в базе - это имя файла (пусть даже с каталогом), то возможны дубли ключей (если камера начала нумерацию файлов с нуля, а путь - сдублировался на карточке памяти). Если ключ - контрольная сумма от файла, то для показа превьюшки нужно считать весь RAW, а не только превьюшку из него.
С базой же возникает понятная засада:
Это понятно. Мне нравится(почти) как это реализовано в FastStone Image Viewer.
Логично имя файла с каталогом.
На этапе работы наплевать на дубли и дырки, размеры там мизерные. Хотя врядли дубли, скорее дырки...
Просто потом есть функция Оптимизировать базу которая и подчищает весь мусор. Которую сам пользователь запустит когда хочет.
>>>> компьютеры сейчас быстрые, ядер много.
Даже на быстрых чувствуется скорость работы с сохранёнными превьюшками.
FastStone показывает 'grid',
FastStone показывает 'grid', то есть одновременно нужно показать много (десятки)
А для показа strip - нужно показать одновременно - десяток (один). Это совсем другая история, этот десяток можно достаточно быстро прочитать (и декодировать).
Про дырки не понял.
Про дубли - теоретически, filename+дата достаточно хорошо. Практически - если камера ресетится (включая дату) при замене аккумулятора (у меня такая есть) - уже нехорошо.
Но приделать базу, потом, если скорость не будет устраивать - ну реально же несложно. Чуть сложнее будет, если сжимать в нее на лету, но и тут никакого рокет-сайенса нету.
Ну вот эксперименты с JPEG
Ну вот эксперименты с JPEG-ами, пока. Быстрый компьютер, но HDD.
Даже префетч не нужен, 56 превьюшек в окне - декодируются и показываются за комфортное время. Быстрее, чем я могу их отсмотреть и ткнуть в нужную. Это в 8 потоков, медленное место - HDD.
Сделать ЭТО быстрее, чем делает faststone оказалось совсем просто.
FastStone показывает 'grid'
Там если Выставить 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
Ну вот в теории, работу с HDD можно улучшить, убрав параллельные запросы.
На практике, в 2015-м году, даже заниматься этим не хочется. Потому что все уже.
На будущее.
Чего бы хотелось, но это похоже можно будет сделать после filmstrip'а
выбираем несколько файлов, и показываем их одновременно, зумим синхронно, синхронно перемещаемся по полю кадра.
Показываем с пикингом и без.
Это все для сравнения кадров....
Не в версии 1.x.
Не в версии 1.x.
Для одновременного показа нужно очень серьезно менять потроха программы. Вот такая вот выросла.
В очередной раз, прописывая 5
В очередной раз, прописывая 5-6 тегов в Bridge, плакал. Мышкой туда — мышкой сюда.
Поясни подробнее. Это ты про
Поясни подробнее. Это ты про keywords?
да. Там нельзя на них
да. Там нельзя на них шорткаты повесить. В результате оно очень мучительно (или сначала расставляем лейблы а потом их конвертируем в keywords, но лейбл может быть только один, так что тоже мучительно).
А у меня есть несколько ситуативных keywrods — ну типа people, cat, car, вот такое. Обычно частых в пределах 5-6, можно было бы повесить на шорткаты и расставлять быстро. А из-за того, что на клавиатуру их не повесить, надо тыкать мышкой в дерево keywords и потом обратно в filmstrip.
Если бы в FRV можно было такое настроить (с поддержкой иерархии и настроек про разделители и родителей как в Bridge) было бы очень круто.
В планах есть. Естественно, с
В планах есть. Естественно, с шорткатами. Когда, чего и сколько - посмотрим.
Относительно разделителей не понял, все что я видел в дикой природе выглядит так
- файлы экспорта-импорта keywords - разделитель табуляция
- в XMP есть два тега, в один все свалено кучей, во втором разделители - вертикальная палка.
UPD: увидел в бридже
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 - одно
Увы - один shortcut - одно действие. Плата за произвольные настройки этих самых шорткатов.
Предложение доработки
Алексей, а Вы планируете добавить в FRV функцию браузинга файлов? Мне ее очень не хватает, хотелось бы иметь возможность открывать папку с равками и видеть их превьюшки, чтобы выбрать нужную и открыть. А если бы в программу еще добавили функцию пакетного переименования файлов, то я бы смог полностью отказаться от использования Adobe Bridge.
Да, будет в следующем major
Filmstrip: будет в следующем major update. Собственно, у бета-тестеров уже есть :)
Batch-операции ("переместить все файлы с рейтингом 3 в каталог") - в планах.
Batch rename сложный (на основе EXIF-данных) - просят, но в планы пока не попало.
Про Filmstrip - отлично, буду
Про Filmstrip - отлично, буду ждать. А вот про групповое переименование - жаль, но буду надеяться на появление в более поздних версиях.
Вот я смотрю на бридж и чего
Вот я смотрю на бридж и чего-то тоскливо мне.
Делать как там - выглядит глупо и недоделано. К примеру:
- XMP-данные нельзя брать, рейтинги, метки, ключевые слова
- зато можно брать EXIF-метаданные, только вот выбор какой-то странный, вот Color profile есть (а он практически всегда будет untagged для raw), а (тупо) Camera make/model - нету.
Делать как-то правильно - нужно знать как, а я не понимаю т.к. никогда ничего батчем не переименовывал. Надо чтобы кто-то спроектировал эту фичу, оставив там 95% нужного и выкинув 80% ненужного.