Представьте себе, что у вас какая-то цифра, а так же та же цифра, но к которой слева прилип один пиксель мусора (так что получилась матрица с горизонтальной размерностью на 1 больше). Теперь некоторые колонки едут не в другие клетки сжатой матрицы, что может привести к существенным изменениям.
А что представлять, у меня большинство символов такие. Но вы думаете, что в сжатых матрицах этот эффект сохраниться? В значительных случаях нет, поскольку сжатие обнуляет подобные тонкости.
Более того, я даже вынашивал идею сравнения оригинальных матриц без их сжатия, но близкой размерности. Например, один символ 45*35 пикселей, а второй 43*37. Просто делаем все возможные сравнения со всеми допустимыми смещениями одной матрицы относительно другой. А выбираем то смещение, которое дает минимум расстояния Хэмминга. Так что «один пиксель мусора» нам погоды не сделает (и даже два!). Но проблема, как уже много раз указывалось, в том, что этот критерий не годится для группировки, только для поиска заданной матрицы в базе данных.
mihaild писал(а):
Конкретно: идете в википедию и читаете про линейные модели. Потом идете в гугл и находите, что есть для их обучения для используемого вами языка.
Конкретно нужна мотивация, а для мотивации достаточно намека. А так Википедия большая, читать есть много чего. Вот вашу информацию про locality-sensitive hasing я держу в уме, на свежую голову обязательно посмотрю внимательней. А пока идей для экспериментов мне хватает.
mihaild писал(а):
Тут вы хотите вложить матрицы в одномерное пространство. В таком виде нельзя задать, что, например, 0, 6 и 9 все больше похожи на 8, чем друг на друга.
Совершенно не факт! В сортировке участвует построчное разложение символов, а оно будет заметно отличаться для названных вам цифр. Более того, при подобной сортировке я делаю попарные сравнения, т.е., вычисляю искомое расстояние Хэмминга. Пока оно мало, последовательность матриц идет в одну группу, как только резко увеличилось, мы закрываем старую группу, и открывает новую, для которой продолжаем попарное попиксельное сравнение.
mihaild писал(а):
В любом случае, вы, кажется, спрашивали, как сделать. Ну вот стандартный способ - кластеризация.
Опять, недостаточно намека, но термин, я на всякий случай запомнил.
mihaild писал(а):
Вы, безусловно, можете пробовать придумать что-то свое, но работать, скорее всего, будет хуже (хотя проверить и можно, конечно).
Опять же, это все абстрактно. Вот если я смог прикрутить FFplay к своему проекту, то получил собственный видеопроигрыватель. А там мне просто непонятно, что куда прикручивать. Но от своих велосипедов я вполне могу выйти на профессиональные алгоритмы OpenCV. Но эту библиотеку нужно изучать серьезно, как матанализ Камынина, к примеру.
-- Пт авг 21, 2020 22:23:32 --В данном случае, убрать английский текст и написать вместо него русский.
Скажем, Яндекс.Переводчик умеет переводить с картинки.
Смотрите, у меня видео, а не картинка. Пока персонаж скажет одну фразу, пройдет несколько секунд. При 25 кадрах в секунду это порядка сотни изображений с одним и тем же текстом. Мне что переводить все из них? Смысл, вытащить уникальную текстовку, в данном случае французскую, а перевести можно любым переводчиком. Я пользуюсь Гугловским, переводит очень хорошо. А английский текст надо затереть, но так, чтобы видео фон не искажался. А на его место написать русский текст. Потом мы это видео проигрываем в нашем собственном видеопроигрывателе (который уже реализован на базе FFplay). Дополнительно добавляем интерактивные возможности, например, видео прокрутку одной фразы несколько раз. А для этого надо добавить возможность разметки видео и прочие специфические настройки, типа указать размеры текстовой области на видео (с помощью мыши). Так что простой перевод картинки нам не нужен.