RawDigger 0.9.13 RC3

lexa - 12/Ноя/2012 15:40
Попрошенные вчера вечером изменения оказались настолько небольшими, что я их взял и сделал.

Хочется надеяться, что "релиз" 0.9.13 от этой версии будет отличаться только названием версии:

Изменения:
  • Убраны всплывающие информационные окошки (при чтении файла и т.п.), теперь эти тексты выводятся в нижней строке окна.
  • При достижении пределов по "Next file"/"Prev file" - программа (противно) пищит и сообщает о проблеме в нижней статусной строке.
  • Опция 'Multi-core/Multi-CPU processing' - ликвидирована, как и было обещано. Многопоточность включается сама при количестве CPU/ядер более одного.
  • Актуализирован мануал.

Comments

Алекс Скилл - 12/Ноя/2012 18:16

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

Эх, а у меня вдруг ещё одна просьба небольшая возникла. Раз уж сейчас есть горячие кнопки для масштабирования изображения "ctrl +" и "ctrl -", то почему бы не добавить и стандартное сочетание "ctrl 0" для "Fit to Window"?
Ведь эта функция уже есть, только опять же до неё очень неудобно добираться в нижнем выпадающем списке с масштабами.

lexa - 12/Ноя/2012 18:22

Fit to window - Ctrl-F (и она доступна еще и через меню View, а в меню все хоткеи подписаны)

Алекс Скилл - 12/Ноя/2012 18:37

Точно, есть такая штука. :) Жаль, что не очень удобно перепрыгивать из одной области клавиатуры от "ctrl +","ctrl -" к "ctrl F". В Photoshop на зря Fit to Window повесили на "ctrl 0" ;)

Если уж продолжать тему клавиатурных фотошопных ассоциаций, то можно было бы ещё и включить такие комбинации кнопок как
"ctrl 1" - масштаб на 100%
"ctrl 2" - переключить отображение в RGB render
"ctrl 3" - включить для отображения канал R
"ctrl 4" - включить для отображения канал G
"ctrl 5" - включить для отображения канал B
и в продолжение уже исключительно для RawDigger
"ctrl 6" - включить для отображения канал G2

Вроде бы не сложно должно быть, зато очень облегчит юзабилити продвинутым пользователям RawDigger.

lexa - 12/Ноя/2012 18:54

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

Kickerua - 13/Ноя/2012 13:36

Мимо, да.

Алекс Скилл - 12/Ноя/2012 19:21

Есть ещё идея, но более сложная в реализации, однако, может оказаться полезной и для фотографов и для исследователей raw.

Можно добавить в окошко с информацией о "пересветах" ещё один столбик статистических данных. Показать для каждого из каналов сколько "запаса" в EV остаётся на каналах.

Например:
R +1.9
G +1
B +1.5
G2 +1

lexa - 12/Ноя/2012 19:32

К сожалению, реальные максимумы всех ~400 камер (+ комбинации с ISO) - неизвестны мне.

Алекс Скилл - 12/Ноя/2012 19:48

А как сейчас определяется крайний предел для "пересвета"? Судя по всему по гистограмме, когда справа появляется большое количество пикселов с одинаковыми значениями. Вот это значение и можно принимать за реальный максимум данной камеры с данным ISO.

То есть можно поставить определение максимума на автомат, пользователю достаточно лишь раз открыть файл с пересветами и данные о модели камеры (название, серийный номер, iso и предельное значение в каналах) попадают во внутреннюю базу данных (это может быть даже обычный текстовый файл, не думаю, что он у кого-то разрастётся более чем на 400 строк, исходя из количества понимаемых RawDigger камер). И теперь, при открытии нового файла с той же камеры, можно легко вычислять сколько ещё осталось запаса до насыщения в каждом канале.

Так же можно дать возможность вручную вносить поправки в значения из этой базы данных.

lexa - 12/Ноя/2012 19:57

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

А идею хранить всякие возможные сочетания (камеры-firmware-ISO) я с негодованием отвергаю

Алекс Скилл - 12/Ноя/2012 20:16

>> - если у нас гистограмма с пиком, то запаса в светах уже нет
Зато мы уже знаем, где этот пик находится. Остаётся только запомнить это значение.

>> - а если без пика, то где будет пик - неизвестно.
Неизвестно, если не запоминать результаты предыдущих опытов с файлами от этой камеры.

>> А идею хранить всякие возможные сочетания (камеры-firmware-ISO) я с негодованием отвергаю
А чем это пугает? База данных будет локальная и информация из неё в интернет выкладываться не будет. Да и чего бояться, что в текстовом файле записано название камеры, серийный номер (на худой конец, можно его и не писать) и ещё какие-то результаты анализа raw-файлов от этой камеры?

lexa - 12/Ноя/2012 22:42

Пока нет желания городить новую сущность.

Kickerua - 13/Ноя/2012 13:36

Мне идея нравится.
Я бы для камеры сам прописал бы значение насыщения, если что.

lexa - 13/Ноя/2012 14:09

Ну я даже не знаю.

Ну вот я для своей камеры максимум знаю примерно (~14k с хреном, точно не помню, да и от ISO зависит).
Ну вот по статистике я вижу, к примеру, максимум данных в 10000. С необходимой точностью (см. ниже) я и на глазок вижу, что это на полстопа ниже макисмума.

Проблема в другом: что это за максимум? Это один пиксель или много пикселов с примерно таким значением или что? Ответ на это - виден на гистограмме, а не на статистике "самый яркий пиксель на k стопов ниже насыщения".
А на гистограмме - надо считать не относительно максимума (который, впрочем, допустим мы и так знаем), а относительно среднего тона. Который задается/запоминается в настройках гистограммы.

Это не говоря о том, что один hot pixel (в котором *всегда* максимум, или только на высоких ISO) предлагаемую индикацию сделает полностью бесполезной.

Т.е. индикация должна быть какой-то другой, ну там "медиана по верхним 0.1% пикселов" или что-то в этом духе.

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

blacklion - 13/Ноя/2012 14:06

Опция 'Multi-core/Multi-CPU processing' - ликвидирована, как и было обещано. Многопоточность включается сама при количестве CPU/ядер более одного.

Злобно. А если у меня тут три виртуалки и я не хочу больше 1го процессора RawDigger'у отдавать?

lexa - 13/Ноя/2012 14:10

То загони его в еще одну виртуалку с одним виртуальным CPU.

Вот фотошопу ты как CPU ограничиваешь?

blacklion - 13/Ноя/2012 14:13

У меня фотошоп, кстати, больше 2-х ни разу не жрал. А вот всякие Hugin'ы -- только в путь

lexa - 13/Ноя/2012 14:20

RD процессор особо не жрет, в отличие от билдов панорамы.
Т.е. это несколько секунд CPU time на картинку, грубо говоря. На это время виртуалки подвинутся.
А толку - много.

lexa - 13/Ноя/2012 14:29
Фотошоповский find edges на большом файле: Т.е. это не 100%, но в пике больше 80 (8 CPU = 4 core X hyperthreading)

blacklion - 13/Ноя/2012 16:57

Вот ни разу этот фильтр не требовался :)
Хотя, PhotoKit sharpener вроде его использует, да.

lexa - 13/Ноя/2012 18:08

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