[Dunduk 0]

Ищется специалист с опытом работы по теме распознавания. Задача разовая, но вполне может возникать в будущем регулярно. Тестирование готовой работы будет проходить в Москве. Сама задача может быть реализована где угодно, другими словами, удаленка возможна.

Имеются ограничения: DSP TMS320DM642, время распознавания одного символа около 1 мс, не более. Символы зашумлены, количество пикселей небольшое и меняться не будет.

Я предлагаю следующий порядок:

1. Кандидат пишет мне письмо, кратко описывает свой опыт в этом деле

2. Я высылаю некоторые технические подробности задачи, и примеры картинок для распознавания.

3. Кандидат сообщает срок реализации задачи и гонорар. Договариваемся.

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

5. По окончании вылачиваем гонорар и получаем исходник. По договоренности, можно начать работу с предоплаты.

 

Для связи mcu.outsource(пёс)gmail.com

[Maverick_ 15]

Ищется специалист с опытом работы по теме распознавания. Задача разовая, но вполне может возникать в будущем регулярно. Тестирование готовой работы будет проходить в Москве. Сама задача может быть реализована где угодно, другими словами, удаленка возможна.

Имеются ограничения: DSP TMS320DM642, время распознавания одного символа около 1 мс, не более. Символы зашумлены, количество пикселей небольшое и меняться не будет.

Я предлагаю следующий порядок:

1. Кандидат пишет мне письмо, кратко описывает свой опыт в этом деле

2. Я высылаю некоторые технические подробности задачи, и примеры картинок для распознавания.

3. Кандидат сообщает срок реализации задачи и гонорар. Договариваемся.

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

5. По окончании вылачиваем гонорар и получаем исходник. По договоренности, можно начать работу с предоплаты.

 

Для связи mcu.outsource(пёс)gmail.com

так может тестовые картинки для распознавания тут разместите

 

а так на входе черный ящик... надо что-то распознать и нужно сделать менее чем за 1 мс и все... :(

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

[Dunduk 0]

так может тестовые картинки для распознавания тут разместите

Чтобы более точно представлять сложность работы...

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

картинки высылаю по первому же письму, ни каких секретов.

Шрифт, которым напечатан распознаваемый символ, известен заранее.

Изменено 15 декабря, 2014 пользователем Dunduk

[Dunduk 0]

update темы.

На данный момент появились наработки по данной задаче, есть исходник под Windows, и есть под DSP (CCS3.3), в целом кое-что работает. Думаю, это несложная задача для человека с соответствующим опытом. Необходимо:

1. усовершенствовать алгоритм, т.е. сделать распознавание более эффективным и более быстрым (время на 1 фрагмент из 10 символов - 5мс или быстрее на DSP)

2. написать служебную утилитку, которая бы генерировала эталонный набор символов из предоставленного мной большого количества (сотни) фрагментов. Это связано с тем, что мы распознаем не какой-то стандартный Arial, а некий другой шрифт. К нему нужно как-то адаптироваться. Конечно, утилитка должна быть под винду, здесь не надо ни какого реального времени.

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

У данной задачи есть продолжение, объем большой, поэтому хотелось бы найти специалиста и работать с ним на долговременной основе.

Работу оплачиваем по договору, и точно в оговоренный срок. Пишите!

 

mcu.outsource(пёс)gmail.com

sample.rar

[Stepanov 9]

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

[iiv 29]

Вот все-таки об арифметической сложности можно тут пообсуждать, не флейма ради а за истину!

 

Как я понял, картинка 50*18=900 пикселей. Пусть в алфавите 64 символа (26большие буквы+26маленькие буквы+10цифры+пробел и точка). Если делать корреляцию, все сводится к построению матрицы из набора таких символов, вычислении ее псевдообратной - это надо однажды сделать на хосте, чтобы запомнить результат, а потом на ТМСе надо выполнять умножение на эту матрицу, пусть даже мы поигрались с точностью, представили все в целых числах, но матрица получается 900*64 и умножений будет тоже 50 000, при производительности 700 мипсов можно получить (опять говорю, 4 умножения целых склеиваем в одно) результат за 20мкс.

 

Если к корреляции добавить сдвиги (символы "прыгают" до 3-х пикселов), то на символ будет примерно по 25 дополнительных векторов, но вектора хорошо еще на хосте подапроксимируются, тогда имеем примерно в 5 раз больше векторов, то есть нам надо будет 100мкс.

 

Если тут все обсуждения выше шли о милисекундах, то в чем вопрос-то, если Вы sgemm/sgemv из пакета lapack ( http://www.netlib.org/lapack) на ваш процессор скомпилите хотя бы на пол пика его производительности, я 3 строки кода - решения Вашей задаче в этой теме опубликую, и будет оно за 0.4милисекунды (без упаковки 4 интов в один) один символ распознавать. Хостовая настройка конечно не три строки будет, но в 10-15 строк можно вписаться, при наличии скомпиленного лапака (под убунтами оно штатно в репозитариях имеется) и мне тоже не жалко ею здесь поделиться :)

 

Если тут в обсуждениях все-таки речь шла о микросекундах, то тогда ой, как же имея 700 мипсов можно за 1 микросекунду 900 пикселей-то хотя бы один раз обойти, то-есть задача, как я понимаю, даже чисто теоретически не решаема?

 

EDIT: кажется я изначально один порядок упустил, сейчас поправил, но утверждение практически все в силе.

[_pv 78]

только пикселей не 900, а 9000 = 50х180.

 

если не корреляцию, а что-то вроде преобразования Хафа, тогда на обнаружение одного типа символа надо будет около полумиллиона МАСов.

соответственно для перебора 50 символов надо 25ММАСов при теоретически "возможных" 720*8=5760, получается около 4мс,

еще два раза можно отыграть по вертикали картинку обрезав, высота символа там 25 пикселей всего а не 50,

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

то есть вполне вероятно что вычислительной мощности может и хватит, но без запаса.

 

[iiv 29]

только пикселей не 900, а 9000 = 50х180.

 

да, только на картинке-то 10 символов, каждый соответственно по 900 пикселей.

 

Хафа я бы очень не рекомендовал, если шум на исследуемых картинках большой, все-таки наименьшие квадраты в этом случае однозначно точнее будут.

 

Кстати, вот код, о котором я говорил (минут 10 потратил на написание):

 

// M - все пикселы картинки в любой последовательности
// N - максимальное число букв/цифр алфавита
// K - подаппроксимация для сдвига = 5
#define M 900
#define N 64
float MainTable[N][K][M]; // надо сгенерить это на хосте
float Picture[M]; // определяемая картинка попиксельно в той же последовательности
float Tmp1[N*K]; // вспомогательный массив
float Tmp2[K]={1, ..., 1}; // еще один вспомогательный массив, его надо предварительно заполнить единицами
float Tmp3[N]; // еще один вспомогательный массив

sgemv_('t', M, K*N, 1., MainTable[0][0], M, Picture, 1, 0., Tmp1, 1);
sgemv_('t', K, N, 1., Tmp1, K, Tmp2, 1, 0., Tmp3, 1);
res=isamax_(N, Tmp3, 1)-1; // возвращаемое значение - номер распознанной картинки

три оператора, как я и говорил :)

 

EDIT: правда в 4 строки будут более честные наименьшие квадраты :)

sgemv_('t', M, K*N, 1., MainTable[0][0], M, Picture, 1, 0., Tmp1, 1);
for(i=0; i<N; i++)
  Tmp3[i]=snrm2_(K, Tmp1+i*K, 1);
res=isamax_(N, Tmp3, 1)-1;

 

а инициализация

 

float InputTable[N][KK][M]; // исходные картинки без шума, по индексу KK надо поздвигать каждую букву попиксельно на все возможные направления, KK=25, сдвигаем каждую букву максимум на до 2-х пикселов (включительно) в каждую сторону
float HTmp1[KK*N]; // вспомогательный массив
int i, j, k; // вспомогательные переменные

for(i=0; i<N; i++)
{ sgesvd_('o', 'n', M, KK, InputTable[i][0], M, HTmp1, 0, M, 0, KK, &j);
  scopy_(M*K, InputTable[i][0], 1, MainTable[i], 1);
  for(j=0; j<K; j++)
    sscal_(M, HTmp1[j], MainTable[i][j], 1);
}
sgesvd_('o', 's', M, K*N, MainTable, M, HTmp1, InputTable[0][0], M, InputTable[N][0], K*N, 1, &j);
for(i=0; i<N*K; i++)
  sscal(M, HTmp1, InputTable[0][i], 1);
sgemm_('n', 'n', M, K*N, 1., InputTable[0][0], M, InputTable[N][0], K*N, 0., MainTable[0][0], M);

тоже, как обещал, в 10 операторов уложился :)

 

А правда, что у этого ТМСа 8 МАС за такт? Если да, то при полном пике с лапака за 0.1мс на символ должно работать :)

[Dunduk 0]

Дорогие iiv и _pv,

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

 

[iiv 29]

Дорогие iiv и _pv,

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

я код опубликовал, он должен работать, компилите и радуйтесь на здоровье, просто было как-то странно, что с Вашей задачей Вы уже пол-года мучаетесь. Если по сути чего - может помогу, пишите, или звоните, телефон могу в личку послать. Кроме самого алгоритма (который 4+10 строк) я предвижу много работы по вводу-выводу, и если по алгоритму, а именно по математической части, я чего Вам посоветовать бы смог, но вот остальным, к сожалению, у меня нет времени и возможности заниматься.

 

С уважением

 

ИИВ

[_pv 78]

Хафа я бы очень не рекомендовал, если шум на исследуемых картинках большой, все-таки наименьшие квадраты в этом случае однозначно точнее будут.

конкретные цифры что там с С/Ш получается не смотрел, но на тестовой картинке выглядит вроде не очень плохо:

[iiv 29]

цифры не смотрел но выглядит вроде не очень плохо:

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

[Dunduk 0]

... если возникнут вращения, или масштабирования...

нет, это исключено.

 

[Stepanov 9]

Хаф в данном случае по скорости вообще не пройдет, без вариантов, да и по требуемой точности будет на пределе.

[_pv 78]

Хаф в данном случае по скорости вообще не пройдет, без вариантов, да и по требуемой точности будет на пределе.

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