Victor Tsaregorodtsev

2 mrgloom: Рядом бы для сравнения поместить картинку из статьи Хинтона в Сайнс 2006г (с той, с которой начался мировой бум deep learning). Чисто для спекуляции насчёт того, что алгоритм снижения размерности, явно не ставящий задачи минимизации внутриклассовых расстояний и максимизации межклассовых, - тоже отрабатывает на этой базе очень достойно.

>Задача получить из шумного облака точек (например семплы с кинекта) некую упорядоченную, более-менее стабильную структуру (модель распределения). SOINN? Она тоже построит сетку узлов. А шум (узлы, попавшие в области с малой плотностью распределения) - удалит. Я, правда, точно не помню самый начальный алгоритм (какую сетку/граф он строит) - но модификация ESOINN даст сетку с треугольными ячейками (может, кому-то для его задачи будет полезнее 3 соседа у нейрона в середине карты, чем 4, как в SOM с прямоугольными ячейками).

2 Nuzhny Результаты сравнения по скорости собирал 4-2 года назад (потом стало лень) на этой странице (смотреть от где-то от середины и все постскрипты). Сравнивал с пятью чужими программами (вернее, с опубликованными в печати или в интернете временами расчётов - исходник-то был доступен всего для одной из этих 5 программ). Сравнивал ориентировочно - с учётом прикидок о разнице в быстродействии моего и других процессоров. Исходников не открываю, демку где-то в те годы на сайте предложил сделать-дать только тому, кто придёт с тяжёлым проектом и гарантирует отдачу проекта в мои руки после того, как демка всё заявленное (как скорость, так и просто надёжность-работоспособность) продемонстрирует. По потреблению памяти - у меня на копейки больше, т.к. все данные обрабатываемого примера (именно одного текущего примера) и внутренние сигналы/веса сети оптимально раскладываются с учётом выравнивания блоков данных на границу параграфа. Ну и в коде 1.5 ноу-хау - одно чисто моё (на удивление - почему-то нигде и никем ранее не опубликованное) о самом шустром варианте распараллеливания обучения нейросети (вообще без синхронизаций потоков на уровне операционной системы), второе - об аппроксимированном вычислении нелинейности нейрона (которое опубликовано, но почему-то никто об этом не знает и на практике не применяет). И сейчас реализованы пара канонических вариантов свёрточных сеток (ЛеКуновский и Симардовский), а также другие её клоны (от Эндрю Нг, Свена Бенке) - вернее, из разных слоёв-кубиков можно собирать свой/новый вариант. Также у нейронов можно ставить полиномиальные сумматоры - не на всех слоях свёрточной сети это помогает/полезно, но если помогает - то точность растёт. Я так даже самого Хинтона опроверг - он в прошлом году говорил, что на задаче MNIST на обычном персептроне никто никогда не опустился ниже 1.6% ошибок, а я таки постановкой полиномиальных сумматоров только на вых.слой получил точность лучше (см последний абзац тут) (хотя сам Хинтон в 1986г в двухтомнике PDP описывал формулы обратного распространения ошибки в том числе и для полиномиальных сумматоров - но вот почему-то сам не пользуется сейчас сигма-пи нейронами в своих сетях, может быть, зря).

Наполовину реклама Думаю, что самый шустрый код для обычных процессоров - у меня, а для видеокарт (на CUDA) - у сотрудника российского филиала НВидии (это его хобби-проект). По крайней мере, код ОНейлла (по второй ссылке в теме) тормознее моего в сотню раз. Код нвидиевца тоже скорее всего будет гарантированно быстрее кода Алекса Крижевского (который писал прогу для Джеффри Хинтона) - из-за доступа к внутрифирменным секретам НВидии. Так что если кому нужен самый-самый шустряк - обращайтесь с конструктивными предложениями Ну и нерекламная часть: исходники проги Крижевского на С и Питоне лежат тут http://code.google.com/p/cuda-convnet/

Динамические ядра - это идущий из СССРовских времён синоним k-means Ну и переформулирую прошлый пост на ином языке. 1) У Вас есть N сэмплов 2) Кластеризуем их - получаем n кластеров, n<<N. Кластеризовать я советую онлайновым алгоритмом. 3) Для каждого кластера строим список из его нескольких ближайших соседей. Чтобы если при "боевой работе" придёт сэмпл с краю кластера - knn работал и с примерами соседнего кластера. Начинаем боевую работу 1) Приходит сэмпл - определяем, в какой кластер он попадает. Затрат - n вычислений длин векторов разностей. 2) Думаем - а не нужно ли взять какие-то соседние кластеры? Например, те, расстояние от сэмпла до центра которых сопоставимо с расстоянием от сэмпла до его кластера. В общем, тут можно придумать эмпирику, ради экономии вычислений берущую соседей только при достаточном удалении сэмпла от центра его кластера. 3) На сэмплах кластера (и, при необходимости, сэмплах его соседях) запускаем knn. Число примеров в этом одном или нескольких кластерах будет в разы меньше, чем N - во столько же раз и ускорится knn. Т.е. через пару-тройку десятков классификаций сэмплов - компенсируем время, затраченное на предварительную кластеризацию, и затем начинаем работать в плюс (по сравнению с постоянным запуском knn по всем N сэмплам)

>Так для того, чтобы визуализировать то, что находится в глубоком слое, надо пройти от него обратно к первому. > Берем карту коэффициентов, и собираем из образов предыдущего слоя картинку как в методе главных компонент. > Затем то же самое повторяем с предыдущими слоями. > В результате, каждая картинка будет иметь размер входного слоя. С опозданием на месяц кину ещё один вариант решения. Берём любой образ, на котором нужный нам "глубокий" нейрон стал победителем среди своих соседей (выдал наибольший сигнал). И начинаем решать обратную задачу - так менять входной образ, чтобы ещё больше максимизировать выходной сигнал данного глубокого нейрона с одновременным уменьшением сигналов его соседей. Т.е. задача обучения с учителем, эталонные коды (1 и -1 или 1 и 0 для нейронов) очевидны. Метод решения - обычный бэкпроп, только обучающий не веса сети, а значения входных сигналов. Т.е. если один глубокий нейрон реагирует на мужика, другой - на бабу, а на входе сети - картинка из камасутры, то "обучение" картинки может убрать с картинки ненужное (бабу или мужика), т.к. мы убираем то, на что реагировал другой нейрон (чья реакция нам не интересна)

>возможно ли делать как то поиск ближайших K соседей не загружая все семплы в память? Я бы сначала раскластеризовал (или заквантовал - если кластеров в данных нет) данные методом динамических ядер на достаточно большое число кластеров/квантов, а knn запускал только для того кластера, к которому относится точка, и для нескольких смежных кластеров. Если данных куча (сотни тысяч) - динамические ядра в онлайн-режиме коррекции за достаточно малое число итераций хорошо устаканиваются. Т.е. десяток-другой прокруток всей выборки (для кластеризации) - а потом работай внутри отдельных кластеров. Я бы для этого ещё и выборку переписал в другом порядке (сэмплы одного кластера идут друг за другом) - чтобы винт читал длинные последовательные блоки данных (кластеры целиком), а не бегал взад-вперёд то за одним, то за другим сэмплом

На английском - не называется. Это русская придумка (см нейрокнижку Жени Миркеса) Проверять результаты - так же, как пишут про LDA. У нейросетки-то целевая функция будет в виде двух макрослагаемых - суммы (по всем классам) сумм внутриклассовых расстояний (от точки до центральной проекции для её класса) и суммы межклассовых расстояний (между центрами проекций классов). Отнормировать все нужные слагаемые аккуратно (на число классов или на число точек в классе) - и управляйте нужным отношением ratio of interclass variance to intra-class variance через добавление ещё одного множителя-коэффициента (к какому-то одному из макрослагаемых).

mrgloom >еще цифры можно исказить рэндомно И нейросеть тоже можно исказить рэндомно См. препринт "Improving neural networks by preventing co-adaptation of feature detectors " Джеффри Хинтона сотоварищи. Правда, не знаю - насколько сильные ручные переделки библиотечного (OpenCV) нейросетевого кода для этого могут потребоваться.

kazanOpenCV был вроде такой алгоритм для задач трекинга объектов - но в полвторого ночи мой склероз отказывается вспоминать его название

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

От либы нужно только чтение и распаковка файла в память. Т.е. вся работа с библиотекой будет заключаться (в идеале) в единственной строке навроде: BYTE *RGBbuffer=ReadJPEGFile(filename,&width,&height); Я бы воспользовался привычным классом из поставки борландовской (ныне абракадабровской) среды разработки - но клиенту нужна переносимость на никсы и отсутствие любых лицензионных заморочек. Поэтому либе необходима кроссплатформенность и сырцы с гнушной лицензией. Ну и безпроблемная компилируемость компилятором gcc, в таком случае. Кто-нибудь может посоветовать вариант?

Спасибо. Не то, что хочется - но если не найду ничего иного... Хотелось именно чего-то простенького. А 3мб исходников - это для моего проекта как из пушки по воробьям.

У меня тоже 905. Брал чисто под монитор Самс204, за которым сижу до сих пор (20дюймовик классической пропорции 4:3 c разрешением 1600*1200 - узкоглазые мониторы мне неудобны). Но в ширпотребных (пусть и топовых) камерах прогресса нет уже года 2 как минимум - их матрицы по прежнему двухмегапиксельные (под разрешение FullHD), а более высокое разрешение достигается интерполяцией.

2 года не рыл ничего нового по вычитанию фона (background subtraction) - накопились вопросы. Буду рад, если кто-нить ответит. 1) Появилось ли что-нибудь существенно лучшее (по качеству работы), чем алгоритм Харвуда и Дэвиса с их тайландскими аспирантами? Имеется в виду статья 2005 года "Real-time foreground–background segmentation using codebook model". Этот алгоритм, насколько я знаю, реализован в OpenCV. 2) Насколько хорошо указанный алгоритм реализован в OpenCV? Каков макс. размер картинки при приемлемой частоте кадров (при условии работы на чистом процессоре, без GPU - для GPU его трудно адаптировать, как мне кажется)? А если довешивать всё необходимое (сглаживание контура или морф.фильтрацию) - какая скорость будет? 3) Есть ли практический смысл в этом алгоритме Харвуда-Дэвиса сотоварищи? Я его себе так и не реализовал - по итогам практического знакомства с другими алгоритмами мне показалось, что его фича (переменное число кодовых групп для каждого пиксела) актуальна только при мелкодетальном константном фоне (обои в мелкий рисунок на стене комнаты - как пример), а с изменениями освещённости заложенная в алгоритм адаптация всё равно справится недостаточно хорошо (тучки по небу так быстро бегают, что естественная освещённость меняется за 1-2-3 кадра - никакая адаптация не угонится), с меняющимся фоном - тоже будут проблемы. 4) Если появилось что-то лучше - то готов ли попробовавший делиться впечатлениями? Я, конечно, новую статью прочитаю и постараюсь найти-прочитать все работы, которые эту гипотетическую статью с новым алгоритмом цитируют - но там может быть описан другой практический опыт. Чем мне замотивировать попробовавшего - чтобы он поделился (на форуме или в привате) впечатлениями? 5) Что сейчас советует практический опыт насчёт стратегии построения вычиталки? Варианты (кидаю из головы): а) уменьшать полученный с камеры кадр, вычитать, восстанавливать выделенный контур обратно в исходное разрешение. Будем неточно ловить границы объекта - зато будет меньше проблем с шумом камеры. б) уменьшать кадр ради того, чтобы потом получше (или побыстрее) сработала морфологическая фильтрация для заливания дырок в выделенном объекте. в) возможные варианты в плане (или взамен) морфологической фильтрации? г) есть ли вычиталки, тянущие полный кадр 2мпикс-камеры? Актуально ли такое высокое разрешение для систем дополненной реальности? Или наплевать на все крутые камеры (тем более, что моя 2мпикс камера Лоджитек 905 с цейсовской оптикой всё равно страшно шумит) и не лезть выше 640*480? 6) Отличается ли по качеству кадра захват через VideoForWindows (старый и тормозной интерфейс) и через DirectShow? А то я может на свой Лоджитек зря ругаюсь (качество поганое только при использовании VideoForWindows, а с DirectShow всё будет хай класс?)? ЗЫ. Я всё в своих прошлых проектах писал сам (без всяких OpenCV) на С плюс Асм, т.е. поддержать разговор в плотной привязке к OpenCV не смогу. Поэтому и в общем разделе тема.

Ну и я немного скажу по нарытому. В общем, нашёл достаточно много интересного. На ряд вопросов, которые я задавал, можно дать такие ответы а) Codebook всё-таки смогли перенести на GPU (CUDA) и получить 12кратное ускорение. Но более простой алгоритм-предок (Horprasert et al, 2000) с одним "кодом на пиксел дал почти 100кратный прирост скорости на видяхе. б) ViBe (статья 2011 года) будет поточнее Codebook'а и побыстрее на обычном проце. И почти не теряет в качестве при переходе от цветного изображения к ч/б. Т.е. лично мне, наверно, стоит Codebook пропустить.

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

Погуглите GTSRB (соревнование german traffic sign recognition benchmark). Уже указанная тут статья Серманета и ЛеКуна - от людей, занявших в соревновании второе место (и в статье описавших дальнейшее улучшение точности распознавания). Также в инете есть и статья победителей. В общем, все лидеры использовали нейросетки (достаточно схожие между собой). Точность нейросеток оказалась лучше точности распознавания человеком. Т.е. если знак каким-то алгоритмом выделяется достаточно хорошо - то распознаваться затем он будет с почти 100% точностью (распознавалку можно будет сделать по описанным в статьях рецептам и натренировать на готовой базе).

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

Не, трекинг объектов (указанная Вами тема) и вычитание фона - вещи существенно разные. Поглядел - ревьюшки появились действительно только в последние годы (раньше кроме обзора Пиккарди в 2004г ничего не было). Ладно, буду читать сам.