Свежие комментарии

Ну я после твоего комментария тоже поменял. От греха.

Круть.

Попробовать не могу - счетчик попыток присылок пароля на сутки заклинен. Похоже, это и есть способ временного решения.

В новый пришло. Я в тот момент момент в новом был.

В том же и смысл получить код в свежесозданный аккаунт.

Я сделал как описано тут: http://habrahabr.ru/post/158545/#comment_5428333. Маркер пароля действительно пришёл в скайп.

В 13-м офисе Микрософт выпускает собственный граммер, в дополнение к "собственному" спеллеру.

Но спеллер-то был и есть у них на известной словарной базе, закупленной у отечественного производителя на корню.

А вот граммер Российского производства им покупать не сезон - ну и у них в русском пруфинг-паке, похоже, что-то сделанное индусами (тм), с многочисленными ухохотайками типа субжевой, только не в UI, а прямо в функционале.

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

Пока слышал только краем уха - но уже боюс-боюс. В частности - облом возможности подменить спеллер со своим словарем пользователя (обучение во всех словоформах же!) - блокирует для меня возможность перехода на 13-й офис. Останусь на 10-м.

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

Ну вот для изображения
Хорошо:
for(row=0...)
for(col=0..)
image[row*rowpitch+col] =...

А плохо, соответственно, если не подряд:
for(col=0..)
for(row=0...)
image[row*rowpitch+col] =...

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

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

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

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

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

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

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

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

В смысле системы команд - очень даже есть.
Во только что скачивал по нему референс, насладись: http://software.intel.com/sites/default/files/forum/278102/327364001en.pdf

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

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

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