Очередной “продукт” был навеян во-первых просмотром доктора Хауса, а во-вторых необходимостью сменить рингтон на мобильнике

Это родившийся за 15 минут коротенький ремикс на песню Teardrop от Massive Attack (это именно то, что играет во вступительных титрах к Хаусу). Сделано, как обычно, наспех в Reason.

Скачать mp3 - Агрессивный доктор Хаус

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

Итак, я надел очки и принял умный вид.

Искажение изображения - это применение к нему преобразования. Наиболее естественными выглядят преобразование типа масшабирования и сдвига:

x' = a1x + b1
y’ = a2y + b2


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

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

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

Во-вторых, функция должна быть ограничена на интервале, на котором мы ее применяем. Это естественное требование, нужное для того, чтобы не выскочить за границы изображения.

Почти хороший вариант - это синус. Он и гладкий, и ограниченный. Но вместе с тем он еще такой банальный, что тошнит.

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

1. На интересующем нас отрезке выбираются случайно N точек, в которых значение функции генерируется случайно в допустимом диапазоне
2. В промежуточных точках интервала [xi, xi+1] функция будет полиномом 3 степени Si(x) = aix3 + bix2 + cix + di
3. Условия непрерывности запишутся как Si(xi+1) = Si+1(xi+1) = yi+1
4. Условия гладкости и ограниченности я выбрал очень хитро: S'(xi) = S’(xi+1) = 0

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

А еще, простота этих условий дает возможность вычислить 4 коэффициента полинома для каждого интервала независимо! Четыре уравнения для определения 4 неизвестных:

S(xi) = yi
S(xi+1) = yi+1
S’(xi) = 0
S’(xi+1) = 0


Maple дает решение:

Теперь можно поглядеть, как будут выглядеть такие функции. Построим кривую по 4 точкам [2, 4], [6, 6], [8, 1], [12, -1]:

Получилась довольно замысловатая загогулина, которую просто так и не придумаешь.

Теперь я попробую применить такие кривые для искажения “капч”. Я сгенерирую 4 кривых и буду их использовать для вычисления масштабных и сдвиговых коэффициентов в уравнениях, с которых я начал вас грузить.

Получилось вот это:

Тот самый эффект развевающегося флага, к которому все привыкли!

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

P.S. Иногда картинка получается не очень искаженной. Происходит это из-за того, что иногда кривые получаются не очень кривыми. То есть опорные точки надо выбирать все-таки не совсем случайно, а из каких-то условий, обеспечивающих нужную кривизну… Но искать эти условия мне уже лень.

Первым делом было бы неплохо разобраться в вынесенных в заголовок словах.

Сэмплирование (sampling, дискретизация) - это такой процесс, во время которого в определенных точках пространства-времени (отсчетах) происходят измерения (samples, выборки) некоторой величины. Например, раз в день человек взвешивается на весах. Или несколько тысяч раз в секунду микрофон снимает амплитуду звука.

Квантование (quantization) - это прием, делающий из непрерывного (и, может быть, бесконечного) диапазона значений конечный набор интервалов.
Делается это обычно с тем, чтобы некоторое значение упаковать в некоторое количество бит. Например, можно квантовать расстояние интервалами по 1 см. И тогда в unsigned byte можно с уверенностью записать рост человека. Или разбить диапазон яркости от совсем черного до совсем белого на 256 уровней. Квантование может быть разным: равномерным, неравномерным, табличным, еще каким-то.

Дискретизация плюс квантование дают нам оцифровку. Например, сэмплируя 44100 раз в секунду и квантуя на 64K уровней амплитуду оцифровывается звук с качеством CD. Сэмплируя 300 раз на 1 дюйм и квантуя яркость на 256 уровней оцифровывается черно-белое изображение. Если последнее делать 25 раз в секунду и параллельно делать первое, то получится черно-белый фильм офигенного разрешения.

В результате оцифровки получаем цифровой сигнал - серию квантованых измерений.

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

Эти проблемы еще называют словом aliasing (элайзинг, алиасинг), или в простонародье “потеря качества”. В общем смысле, элайзинг означает наличие в воспроизведенном сигнале информации, которой в оригинальном сигнале не было. Это и мозаичное видео на DVD с 8 фильмами на одном диске, и металлическое звучание аудио, оцифрованного с низкой частотой дискретизации/битностью, и эффект муара при уменьшении картинок. И даже известный всем эффект, когда быстро вращающееся колесо кажется медленно крутящимся в обратную сторону - это тоже элайзинг, возникающий оттого, что наш мозг неправильно выбирает частоту сэмплирования при просмотре колеса.

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

Но есть и менее банальные примеры, которые не очевидны.

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

Например, это преобразование даст картинку, повернутую на 45 градусов и увеличенную примерно в 4 раза (по площади):

x' = (x - y) / 3
y' = (x + y) / 3

превращается в:

На преобразованном изображении явно заметен элайзинг - пикселизация. Почему?

Для вычисления цвета пикселя в итоговом изображении в точке (30, 20) я применил записанные выше уравнения и узнал, что надо взять цвет исходного изображения в точке (10/3, 50/3). Но поскольку никаких дробных частей от пикселя взять невозможно, я взял цвет в точке, которая получилсь при отбросе дробной части - (3, 16), внеся тем самым в итоговое изображение паразитную информацию.

А как же узнать, какой цвет сидит в точке (10/3, 50/3)?

Можно поступить так: увеличить исходное изображение в 100 раз и посмотреть, какой цвет сидит по координатам (33, 167). Так мы получим более аккуратное значение. Но увеличение изображения это опять-таки преобразование над ним, выглядещее как

x' = x / 10
y' = y / 10

И мы снова получаем ту же свинью: не зная цвета в точке (3/10, 3/10), я возьму цвет в точке (0, 0) и получу мозайку.

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

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

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

Например, если в точке 2 одномерный сигнал имеет значение 7, а в точке 3 - значение 5, тогда в точке 2.7 предполагаемое значение равно 0.3 * 7 + 0.7 * 5 = 5.6.

Изображение - это двумерный сигнал, поэтому для него надо применять билинейную фильтрацию, соответственно по четырем точкам. С ней изображение становится гораздо более ровным:

Такой фильтр еще называют triangle filter или cone filter. Кроме него существует масса других: квадратичный, кубический, фильтры основанные на распределении Гаусса, фильтры основанные на функции Sinc (Mitchell, Lanczos). Я нашел страничку, на которой собрано много фильтров с их графиками.

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

А теперь ответ на главный вопрос, ради чего я сел за эту статью: какая связь между фильтром и передискретизацией?

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

Ваня, понятно?

Скачать: Минусовку (mp3), MIDI, слова

Сегодня я закончил достаточно трудоемкую задачу - доделал jQuery-враппер в Lexa.Jsm.CoreLibrary. О том, что такое Lexa.Jsm, можно узнать из этой статьи.

Заодно накидал несложный пример и поместил его в Misc/jQueryDemo. В процессе его билдежки из C#-ного исходника App.cs получается вот такой милый скрипт:

app.js

JSM.ensureNamespace('jQueryDemo');

var _ = jQueryDemo.App = {
};

_.DomReady = function() {
  $(document.body).css({ margin: 0, padding: 0 });
  var div = $('<div></div>').text('Hey, it\'s fun to write jQuery code in C# :)').css({ background: 'orange', font: '16pt Tahoma', padding: '8px 16px' }).fadeIn(400).appendTo(document.body);
  var button = $('<input>');
  button.attr('type', 'button').val('Click here to hide orange bar').one('click', function(e) { return div.slideUp('slow', function() {
    button.attr('disabled', true);
    window.alert('No more orange bars!');
  }) });
  document.body.appendChild(button.get(0));
}

_.Run = function() {
  $(jQueryDemo.App.DomReady);
}

_ = JSM.registerType;
delete _;

По крайней мере, таким он получается сегодня. Кто знает, чего я натворю в Jsm-компиляторе в будущем

Кстати, обертка для jQuery снабжена документацией, а значит jQuery-код писать теперь гораздо легче. Взгляните:

Тут и intellisense, и подсказка по параметрам, и проверка синтаксиса и типов as you type, и Go to definition с Find all references. Писать приходится немножко больше, но происходит это теперь быстрее.

Еще есть несколько особенностей.

Во-первых, имеются некоторые названия, которых, строго говоря, в jQuery нету. Напрмер, jQuery.AjaxOptions или jQuery.AnimationOptions. Они облегчают написание кода и в то же время не создают дополнительного выхлопа, то есть компилируются в обычные JavaScript-объекты.

Во-вторых, вместо $(...) или $.each следует писать соответственно new jQuery(...) и jQuery.each, однако компилируется это в свои короткие аналоги.

В-третьих, в jQuery часто используется this внутри callback-функций. Совершенно понятно, что в C# никаких фокусов c this не бывает. Чтобы не потерять функционала, я ввел три дополнительных метода:

• DomElement jQuery.thisElement()
• T jQuery.thisObj<T>()
• jQuery jQuery.thisWrapper()

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

Теперь думаю, может показать это Резигу?

Выложил табу темы из Дживса и Вустера, как ее играю я.

Download: PDF, MIDI, GP5

Склоняюсь к тому, что изображен январь 1997 года. Новогодний интерьер органично дополняют: некий вариант спектрума, подключенный к телеку длинным шнуром (стелется по полу), магнитофон для записи и считывания программ (торчит внизу ближе к левому краю) и собственно я.

Кто в курсе, поймет всю тонкую ауру этой картины. Кто не в курсе, объяснять бесполезно

1. Del Shannon’s Runaway
2. Hello Dolly
3. Тема из Дживса и Вустера
4. Corcovado (Jobim)
5. Tears (Django)

Это потрепанная гитара, на которой я учился играть в 1998 году.

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

Нормального MIDP-клиента я не нашел. Под нормальным я понимаю клиент, который мог бы загружать фотки на twitpic или подобный сервис. Я нашел только Twim, но он имел проблемы с кодировкой и в самый нужный момент просто перестал работать.

Поэтому я решил написать клиент для себя, а заодно попробовать Java ME в принципе.

Проект лежит в открытом доступе на http://code.google.com/p/lexa-my-twitter/. Данная поделка умеет обновлять статус, загружать фотки с камеры на twitpic и читать friends timeline. В принципе, это все что нужно лично мне. Работа с камерой была заточена под Nokia (в частности, локатор capture://image вместо capture://video).

Впечатления от Java ME спорные. С одной стороны, прикольно написать программку для телефона. С другой - API бедновато. Нету очевидных вещей вроде url encode, base64 encode, не говоря уже об XML-парсерах. Разочаровала также не-кроссплатформенность API для камер.