19 заметок с тегом

html5

Работа с камерой и распознавание чисел в «Опере»

Распозновалка (43.68КиБ)

Я вчера заморочился на отличненько. Мне показалось скучным и грустным вводить цифры счёта за квартиру в окошко «Госуслуг» и решил сделать автоматическую распознавалку чисел, попутно изучив работу с камерой из браузера.

Доступ к камере — эксперментальный стандарт, поэтому мало кто из браузеров может им похвастаться, я использовал специальный билд «Opera-Labs-Camera», который можно взять с сайта снапшотов «Оперы». Работать мой пример, соответственно, будет только там.

АПИ оказалось несложным. Всё, что нужно сделать — соединить специальным образом тег VIDEO с источником стримового видео; потом я 10 раз в секунд забираю кадр с видео и кладу в CANVAS (на скриншоте он цветной), оттуда вырезаю небольшую область, перевожу в градации серого, беру за порог 75% от усреднённого цвета и перевожу всё в ч/б.

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

В итоге, лучше всех распознаёт следующий алгоритм.

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

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

На скриншоте в большом текстовом поле записаны получившиеся комбинации. Первое — номер по порядку, далее (через двоеточие) — количество переходов по вертикали и потом описанная последовательность. Например, «ноль» записывается как «2:11» (два перехода по вертикали, потом одинаковые переходы по разу слева и справа разделительной линии).

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

Черновики у меня в комментариях

Мне тут хочется пару проектов на PHP доделать, а я что-то давненько, порядка полугода, на нём не программировал вообще. Всё больше Пайтон и Google Go. Поэтому я взялся внести несколько изменений в движок своего сайта, которые давно руки чесались сделать.

В том числе сделал то, что давно просили — черновики в комментариях. Работает только в современных браузерах — IE 8.0+, FF 3.5+, Safari 4.0+, Chrome 4.0+, Opera 10.5+, а так же iOS 2.0+ и Андроид 2.0+. Только такой список, так как сохранение происходит в localStorage.

localStorage — это клиентская база данных «ключ и значение», которые есть сейчас уже во всех распространённых браузерах. Преимущество хранения черновиков именно в ней — черновик сохраняется вне зависимости от того рухнул сервер или нет, ведь localStorage сохраняет данные на диске клиента.

Кстати, я делал библиотеку эмуляции localStorage для IE 6 и 7 (используется behavior userData), но у себя использовать не буду, ни к чему поощрять некрофилию.

Работает всё следующим образом (детально можно посмотреть в исходниках любой страницы с комментариями): когда пользователь делает паузу в наборе комментария, мой JS вызывает localStorage.setItem, где ключём является URL страницы плюс имя поля (у меня их три — имя пользователя, сам комментарий и кому этот комментарий был адресова).

После отправки комментария в теле полученной страницы приходят вызовы localStorage.removeItem, которые удаляют сохранённые значения.

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

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

Код, с использованием JQuery, получился вот такой:

// globalStorage — это для FF 2.0, но я не уверен, что это правда работает
var storage = window.localStorage || window.globalStorage && window.globalStorage[location.hostname] || null;

if (storage) {
    var savedraft = function s() {
         if (s.hnd) {
             clearTimeout(s.hnd);
         }
        	
         var o = $(this);
        	
         s.hnd = setTimeout(function() {
             try { // если не хватит места, будет исключение
                 var prefix = location.pathname + '#';
                 storage.setItem(prefix + o.attr('name'), o.val());
                 storage.setItem(prefix + '?', +new Date()); // сохраняю время, возможно в будущем буду подчищать старые черновики
             } catch (o) {}
        }, 500);
    }
    
    // каждый элемент, который надо сохранять, имеет класс draft	
    $.each($('.draft'), function(_, value) {
        var o = $(value),
              key = location.pathname + '#' + o.attr('name'),
              v = storage.getItem(key);

    if (savedsuccessfully) { // внешний флаг, что черновик больше не нужен — всё сохранено на сервере		
                  storage.removeItem(key);
              } else if (v !== null) {
                  o.val(v);
              }
              o.keypress(savedraft).change(savedraft);
        })
    }

localStorage не резиновое, у разных браузеров значения различаются, но в целом, там около 5МБ на домен, да и диск пользователя забивать жалко. Поэтому я сохраняю время записи, возможно когда-нибудь буду вычищать очень уж старые черновики.

localStorage для Internet Explorer 6 и 7

Написал небольшой класс в JavaScript для поддержки API localStorage в IE 6 и 7. localStorage — это браузерное хранилище key-value. Эмулируются setItem, getItem, removeItem, key, clear и length (для хранения использует behavior userData).

Доступ к значениям как к свойствам класса не реализован. Прежде всего потому, что в JS в этих версиях IE нет сеттеров и геттеров, а для того, чтобы воспользоваться onpropertychange мой объект надо поместить в DOM, что порождает массу гемороя, типа присутствия свойств из DOM, а не из хранилища.

Так же я не сделал события onstorage и onstoragecommit, потому что не придумал для чего это нужно (а второе корректно реализовать вообще нельзя).

Ещё не реализовал нестандартное, но полезное расширение remainingSpace, потому что в общем случае нельзя сказать сколько места ещё осталось в userData, так как квота зависит от зоны сайта (доверенная, интранет и так далее).

С большой вероятностью эта зона, конечно же, «интернет» (то есть квота 1МБ), но квоты localStorage сильно отличаются по механизму от userData, у последнего две квоты — на документ (в зоне «интернет» это 128КБ) и на домен (упомянутый мегабайт). Вполне может случится, что квота «на документ» ещё не исчерпана, а доменная уже да.

Зато я реализовал exception, который бросается в том случае, если IE говорит, что квота исчерпана.

В общем, основные вещи есть. Пример использования:

// .-~*´¨¯¨`*·~-.¸ тут подключаем библиотеку ,.-~*´¨¯¨`*·~-.¸
// записываем два значения
try {
    localStorage.setItem('key1', 'myvalue1');
    localStorage.setItem('key2', 'myvalue2');
} catch (e) {
    if (e.description == 'QUOTA_EXCEEDED_ERR') {
        alert('Нет места');
    } else {
        alert('Что-то не так, не знаю что.');
    }
}

// смотрим значение по ключу «key1»
alert(localStorage.getItem('key1'));
// смотрим первое значение (по номеру), нумерация с нуля
alert(localStorage.key(0));

// удаляем значение по ключу «key1»
alert(localStorage.removeItem('key1'));

// смотрим сколько ключей осталось
alert(localStorage.length);

// очищаем хранилище полностью
alert(localStorage.clear());

Ограничения на localStorage

localStorage — key-value браузерное хранилище, в котором веб-приложение может сохранять свои данные сколько угодно долго. Я рассказывал о нём в книге «Реактивные веб-сайты». По стандарту рекомендуется выделять для каждого приложения (т. е. хоста) пять мегабайт.

Но не всё так просто:

Last time I’ve checked, Chrome 5.0.375.99 beta let me save 2600-2700 thousands of characters, Firefox 3.5.9 — 5200-5300k, Explorer 8 — 4900-5000k, and Opera 10.60 popped a dialog, letting me give the script unlimited storage.

Причём, я ещё заметил, что браузеры с разной скоростью выделяют место под хранилище. Некоторые («Опера», например, выделяет его за время O(1)), другие заметно замедляются с ростом размера выделяемой памяти.

Добавлено позднее: кстати. У объекта localStorage есть несколько методов, в тот же самый объект отображаются, как свойства, пары ключ/значение. В любом браузере, кроме FF, можно запросто перезаписать любой из методов этого объекта. Только FF предусмотрительно не позволяет этого делать. Жаль только, что он не позволяет этого делать молча, не выбрасывая exception.

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

rel=«noreferrer»

Как известно, около года назад в WebKit появилась поддержка атрибута «rel» у ссылки со значением «noreferrer». Если указать это значение, то браузер не будет передавать заголовок «referer», в котором указано с какого адреса браузер осуществил переход.

Это прекрасная вещь, которая позволяет защищать, к примеру, информацию из интранета. У нас (в «Яндексе») стоят специальные скрипты для скрытия заголовка «referer» специальными ухищрениями, чтобы предотвратить утечку (так как некоторые сервисы у нас с ЧПУ) данных. Этот атрибут, если он был бы реализован везде, решил бы эту задачу более изящно.

К сожалению, с его распространением, думаю, будет расти его параноидальное использование, что сильно повлияет на статистику. Сейчас можно быть до какой-то степени уверенным, что если «referer» не выставлен, то человек пришёл из закладок в браузере или набрал адрес руками, скоро такое предположить будет неверно. Так же было удобно по тому же заголовку искать обсуждения своих статей (впрочем, я уже довольно давно делаю это, подписавшись на RSS сформированного мной запроса к «Яндекс.Блогам»).

Ну и ещё один показатель бардака — HTTP-заголовок называется «referer», а значение атрибута — «noreferrer».

P.S. Возможно поддержка «noreferrer» и ещё где-то реализована, я не интересовался.

Motion JPEG или о чём я говорил

Некоторые ребята почему-то подумали, что я предлагаю M-JPEG как универсальный формат видео в вебе. Ничего такого я не имел ввиду. Вероятно, я написал как-то слишком туманно.

Я лишь хотел обратить внимание на два факта:

  • на бардак, когда формат видео не поддерживается тегом VIDEO ни в одном браузере, но поддерживается браузерами
  • на то, что говорить «в браузерах нет единого формата видео» некорректно
    И только.

Бардак: Motion JPEG (M-JPEG) и тег VIDEO

С утра, складывая носковый пасьянс (не сошёлся, три (!!!) разных носка) — жена постирала чёрное, я задумался о формате M-JPEG. Если коротко, это формат видео, каждый кадр которого — JPEG. Очень простой формат, достаточно распространённый и его поддерживают основные браузеры — «Firefox», «Сафари», «Хром», «Опера», не поддерживает только Internet Explorer (даже девятый).

M-JPEG (51.09КиБ)

Таким образом, вопреки всем разговорам, у нас уже есть единый потоковый видеоформат, de facto, причём есть давно. Правда, плохенький (напоминаю — каждый кадр целый JPEG) и проигрываемый немного по-разному (обредший нового адепта «Хром», тормозит меньше всех). Впрочем, чтобы как-то обелить формат, у него есть и достоинства — каждый стоп-кадр у него довольно качественный, потому M-JPEG любят в камерах охраны.

Бардак заключается в том, что тег VIDEO не поддерживает формат Motion JPEG ни в одном из браузеров. Это многое говорит о том как производители браузеров определяют вектор развития их детища. В погоне за модой забывают наводить порядок и править баги (красный круглый камень в дырочкой в чей-то огород).

Воспроизводится M-JPEG через тег IMG, я даже небольшой пример накидал за 15 минут (нажмите круглую блямбу справа внизу картинки для воспроизведения).

При помощи тега CANVAS, M-JPEG и метода «stop» у окна можно даже сделать плеер, плохой, но работоспособный. Я попробовал, но результат мне не понравился. В частности, потому что тег IMG не умеет управлять видеопотоком, стоп-кадр нужно делать при помощи CANVAS, а сделать его можно только после остановки видеопотока (метод «stop» у окна нам в этом поможет) и плеер между остановкой видео и появлением стоп-кадра секунду не показывает ничего.

Можно, кстати, вспоминить, что Internet Explorer с какой-то бородатой версии поддерживает DYNSRC у тега IMG, причём там-то этот тег имеет богатое API для управления видео, в котором есть всё, что сделать полноценный плеер.

Ещё более кстати, что этот плеер будет поддерживать видео в формате AVI и кодеки установленные в системе, так что если у вас в системе есть кодек для M-JPEG, можно просто гнать видео в этом контейнере, IE его должен понять. То есть, можно и Internet Explorer обучить понимать Motion JPEG.

Canvas в IE9 будет

Ну что, AMD действительно тогда проговорилась, никакой ошибки нет — в IE9 будет CANVAS. Только что появился Internet Explorer 9 Platform Preview 3 и там есть CANVAS.

Должен сказать, скорость очень хорошая. Реализовано пока не всё (это всё-таки даже не альфа), но для работы многих демок и игрушек хватает. Правда на синтетических тестах результаты противоречивые. Я сравнивал с последней сборкой «Оперы» 10.60, где-то IE9 впереди, где-то «Опера» сильно обгоняет.

Кажется, с применением полупрозрачности (и тени) производительность IE9PP3 пока резко падает.

Из других новостей: AUDIO, VIDEO, CANVAS с аппаратным ускорением, увеличена производительность и улучшена его поддержка JavaScript, поддержка WOFF (формат шрифтов), ACID3 — 83%, HTML5 test — 84/300 (предыдущий результат — 32).

Unicode со «школотой» по-прежнему рисует квадратиками.

2010   canvas   html5   ie   ie9   программирование

HTML5 test

Автор теста HTML5 обновил свой тест, теперь максимальное количество очков, которое может набрать браузер — 300, а не 160. Кроме того, теперь поддержка браузером кодеков для тегов VIDEO/AUDIO не влияет на основные очки, а даёт бонусные. Это правильно, так как стандартном HTML5 кодек так и не выбран.

Результаты по браузерам выглядят так:

«Сафари» 5 — 208 (ночная сборка — 220) «Хром» 5 — 197 (ночная сборка — 217) FireFox 3.6 — 139 (ночная сборка — 176) «Опера» 10.50 — 129 (10.60a 3422 — 159) Internet Explorer 8 — 27 (IE9PP2 — 32)

То есть лидером, по результатам этого теста, является пока пятый «Сафари», при этом тот же пятый «Сафари» под Windows набирает только 165 очков.

«Опера» — ещё больше вещей из HTML5

Пока я тут ною, что «Опера» не поддерживает CSS1 в полном объёме, новый билд «Оперы» (10.60а build 3419) стал поддерживать кодек WebM для тега VIDEO (у которого есть все шансы стать стандартом), HTML5 offline web applications, Geolocation API (что давно было известно), Web Workers и Cross-Document Messaging.

Круто, ребята, очень круто. Но сделайте поддержку CSS1 уже наконец.

Ранее Ctrl + ↓