FastRawViewer 1.4-beta

от:Alex Tutubalin

Иногда в метаданных есть указание "где вендор камеры считает, что начинается изображение", чаще - нету и приходится резать по вкусу.

В случае DNG, этих указаний даже два, Active Area и Default Crop. При этом адобовские тулзы используют всегда Default Crop (он уже), FRV - Active Area (пока), последние версии диггера - настраиваются.

Подробнее

Не нашёл в Диггере, где... Если точнее, там, где речь именно про кроп, то я поставил галку - и диггер перестал узнавать/ принимать файлы DNG. Версия 1.2.19. Снял -и снова всё пошло как надо...

от:Alex Tutubalin


Большого смысла во вьюере резать по DefaultCrop (он всегда не шире ActiveArea) - ну лично я не вижу. Наоборот, полезно показать все, а если юзерский конвертор режет лишнего - ну конвертор можно и сменить, если в тех краевых 10 пикселах (это при печати 300dpi - ~1 миллиметр на отпечатке) содержится что-то крайне сюжетно важное.

Конверторы усугубляют картину: демозаике нужен разбег на краю, кому 2 пиксела, а кому и 8 или 16. Дальше можно на краю посчитать упрощенную демозаику, а можно обрезать и единства "как правильно" - не наблюдается.

Подробнее

Смотрелка на мой взгляд должна показывать DefaultCrop, конечно лучше как настраивамый вариант, полностью, ActiveArea или DefaultCrop и может даже с заданием размеров вручную. Исключительно чтобы был выбор на случай чудесатого конвертера, который берёт размеры с потолка, как например, raw - терапия, которая считает, что моя камера имеет матрицу 5528х3688.
Итого, мы уже имеем следующие размеры:
5546х3714
5546х3696
5536х3696
5528х3688
5472х3648
Лично меня интересует только последний размер, потому что так считает родной для камеры конвертер ACR. Но, в случае стыковки с Терапией, было бы интересней иметь в просмотре именно её размерчик. Правда, опять же неизвестно, сколько она режет сверху/ слева, а сколько снизу/ справа, что там симметрия - это не следует из данных.
И -да, гистограмма и всё, что имеет отношение к прочим данным из raw, должна бы быть строго в рамках того размера, который относится к картинке, всё лишнее будет только давать искажения данных, как мне кажется... Как пример, зелёная полоска внизу с моего raw-а не должна входить в гистограмму как пересвет в зелёном канале, если размер будет типа DefaultCrop.
Естественно, возможность альтернативы в настройках - хорошая традиция, поэтому и предыдущий вариант должен иметь место быть...

Мы обсуждаем, даже вот в самом жестком случае (терапия) - 1%. А вообще - меньше.

С учетом того, что разные конверторы режут таки по разному - единственный правильный ответ тут - давать поконфигурировать пользователю. Записал, если будет хотя бы 10 желающих - сделаем. Пока - вы один.

от:Alex Tutubalin
Мы обсуждаем, даже вот в самом жестком случае (терапия) - 1%. А вообще - меньше.

С учетом того, что разные конверторы режут таки по разному - единственный правильный ответ тут - давать поконфигурировать пользователю. Записал, если будет хотя бы 10 желающих - сделаем. Пока - вы один.

Подробнее

Где ж набрать столько "желающих"... Большинство вообще не обратит внимания, что там вылезло на краю... Но, раз уж смотрелка позиционируется как точная - то точность должна быть безупречна в любом случае, как мне кажется.
PS И дело тут не в процентах, а как раз в том, что это на краю и малозаметно, можно лопухнуться, не подрезав вовремя это безобразие.

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

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

Это такое же бесполезное упражнение, как точный подсчет пересвеченных пикселей (или точное задание границы для отсечки) - типичная точность замера экспозиции порядка 1/6EV и точнее просто не надо.

Единственный практический аргумент - это не точность подсчёта как таковая, а возможность ошибки в определении границ растяжения гистограммы, когда краевые пиксели, которые на самом деле не пришей, не пристегни, могут оказаться фиктивной границей пересветов/ недосветов.
Больше практического смысла я не вижу. То есть, скорее всего его просто нет, потому что дневные снимки этих зелёных полосок не имеют. Странно это всё, видимо, действительно не стоит заморачиваться.

Из каких соображений сделано следующее:
1.встаем в дерево папок, листаем по папкам, встаем на папку с файлами, справа видим грид из картинок в выбранной папке
2. листаем картинки в выбранной папке, нажимаем Enter, грид меняется на Filmstrim внизу и выбранной картинкой вверху, листаем. Двигаемся также и по папкам в дереве папок стрелками - все отлично.
3. теперь жмем G, чтобы смотреть в гриде. Если нажать стрелку вниз, он вместо позиционирования на следующей картинке, переходит на следующую папку по дереву папок. А если нажать стрелку вправо, то начнется листание в выбранной папке. И вот теперь мы закончили просмотр в текущей папке. А как вернуться назад в дерево папок ? Без мыши выйти в дерево папок невозможно.
Нужно что-то типа Backspace, как в проводнике виндовс, а также нарисовать в гриде и фильмстрипе кнопку возврата к выбору папок перед начальным файлом.

Кнопку (горячую клавишу) "передать фокус на фолдеры" - обдумаем.

Кнопка (для мыши) в Grid/Filmstrip - явно не нужна, тыкайте мышью прямо в фолдеры.

[quote "Кнопку (горячую клавишу) "передать фокус на фолдеры" - обдумаем.][/quote]

Обдумали и сделали. И не только на фолдеры

https://blog.lexa.ru/2017/05/18/fastrawviewer_142_beta.html

Спасибо, то что надо.

Не помешало бы:

1. Из дерева папок - Reveal in в Explorer/Finder
2. Просмотр tif.
3. Просмотр видеофайлов (не сочтите за ересь, но прочий софт делает)

от: gennadiy_100772
Не помешало бы:

1. Из дерева папок - Reveal in в Explorer/Finder
2. Просмотр tif.
3. Просмотр видеофайлов (не сочтите за ересь, но прочий софт делает)

1 - ну вероятно, да.
2 - в планах на 1.5
3 - не в планах и вряд-ли будет в них (желания повторять VLC/MPC ну как-то никакого нет, а без этого - ну зачем оно?)

2+ еще psd, пожалуйста.

PSD - превьюшку же, рендерить все слои не надо? Тогда да.
И TIFF - если есть превьюшка, то ее?

То есть задача, как я ее понимаю - навигация, а не просмотр 100% результата рендеринга слоев?

а превьюшка, она полноразмерная там? тогда да.

В случае PSD - какую превьюшку записали, такая и есть.

Рендерить (многогигабайтный) PSD - всяко не будем в ближайших версиях.

от: gennadiy_100772
Не помешало бы:

1. Из дерева папок - Reveal in в Explorer/Finder

https://blog.lexa.ru/2017/06/02/fastrawviewer_143_1135.html

очень жду

от: Alex Tutubalin

3 - не в планах и вряд-ли будет в них (желания повторять VLC/MPC ну как-то никакого нет, а без этого - ну зачем оно?)

MPC конечно не нужно, а просто простейший предпросмотр, как в проводнике виндовс и просмотре acdsee. Хочется избавиться от всех этих сторонних браузеров на компе.

от: gennadiy_100772
MPC конечно не нужно, а просто простейший предпросмотр, как в проводнике виндовс и просмотре acdsee. Хочется избавиться от всех этих сторонних браузеров на компе.

У нас еще масса идей по основной задаче, работе с RAW.

А у пользователей - масса других идей, кому редактирование JPEG, кому просмотр видео.

С пользовательскими идеями мы обходимся следующим образом
- если реализовать просто (как вот с shortcut-ами на переход в панель)
- либо если запрос массовый (десятки людей просят)
То мы делаем.

Если же реализовывать дорого, либо запрос не массовый, либо вообще не наше дело (как мы видим назначение программы) - то пишем в хвост TODO, где оно и остается надолго т.к. голова TODO пополняется быстрее.

Вот видео - пошло именно в такой хвост. Попросит много человек - имеет шансы подняться повыше.

Такие дела.

Работа с рав понятно - основное.
А что в планах на ближайшие релизы интересного будет?