FastRawViewer 1.3 Release Candidate 1

Никаких серьезных изменений относительно Беты-3 не произошло, поэтому у нас "анонс на мир":

FastRawViewer 1.3 (Release Candidate 1)

Там же, если присмотреться, можно найти ключик до 30 апреля (примерно, он на 45 дней от сегодня).

Будем благодарны за анонс в англоязычных (и прочих иностранноязычных) форумах, блогах и т.д., чем больше тестеров - тем лучше.

 

Comments

после выполнения rejected, в 90% случаев экран не обновляется полностью, а обновляется только область, где должно было бы появиться предупреждение (которое я кстати отключил).
http://www.picshare.ru/view/7199053/

А что за
- система (версия windows)
- видеокарта
- версия видеодрайвера
- видеорежим FRV (OpenGL/DX9/...?)

HP EliteDesk 800 G1 DM
http://www.picshare.ru/view/7202071/
Windows 7 serv.pack 1
видео встроенное
Видеорежим FRV был выставлен по умолчанию DX9, поставил OpenGL - глюки пропали.
Спасибо!

Intel HD Graphics - крайне советую обновлять драйвера на свежие (и почаще - там у интела в драйверах много приколов бывает)

В бете 2 (1?, 3?) там, где дерево каталогов:
если раскрываешь диск/папку, которая "последней строкой", оно разворачивается ниже области видимости - приходится прокручивать вниз вручную.

Не смертельно, но неудобно.

Альтернатива - это активный элемент, который ускакал из под мышки. Это как-то еще хуже.

Алексей, странная, вот, штука (да, опять я с гармонией в левом доке): настроены размеры filmstrim (сверху), folders (посредине), EXIF (внизу). Тыкаю Tab и наблюдаю, как постепенно, раз за разом, EXIF отжимает себе больше и больше места, пока остальные два не скукожатся до минимальных размеров.

Воспроизвел, но что делать - чего-то пока не знаю :(

Чудовищный какой-то закат солнца вручную, но справился.

Вот попробуйте обновленной гармонии: https://www.dropbox.com/s/71glpqj6i65rsfd/FastRawViewer-1.3.0.874-x64-Se...

Эммм... Ну... Теперь при каждом нажатии таба начинает самовольно съёживаться панель Folders. А вот если «палец залип» на табе — опять всё зохавывает EXIF. Мистика.

Если палец залип - то да.
Потому что там размеры EXIF пере-устанавливаются по 200ms-таймеру и если палец залип - то будет всякое.

"самовольно съеживаться" - напомните, что у вас в левой колонке живет.

Filmstrip, Folders, Exif. Порядок неважен, в принципе, в медленном режиме нажимания таба Filmstrip отжимает место у Folders. Когда залип — отжимать у всех начинает EXIF.

Ага, я filmstrip и folders (или только folders) такое же решение пропишу.

Но на залипший Tab оно не рассчитано (ну таймаут поставлю не 200ms, а 50, но смысл не изменится)

Folders тоже зафиксировали: https://www.dropbox.com/s/prgbzzhb1keegw5/FastRawViewer-1.3.0.875-x64-Se...
Остальные, кроме Filmstrip, и так fixed size (гистограмма - если в доке).

Но на залипший Tab это никак не рассчитано. Там эта гребаная анимация появления окон, от которой, судя по всему, все и сбивается. Не частите, давайте прорисоваться. Если дожидаетесь полной прорисовки, то все ок.

А API для программной установки размеров есть только в Qt 5.6, который мы еще полгода использовать не будем.

Во, теперь всё стоит.

Так выпьем же за ту силу, которая держала полотенце!

Спасибо за багрепорт!

А вот мне тут попал в руки файлик (http://danandsherree.com/upload/2004/12/DSCN6875.NEF), который CMYG. А FRV кажет каналы как-то по своему, не по порядку: GMCY. Это ожидаемо?
By the way, классные цвета с него выходят. Не знаю, чем оно грозит, но цвета красивые.

А что значит "по порядку"?
Вот есть байеровский квадратик, 2x2. Я могу придумать минимум три способа его нумерации: по часовой, против часовой, по строчкам. Какой из них "единственно верный" - я не знаю.

Не, не так сказал. Он их внизу показывает как RGB (как четвёртый отдельно включить — не знаю). Это раз.
При запуске (судя по цвету гистограммы) зелёного канала нам показывают ну ни разу не зелёный. Или оно сначала CMYG->RGB, а потом уже показывает? Но всё равно, не логично.

Оно, конечно, CMYG->RGB, потому что как на мониторе CMYG показать?

Каналы выглядят правильно. Если включить поканальный баланс, то прибавление G - зеленит, M - маджентит ну и так далее.

На rawsamples.ch есть более человечный сампл с E5700 (где есть, хотя бы, околонейтральная стена) - по нему видно что все ну как-то осмысленно.

И, да, нижние RGB (и BW) - это, конечно, работа с уже рендереным представлением, а не с исходным.

А, то есть я хотел функционал RD от FRV, получается? Потому что к RD никаких вопросов не возникло.

Просто цвет гистограммы тогда смущает, раз мы показываем уже конверсию, то может гистограмму оставлять полноцветной? Чтобы не возникало впечатления, что «щас играет канал магента», когда нам показывают вообще синий.

Гистограмма - RAW (там даже это написано на заголовке гистограммы)
Поканальные представления - по рендереному с наложенным всем (бб, экспокоррекция, контраст) - это написано в мануале.

отоварился по случаю 4К LCD -> нельзя ли дать опцию увеличения ширины вертикальных скроллбаров... а то больно сложно попасть мышкой...

N/A

А зачем туда попадать мышкой, колесо же?

> А зачем туда попадать мышкой, колесо же?

тогда можно спросить зачем они вообще нужны на экране - ибо их с трудом видно Ё-)...

а нужны они затем что все-таки визуальные ощущения при прокрутке тьмы thumbnail'ов в GRID MODE например колесом (с настройкой чтобы мало крутилось за раз) и плавным перемещением захваченным скроллбаром разные, скроллбаром бывает приятнее и плавнее... у меня и в FireFox'е add-on стоит NewScrollbars (aka NoiaScrollbars) для жирных и толстых скроллбаров...

N/A

N/A

Ну уговорили, будет вам tunable.
Я подозревал, что там есть внутренние проблемы - но вроде нет.

Нужно ли шире (выше) 50px (извините, но в пикселях оно проще оказалось)?

>> тогда можно спросить зачем они вообще нужны на экране
Чтобы обозначить возможность прокрутки.

Я (тоже на 4k дисплее) - сделав tunable тут же укрутил его в минимум (6px)

https://www.dropbox.com/s/71glpqj6i65rsfd/FastRawViewer-1.3.0.874-x64-Se...

ScrollBarsWidth/Height в регистри. В пикселях.

душевно... поставил 30 пикселей и все стало на свои места.

N/A

Win10х64 = а нет ли какой засады если из FRV запускается не родной executable (условно говоря ".exe"), a командный файл ( условно говоря ".bat" )

N/A

Я запускал cmd - запускается.

запускается, но нет ли засады с передачей внутрь параметеров... например есть что-то типа (строка внутри файла)

@ "C:\Program Files\Phase One\Capture One 9\nircmdc.exe" exec hide "C:\Program Files\Phase One\Capture One 9\CaptureOne.exe" %1

PS: nircmdc если что к C1 не относится, я ее просто там держу

N/A

собственно там еще строки типа

@ "C:\Program Files\Phase One\Capture One 9\nircmdc.exe" win activate title "C1"
@ "C:\Program Files\Phase One\Capture One 9\nircmdc.exe" win max title "C1"

вот они отрабатываются нормально похоже по функциональности

почему вопрос - вот из xnview этот командный файл отрабатывает как надо и в C1 нужный raw выбирается для работы внутри C1.... а из frv - нет

N/A

А на надо ли %1 в кавычки в такой ситуации?

Я то простейшую вещь делал:
dcraw [параметры] %*
(не то чтобы мне надо было - но спросили, я и проверил)
В такой ситуации все передавалось (я подозреваю, что на %* система расставляет кавычки сама)

aaa... похоже дело в том что FRV блокирует доступ к файлу... если запуская xnview мы видим что C1 имеет доступ к файлу "сразу", до запуская абсолютно то же самое из FRV надо сидеть и ждать... и он таки появится но прямо скажем это занимает неприятно долгое кол-во времени ?

N/A

> запуская xnview

запуская _ИЗ_ xnview

N/A

причем это происходит в самом начале (запустил FRV, потом первый раз открыл что-то в C1), потом все быстро....

N/A

Не зачитывает ли C1 долго каталог, например?

> Не зачитывает ли C1 долго каталог, например?

уже зачитала давно - из XnView все тоже самое, на тех же файлах быстро - это скорее всего FRV зачитывая что-то блокирует

N/A

кстати о : program startup -> last opened file

непонятно почему это обязательно должно быть как обязательный заход при запуске в просмотр этого файла ? мб я хочу в GRID MODE но с этим файлом выбранным там... иначе некий конфликт с установками interface -> grid/filmstip... если я enable grid mode + start in grid mode + program startup -> last opened file

N/A

Открытие файла, независимо от способа открытия (Menu - File - Open, Drop, Menu - File - Recent files, вспоминание при старте, передача в командной строке) - это всегда Single view.

Собственно last opened file - это Menu - File - Recent files - верхний в списке.

Но, действительно, конфликт.

Т.е. при установке last opened file - нужно галку в Grid снимать (и запрещать). Но снимать ее на невидимой закладке - неправильно, юзер не увидит.

Вменяемого решения я не вижу пока, поэтому пока забьем.

Ну у меня вот какая гипотеза таки
- C1 таки вычитывает каталог целиком и щупает там файлы.
- а FRV, прочитав текущий файл, делает префетчи в разные стороны (в зависимости от фазы луны) - и блокирует (RO) не текущий файл, а следующие.

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

Собственно вот.

Проверка
а) или выключить префетч (Number of .. RAW decode threads в Performance), ну полностью не выключится, ну хоть до 1 сократить
б) или поразвлекаться в фолдере со строго одним файлом, там префетча нет т.к. нечего.

завтра посмотрю, спасибо

N/A

На момент, когда "красная рамка" погасла - файл разблокирован, инфа 100%.
Он разблокируется раньше на самом деле, но эта фаза никак не обозначена интерфейсно.

Есть еще префетчи, да, но они не касаются текущего файла.

Вообще, собственно на момент отрисовки (в режиме single view) - файл разблокирован. Ну там "плюс-минус", потому что как там сообщения между тредами ходят - некоторый (негарантированный) вопрос.

ну ладно - это более менее терпимая проблема... просто вот первый запуск C1 из свежеотрытого FRV имел разительный временной контраст по сравнению с тем же из xnview или запуском PS/ACR из FRV... т.е. если никаких лишних блокировок frv не делает то и аллах с ним... хотя зачем frv вообще что-то блокирует если он raw ничего не пишет ? во избежание что этот файл находится в процессе записи чем-то (например копируется, итд) ?

N/A

FRV особо не задумывается "зачем он блокирует", std::filestream блокирует при RO-открытии - и прекрасно.

Происходит это, по всей видимости, оттого, что в Win32/CreateFile в sharemode передается 0, отчего там эксклюзивный лок (что-то у меня оно не трейсится туда, но и никаких способов передать SHARE_READ я чего-то не вижу).

Но, как в том преферансном анекдоте, "и так неплохо получается", потому что не дадут, к примеру, файл увести в процессе чтения (а в OS X не дадут другим механизмом - там если файл к примеру стерло, он на самом деле сотрется только после его закрытия всеми процессами)

Там ссылка на скачивание "Mac OS X 10.6-10.10" а не "Mac OS X 10.6-10.11"

Спасибо!

Копипаста правит миром.

Add new comment