БК-0010 старца

[Fouras]

Такая очень сырая идея.

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


Ведь это же можно обобщить на пространство любой размерности. Причем сделать так, чтобы один кластер притягивался, а разные расталкивались. И тем самым генерить распределение значений для вариационного GAN. А я собираюсь делать вариационные ганы.

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

[Fouras]

Первое разложение картинки на 32 фичи 5x5

Самое забавное, что задача чисто математически ровно та же самая, которую пытался решить каноник при типировании по анкетам:

Дано... наверное можно назвать многообразие, но я в математике не силен, могу ошибиться в термине. Скажем так, у нас картинка состоит из большого количества пикселов (у меня 42 000), но надо учесть окрестность вокруг каждого с радиусом 2.

И надо составить библиотеку из 32 фрагментов 5x5 (их называют фичами), чтобы при линейном отображении на картинку получилось максимально близкое к исходному.

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

Это же типирование по анкете: надо подобрать 32 типа, чтобы оттипировать любого человека с учетом акцентов.

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

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

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

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

[Fouras]

В общем случае задача линейного разложения нерешаема с удовлетворительной точностью. Из линий линейными преобразованиями не сделать круг, как из букв П, Ж, О и А не составить слово Вечность. Надо делать какое-то разложение, по типу гармонического ряда. В принципе, возможно разложение на любые отогональные функции, и даже неортогональные. Либо делать нелинейную зависимость. Нелинейная зависимость в моем случае не катит, у меня потом будет пулинг, поиск самых сильных фич. То есть, надо увеличивать базис и делать смесь гармоник.

[Fouras]

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

Большинство фич стали монохромными и начинают собирать все варианты поворота и отзеркаливания, что логично.

Не хватает ортогонализации фич. Не понимаю, почему до сих пор остаются прямые и негативные варианты, один другое не вытесняет.

Надо все-таки смешивать несколько фич в одной. Очень не хочется на первом слое делать фильтр 3x3, но возможно придется, если я не добьюсь идеального восстановления с 5x5.

Надо сравнивать не среднеквадратичное отклонение по RGB, а яркость по RGB, и цветность с меньшей точностью. Возможно, придется в другом цветовом пространстве решать, а это нежелательно: RGB линейно, а а всякие VHS не линейны.

[Fouras]

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

После сортировки видно, что фич не полный набор с учетом поворотов. Особенно странными выглядят цветные. Я ничего не разделял, алгоритм сам создал черно-белые и сплиты с дополнительными цветами.

[Fouras]

Фичи сделал круглыми. Теперь рецептивная область сохранилась как у 5x5, но качество выросло, поскольку площадь меньше, причем за счет периферийных пикселов.

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

Фичи выглядят теперь как освещенные шарики, что очень даже логично: объёмную освещенную картинку мы собираем из выпуклостей и вогнутостей.

Почему не хочу 3x3. Для обычных фотографий фильтры 3x3 мало что дают, там обычно что-то содержится мало отличимое от шума. Я же собираюсь с первого же слоя собирать осмысленную информацию. А начиная с 3-го слоя уже будут 3x3.

[Fouras]

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

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

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

Пример конкуренции:


Здесь на нижнем уровне дельфинчики, а на более высоком обнимающаяся пара. Обычно побеждает пара, сверху вниз.

А тут наоборот: чаще побеждает Эйнштейн, который в более высоких гармониках.



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

[Fouras]

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

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

Надо будет на карточке считать, слава богу шэйдеры я уже освоил. Большая фотка уже минут 10 считается и только 2%. Зато уже прикидочное восстановление практически идеально.

[Буран]

Fouras, мне нужен твой совет.

Есть фотки, на которых камни. Много камней разного размера, сваленных в кучу. Щебёнка, короче говоря. Как ты думаешь, можно свёрточной нейросетью оценить средний размер камней? А ещё лучше - их распределение по размеру? Полный график распределения не нужен, достаточно информации, скажем, о проценте камней меньше 2 см и больше 4 см в диаметре.

И какова для этого должна быть ширина окошка (ну, этот квадратик, пробегающий по картинке)? Наверно, если мы оцениваем процент камней больше 4 см в диаметре, достаточно ширины, соответствующей этим самым 4 см?

[Fouras]

Fouras, мне нужен твой совет.

Есть фотки, на которых камни. Много камней разного размера, сваленных в кучу. Щебёнка, короче говоря. Как ты думаешь, можно свёрточной нейросетью оценить средний размер камней? А ещё лучше - их распределение по размеру? Полный график распределения не нужен, достаточно информации, скажем, о проценте камней меньше 2 см и больше 4 см в диаметре.

И какова для этого должна быть ширина окошка (ну, этот квадратик, пробегающий по картинке)? Наверно, если мы оцениваем процент камней больше 4 см в диаметре, достаточно ширины, соответствующей этим самым 4 см?

Задача идеальная для нейросетей. Умеренная ответственность: никто не умрет немедленно и не остановится на сутки банковская сеть. Данные однородные.

Для таких задач используют предобученную нейросеть, например VGG16. Можно взять и больше, VGG19, и больше, но в данном случае никакой разницы не будет. Все настоятельно и твердо рекомендуют использовать именно предобученные сверточные части. Их учат месяцами на миллионах картинок, и уверяю, что ты не сделаешь лучше.

Процесс взятия предобученной нейросети называют трансфер леарнинг.

Spoiler: показать

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

Масштаб можно получить из положения камеры и и ее параметров, но это проблема. Сегодня эта камера на каждом углу продается, а завтра такую только на озоне бу по тройной цене. Еще важно откуда получаем: это стационарная камера над траспортером, в месте свала, на приемном пункте, или это фотки мобильниками с точек. Я бы настоятельно посоветовал, чтобы в кадре была мерная линейка: либо нивелирная рейка, либо распечатанный в стандартном масштабе бар-код. Бар код хорошо опознается нейросетями, если будет pdf для печати на А4, то можно просто листок положить рядом и фоткать. Без мерных маркеров сеть не узнает, поскольку чудес не бывает. Избыточность нейросети потребуется для распознания масштаба по бар-коду.

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

Spoiler: показать

Аугментация бывает и как дополнительный слой, и как утилита для фотографий.

Откуда получить стартовые данные. Первое: максимальное количество фоток в реальных условиях с разным освещением. Хорошо бы вообще фильмы в 2К с максимальным битрейтом.

Второе: возможность искусственной генерации. Уж камни несложно нагенерить. Можно генерить карту высот, и сделать элементарную модель освещения по Ламберту. Это в зависимости от опыта работы от часа до нескольких дней, если совсем далек от темы и не въезжаешь. Текстуры с нужными распределениями вставлять в фотки по маске реальных фот.

Архитектура очевидно такая:
вход: необучаемая, но предобученная CNN скачанная с гитхаба. Скорее всего VGG16 - она мощна, хорошая и достаточно быстра для домашних компов.
потом полносвязанный слой с выходом без нелинейности, где каждый выход: вероятность встреть камень такого размера. То есть, на выходе эквалайзер. 3х слоёв полносвязанной сети более чем достаточно: больше слоёв будут просто хуже обучаться.

[Буран]

О, спасибо!

С масштабом проблем нет: камера находится в фиксированной позиции относительно камней, расстояния известны.

С освещённостью сложнее. Съёмка может быть и днём, когда солнышко светит, и в пасмурную погоду, и в темноте - тогда включается искусственное освещение (кажется, фонари по бокам).

Буду думать, где брать данные для обучения. Задача не самая приоритетная, время есть.

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

[Fouras]

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



Кстати, фотка с соционической сходки. Самый правый - Беглый Чайник. В центре Мамонтов, организатор соционических мафий, ну и парочку справа возможно кто-нибудь знает. Хотя здесь они еще не парочка, а сейчас они уже не парочка.

[/ru/]

Fouras,
Sorry, если не в той теме.

Нужен совет, как лучше написать на C++ предобработку данных.

Хочу сравнить скорость на data.table из R и чистой на C++ . Скорее всего на чистом C++ будет раза в 2 быстрее.
Там хорошо организованы вставки на Сях, по моему можно попробовать.

Нужно текстовые данные перевести в цифровые или буквенные индексы.

В скрипт поступает слово, нужно сматчить соответствие ему (полное) из первой колонки таблицы и выдать значение из второй колонки. 30 - 50 млн. строк.

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

[Fouras]

Зависит от размеров таблицы. Если действительно нужна скорость, то скорее всего никакого stl, кроме std::vector. Все в институте учили про то логарифмический поиск set, map. Так вот, практически всегда на реальных примерах линейный поиск в векторе обгоняет. Кто считает иначе, тот руками не сравнивал. Когда не обгоняет, делают бинарный поиск поиск в сортированном векторе. Если надо быстрее, делают поиск строки в дереве, когда все строки хранятся подряд в едином векторе. Задача поиска в таком дереве минимизировать 1) кэшпромахи обращения по памяти 2) не начинать поиск с начала слова, а продолжать сравнивать следующую букву в дереве. Для этого пишут свой поиск.

Для больших данных вводят хэшфункции. Можно хэшлист заюзать, но я его лично не замерял, скорее всего в угоду универсальности он недостаточно эффективен (диванная аналитика детектед). Хэшфункцию надо выбрать такую, чтобы была без таблиц как в crc, учитывала знакоместо и была достаточно проста для быстрого вычисления. То есть, MD5 не пойдет. А вот что-то на неприводимом многочлене на поле Голуа в самый раз. В МИФИ даже один чувак защитил кандидатскую на эту тему. Хотя он там шульмовал, в целом нормальный подход. Идея: как следует перемешать биты и сделать чтобы каждый бит зависел от остальных. Многочлен Жегалкина в самый раз. И/или сеть Хопфилда. Если словарь фиксированный, то константы хэшфункции можно подобрать чтобы минимизировать хэш-промахи. Мне доставляло большое удовольствие писать такие переборные программы, которые подбирали последовательными приближениями лучшие коэффициенты. Это прикольно.

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

Если таблицы еще больше, то для предварительного отсечения используется фильтр Блума.

[/ru/]

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

Данные - это обычные слова - char s[30].
Более сложные алгоритмы пока не потяну.