Код в квадрате?

mandigit

Есть квадрат 4x4, каждая клетка может принять значение 0/1.
Положение квадрата в пространстве неопределено, например
0100
0010
1111
0000

кодирует то-же число, что и (повернуто на 90 град)
0100
0101
0110
0100

можно предположить, что таким образом можно закодировать более 2^14 чисел
(исходя из того, что каждое закодированное число приводит к не более, чем 4 запрещенным числам)

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

Digit

Посмотри в сторону QCode - Dead с его помощью маяки маркировал.
Или я не о том? :oops:

mandigit

Digit писал(а):

Посмотри в сторону QCode - Dead с его помощью маяки маркировал.
Или я не о том? :oops:

Оно самое, только хочется эффективнее использовать имеющуюся информацию!
QCod'ом в квадрате 4x4 не закодируешь 2^14 чисел.

=DeaD=

2mandigit: Думаю вопрос решается, но очень проблемно, у меня всего на 2 бита от теории сокращает количество информации, зато всё тривиально работает, а тебе нужно именно эти 2 бита выжать? Надо без этого будет строить какие-то классы, которые надо будет быстро опозновать, а это серьезные затраты времени, растущие с размером матрицы, мне так кажется. Ну может 1 бит можно без таких проблем отжать... даже могу сказать как - шифропоследовательность 001х, он тогда оно становится уязвимым к 1-кратному отражению.

mandigit

=DeaD= писал(а):

Думаю вопрос решается, но очень проблемно, у меня всего на 2 бита от теории сокращает количество информации, зато всё тривиально работает, а тебе нужно именно эти 2 бита выжать?

Ну, пока стоимость этого отжима видится очень дорогой :cry:

Но, вдруг, кто-то хорошо знакомый с арифметикой полиномов найдет простое решение.
Суть-то вот в чем:
матрица датчика 16x16, что-бы определить такую метку нужно разрешение в два раза больше, чем единичный элемент метки, а с учетом случайного положения метки нужно площадь охватывать, как два размера метки.
Получается, что информацию надо упаковать в квадрат 4x4, что составляет 16 бит
Если убрать 2 бита, получится что можно в таком коде зашифровать положение x=0..127, y=0..127
А если убрать 4 бита то только 0..63

В первом случае площадка при размере метки 1.28x1.28м
во втором 0.64x0.64

zubr

=DeaD= писал(а):

2mandigit: Думаю вопрос решается, но очень проблемно, у меня всего на 2 бита от теории сокращает количество информации, зато всё тривиально работает, а тебе нужно именно эти 2 бита выжать? Надо без этого будет строить какие-то классы, которые надо будет быстро опозновать, а это серьезные затраты времени, растущие с размером матрицы, мне так кажется. Ну может 1 бит можно без таких проблем отжать... даже могу сказать как - шифропоследовательность 001х, он тогда оно становится уязвимым к 1-кратному отражению.

За либу респект

А если у вас во внешнем черном квадрате одну точку белой сделать? Например ближайшую к угловой.
Будет метка после этого корректно определяться?

Код:

            int isGood=0;
 
            //Проверим на то, что по периметру центрального квадрата маяка размером 7х7 идут черные клетки, иначе ошибка
            for(int i=0; i<K; i++){
              if( res[0][i]==0 )  { isGood++; }; // считаем белые точки в черном контуре
              if( res[K-1][i]==0 ){ isGood++; };
              if( res[i][0]==0 )  { isGood++; };
              if( res[i][K-1]==0 ){ isGood++; };
            };
            isGood = (isGood > 1) ? 0 : 1; // разрешим одну белую точку

Если это работает и CV находит черный контур, то этой точки достаточно чтобы определить поворот или отражение.

=DeaD=

mandigit писал(а):

Если убрать 2 бита, получится что можно в таком коде зашифровать положение x=0..127, y=0..127
А если убрать 4 бита то только 0..63

Есть тупой метод, но он достаточно слабый по производительности, хотя смотря сколько у нас флэша под это дело отвести, если даём 2N байт флэша под служебные таблицы, тогда скорость распознавания маяка будет порядка 2^16/(2*N), то есть если 1Кбайт под служебные таблицы отдадим, тогда скорость будет порядка 64 операций достаточно сложных. В принципе терпимо на 8МГц-ах то... Надо такой метод?

Добавлено спустя 1 минуту 18 секунд:

zubr писал(а):

А если у вас во внешнем черном квадрате одну точку белой сделать? Например ближайшую к угловой.
Будет метка после этого корректно определяться?

Если это работает и CV находит черный контур, то этой точки достаточно чтобы определить поворот или отражение.

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

nest

может, прошвырнуться по известным типам штрих кодов ?

=DeaD=

nest писал(а):

может, прошвырнуться по известным типам штрих кодов ?

Вопрос в том, что известные штрих-коды не надо локализовывать (где они на кадре), а тут есть такие грабли

Больше всего похожи на то что нужно QR-коды - их сотиком можно распознавать, но надо сотик наводить для этого: http://ru.wikipedia.org/wiki/QR_%D0%BA%D0%BE%D0%B4

zubr

Так нет же никаких противоречий с вашим методом.
Разница в одной белой точке. Не хотите ее использовать для оценки - не используйте.
А хотите - то +6 бит получите. Соответственно на мелких маяках интереснее становится.

Почему производительность может упасть? Можете потестить с белой точкой?

Я еще не собрал ваш код. Былдером лет 10 не пользовался.
Вот было бы здорово если бы был консольный тестик типа даешь картинку - получаешь картинку.
Тогда и оптимизировать будет на чем. И тестовые картинки страшные придумывать.

=DeaD=

2zubr: в смысле в одной белой точке? Если из внешнего черного квадрата изъять 1 квадратик и сделать его белым - не будет распознаваться квадратный контур - верхний фильтр в поиске маяков, что сильно уронит производительность.

Добавлено спустя 45 секунд:
2zubr: нарисуйте, что имеете в виду, может я вас не так понимаю :pardon:

zubr

у известных еще проблема с патентами..
но для понятия решаемых задач очень даже интересно http://www.id-russia.ru/Faq/Aztec/abtaztec.html

я имел в виду так (вариант 5x5):

11111
1xxx1
1xxx1
1xxx1
10111

=DeaD=

zubr писал(а):

я имел в виду так (вариант 5x5):

11111
1xxx1
1xxx1
1xxx1
10111

Так не пойдёт, как я и говорил, не сработает детектор квадрата на верхнем уровне алгоритма.

Добавлено спустя 1 минуту 32 секунды:
Есть идея в моём методе внешний черный квадрат сделать в 50% толщины ячейки и всё, сразу добавится куча бит

.

nest

mandigit
мало одного квадрата - делаем 3х3 квадратов размерами 16х16.
наружние - для центрации/позиционирования. внутренний - данные.
ну или наоборот.

для мышного сенсора они всё равно мелкие нужны. ну и пусть будет мелкие хоть 3х3 сантиметра.

mandigit

=DeaD= писал(а):

... Надо такой метод?

Давай!

nest писал(а):

мало одного квадрата - делаем 3х3 квадратов размерами 16х16.
наружние - для центрации/позиционирования. внутренний - данные.
ну или наоборот.
для мышного сенсора они всё равно мелкие нужны. ну и пусть будет мелкие хоть 3х3 сантиметра.

Хочется по-возможности остаться в схеме с картинкой, достаточной для определения позиции.

roboforum.ru

Код в квадрате?

Кто сейчас на конференции