» FastStone Image Viewer

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
Ищем параметры 1252, 1253, 1254, 1255 и меняем их значения на c_1251.nls.

Ваш совет помог. Спасибо! А в реестре я назад всё поправлю пожалуй.

Sp1y0n
в том то и дело, та замена вроде как еще для Win XP была худо-бедно актуальна, а во времена Win7-Win10 не помню, чтобы этим приходилось пользовался

На Windows 10 у портативной версии регулярно спадает ассоциации с файлами jpg и png. Как-то можно исправить?

Подскажите, в программе как-то можно ставить рейтинг и цветовую метку на фотографии?

Mosl
Настройки>Миниатюры>Разрешить пометку файлов
Появится кнопка на панели "Показывать только помеченные файлы".

inile нет это не то.
Я имел ввиду поставить рейтинг в звездах от 1 до 5 и цветовые метки как LR.
Эта программа очень быстро и качественно отображает RAW файлы, я бы хотел сделать их первоначальный отбор в FastStone, но для это мне надо система рейтингов.

Цитата:

Эта программа очень быстро и качественно отображает RAW файлы

Заблуждаемся.....
Она быстро показывает превью из RAW.
Как только включаешь опцию реально показывать RAW, быстродействие катастрофически проседает.

IMHO
В настоящий момент только 1 Viewer - FastRawViewer
Реально быстро показывает RAW.
Там и рейтинги там и звёзды, там и ....

У меня следующий воркфлов.(может дело привычки, пока в FRV не появился фильмстрип, ща переучиваться надо)
В FastStone Image Viewer в превью режиме за первый проход удаляю явный шлак.
Потом в настройках на HotKey вешаю вызов FRV и уже в нём более детально работаю с оставшимся материалом. Или более детально рассматриваю картинку.
Он может генерить xmp файлы которые можно импортироват в LR.( я правда с этим не ковырялся)

Цитата:

В настоящий момент только 1 Viewer - FastRawViewer

Она стоит денег, а взломанной не нашел.

На форуме была тема, но похоже после сбоя погибла, тоже не могу найти.
[more=Был релиз..]
LibRaw.FastRawViewer.DX9.v1.1.4.707.for.Windows-BEAN
LibRaw.FastRawViewer.DX9.v1.1.4.707.for.Windows.x64-BEAN
LibRaw.FastRawViewer.OpenGL.v1.1.4.707.for.Windows-BEAN
LibRaw.FastRawViewer.OpenGL.v1.1.4.707.for.Windows.x64-BEAN
[/more]

DVall
Если у вас осталась программа, поделитесь пожалуйста.

[more=Нету..]
В гугле находит LibRaw.FastRawViewer Windows-BEAN
Текст
[/more]

Mosl

См. ПМ

Mosl
На Персии есть и новее версия.

arturrc
Новее только х64

Pasha_ZZZ
LibRaw.FastRawViewer.v1.2.0.719.for.Windows-BEAN
LibRaw.FastRawViewer.v1.2.0.719.for.Windows.x64-BEAN
LibRaw.FastRawViewer.v1.2.0.719.for.MacOSX-BEAN
Извиняюсь за

Спасибо всем кто откликнулся.
В теме "Запросы на взлом программ" создал запрос на версию 1.2.4.742, может помогут.
http://forum.ru-board.com/topic.cgi?forum=55&topic=11525&start=5460#13

DVall

Цитата:

Она быстро показывает превью из RAW.
Как только включаешь опцию реально показывать RAW, быстродействие катастрофически проседает

А какой смысл показывать реальные RAW? Превью вполне достаточно для оценки кадра. Иной раз достаточно просто вытащить эти превью (что я обычно делаю при помощи dcraw -e *.cr2).

В любом случае, для обработки понадобится что-то более мощное, чем вьювер.

Что касается быстродействия... неплохо бы автору сабжа пересобрать критические участки более продвинутым компилятором (например, Intel C++) с поддержкой всех векторных расширений. Или хотя бы выпустить 64-разрядную версию, в которой SSE2 используется по умолчанию. Это даст существенный прирост скорости. Может быть, отпишу ему. Или отпишите сами - чем больше народу попросит, тем больше вероятность, что он прислушается.

Вот вам картинка, наглядно показывающая разницу в скорости декодирования JPEG, с применением векторных команд, и без оных. Два верхних декодера их используют.



Из моего опыта, некоторые алгоритмы дают восьмикратный прирост производительности при использовании обычного набора SSE2, я уж не говорю про AVX/AVX2 и распараллеливание.

Цитата:

А какой смысл показывать реальные RAW? Превью вполне достаточно для оценки кадра.

Мне недостаточно. По превью отлавливается только явный шлак...
Превью с 24 мп. ощущение что всё мыло(с 14 было ещё нормально).
В камерах явно ресайз идёт по быстрому алгоритму.

DVall
Думаю, что это от камеры зависит. У моей 20 Мп, и никакого мыла на превью нет, если его нет в оригинале.

Да и зачем анализировать превью когда можно на большой скорости смотреть реальные кадры.

Цитата:

У моей 20 Мп, и никакого мыла на превью нет

С трудом верится, ну явно же при таком ресайзе будет большая потеря информации.
Может ещё от монитора зависит?(NEC 2490WUXi2)

DVall
У меня в качестве основного монитора почти такой же (Dell U2412M).

Качество ресайза еще зависит от типа матрицы. У меня был аппарат с 18 Мп - разница в превью с 20 Мп ощущается. И от настроек джипега в камере зависит, например от уровня резкости. По крайней мере, на Кэнонах к встроенному в RAW джипегу применяются настройки камеры (цветовые стили, резкость и т.д.)

Поднять быстродействие сабжу всё равно не помешало бы. Интерфейс там, насколько я понимаю, написан на Delphi, декодеры - скомпилированы обычным Visual C++ без векторных расширений. В разы ускорится время декодирования, если использовать всю мощь современных процессоров.

Краткое исследование.
24 Мп RAW 6024x4024
Превью 1616x1080
Размер файла 500K
Если его же пересохранить с качеством 100% получаем ~800K.
Явно идут потери на ресайзе, и артефакты jpg сжатия.
Я снимаю в RAW, без jpg.
Вполне возможно на соньках при съёмке в RAW никакие улучшайзеры к превью не применяются.

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

DVall
У меня - 20 Мп RAW 5472x3648 (23 Мб). Превью такого же разрешения, размер встроенного в RAW джипега (выдернул при помощи dcraw -e) - 2,3 Мб.

Faststone при сохранении показывает качество оригинала - 80%.

Думаю, что дело тут в разрешении. Моя камера не делает ресайз, отсюда и разница.

Цитата:

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

Цитата:

если использовать всю мощь современных процессоров.

вот из за таких советов, софт под x86 жирнее носорога стал. Вся мощь современных процессоров, вот так глупо в тепловую энергию и просирается. Говнокомпилятор от штеуда, даёт прирост только в егошных процессорах , которые он в настоящий момент производит, и только в писькомерных тестах. а амд процессоры сразу в жопе окажутся. к тому же использование в качестве оптимизаций дурного нашпиговывания бинарника скалярными и векторными инструкциями, вместо грамотных ручных ассемблерных оптимизаций и качественных алгоритмов, отвалит программу на процах которые эти инструкции неподдерживают или поддерживают плохо. ну а на core i7 и так перемолится быстро, даже если привык везде с секундомером сидеть.

Цитата:

кол-во снимков в серии

Вполне может быть определяющим фактором, при 12к/с на превью наплевать....

sergEO7905

sergEO7905
Цитата:

Говнокомпилятор от штеуда, даёт прирост только в егошных процессорах , которые он в настоящий момент производит, и только в писькомерных тестах. а амд процессоры сразу в жопе окажутся.

Какой же ламерский это бред, просто жуть.
Главные производители комнатных обогревателей (они же шмамд) давно поддерживают и SSE различных версий, и AVX и (продолжить самостоятельно)...
А если бы вы знали на самом деле, что это такое - то тупостей про оптимизации взамен SSE/AVX не говорили бы.

Цитата:

А если бы вы знали на самом деле, что это такое - то тупостей про оптимизации взамен SSE/AVX не говорили бы.

считайте что хотите, я не собираюсь оправдаваться. результат на лицо., никакой реальной оптимизации давно нигде нет, а софт становится всё жирнее и неповоротливее.
Цитата:

(они же шмамд) давно поддерживают и SSE различных версий, и AVX и (продолжить самостоятельно)...

то что бульдозеры поддерживают, совершенно незначит то что оно там нормально работает. к тому же у превидущего покаления K10 этих фуфлыжных avx нет, а этих процов включая 6 ядерных у населения навалом в работе, и никто ничего менять несобиерается. к тому же даже обычного ia32 для быстрой отработки фото должно хватать, при чём потенциал расширять можно ещё очень долго. а вешать всё на ключи оптимизации дуракомпилятора, и соответственно насиловать этим блоки и костыли вокруг ALU, должно быть стыдно, так как это лень страшная.

sergEO7905
Цитата:

блоки и костыли вокруг ALU

ALU занимается целочисленными операциями, а для потоковых и векторных - фактически не предназначен. И если бы интерполяция и лосси-сжатие базировались бы на целых числах - то оно бы и помогло.
И т.к. нужный вариант ЕХЕшника/ДЛЛки получается изменением пары ключей комстроки - можно было бы:
а) сделать несколько вариантов сабжа с разными ключами;
б) сделать несколько вариантов процедур.
Но вы ведь такой идеалист и хотите, чтобы один ЕХЕ работал и на 286, и на и7. И что вы, что вы, и так ведь целых 7(!!!) метров весит! А вдруг после таких вариантов вырастет, аж до 10-12(!!!!!!), это ж при нынешних гигабайтах ни в какие ворота просто не лезет!