Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Забавно!
А подобные алгоритмы с другими параметрами (размерностями растра, например) бывают?
А подобные алгоритмы с другими параметрами (размерностями растра, например) бывают?
Пост о неравенстве Таппера… которое показано лишь на картинке в самом начале и дальше никакого упоминания о нем нет.
Почему бы не объяснить как (и почему) работает эта формула, не написать ее в нормальном виде?
Хоть бы в Python-коде использовали эту функцию для рисования, что ли…
А так, любую картинку в любом предопределенном разрешении можно в число и обратно перевести, даже на 17 умножать не надо.
Если вам интересен механизм работы самого неравенства, доказательство его работы, то вам сюда ТЫК (Если руки дойдут, то и перевод возможно напишу)
Впринципе, можно сделать реализацию через PyPlot, только остается вопрос, будет ли они быстрой и эффективной… А так, спасибо за идею для второй части :)
Впринципе, можно сделать реализацию через PyPlot, только остается вопрос, будет ли они быстрой и эффективной… А так, спасибо за идею для второй части :)
Я говорю о теме поста, и о том что идет по сути в его теле :)
Они не взаимосвязаны никак, вообще. Ни код, ни текст не раскрывают темы.
Почему же? Джефф Таппер описал простой способ генерации числа k для каждого изображения. Да, так можно сделать с изображением любого формата, но данный пост показывает, что мы это делаем не просто так — все связано с его формулой. Как эта формула работает — я Вам уже отправил ссылку. Тема топика — реализация алгоритма на Python — алгоритм нахождения числа k был реализован, хоть и показался немного детским
Вы правы, добавил краткое разъяснение работы формулы Таппера в начало статьи. А то как то суховато получилось
А зачем преобразовывать число в строку?
Лучше было бы так:
Заодно монохром будет выглядеть немножко лучше.
byte = str(image.getpixel((x,y)))
if byte == "255":
byteset += '1'
else:
byteset += '0'
Лучше было бы так:
if image.getpixel((x,y)) > 127:
byteset += '1'
else:
byteset += '0'
Заодно монохром будет выглядеть немножко лучше.
Для тех, кому интересно, как оно работает www.youtube.com/watch?v=_s5RFgd59ao
Numberphile вызывает зависимость :)
Забавно.
Но позвольте сделать несколько замечаний к самому коду.
Можно упростить до
А чтобы не сортировать список lists в обратном порядке, поменяйте знак индекса на противоположный, т.е.
можно заменить на
Но позвольте сделать несколько замечаний к самому коду.
if len(binary) < 1802: new_binary = "" for i in range(1802-len(binary)): new_binary += "0" binary = new_binary + binary
Можно упростить до
binary = ("0" * (1802 - len(binary))) + binary
А чтобы не сортировать список lists в обратном порядке, поменяйте знак индекса на противоположный, т.е.
for x in range(1802): lists[x%17].append(binary[x]) lists.reverse() #Немножко костылей - без этого изображение будет отзеркаленным
можно заменить на
for x in range(1802):
lists[-(x % 17)].append(binary[x])
Спасибо за исправление
Пожалуйста!
Возможно, здесь меня поправят, так что замечу, что вариант
будет чище и куда уместнее первого.
binary = ("0" * (1802 - len(binary))) + binary
Возможно, здесь меня поправят, так что замечу, что вариант
binary = binary.rjust(1802, "0")будет чище и куда уместнее первого.
Ещё можно заменить
flag_okay = False
if width == _SIZE_WIDTH and height == _SIZE_HEIGHT:
flag_okay = True
if not flag_okay:На просто
if width != _SIZE_WIDTH or height != _SIZE_HEIGHT:
Противоположный индекс не сгодится, ведь
lists[-0]==lists[0], а должен быть lists[-1]. Я бы предложил lists[16-(x%17)]UPD: Добавлен новая реализация функции from_k_to_bin, которая использует непосредственно функцию. Также были исправлены кусочки кода и заменены на более красивые, которые были предложены комментаторами. Добавлена теория про само неравенство в самое начало статьи
К сожалению, формула Таппера — это просто способ закодировать изображение, а не как-нибудь его сжать.
Число К из статьи — 1807 бит. Количество пиксель в картинке 106*17 = 1802.
Для сжатия не пойдет, и практической ценности видимо не имеет. Или всё же имеет?
Число К из статьи — 1807 бит. Количество пиксель в картинке 106*17 = 1802.
Для сжатия не пойдет, и практической ценности видимо не имеет. Или всё же имеет?
А само число сжимается или у него слишком высокая энтропия?
Ну тут надо смотреть на энтропию изображения и энтропию его числа. Думаю что порядок величин одинаковый, так что не выстрелит.
Ну строковое представление числа, отлично сжимается, там энтропия априори низкая (и чем длинее число тем ниже). Сжатие строкового представления числа «хабр» более чем в два раза с помощью bz2. Если число перевести в 256 бит то уже не нужно сжимать — 32 байта. Только нет гарантии, что для любой картинки нам хватит 256 бит.
Да, это даже не квайн, просто способ обфускации. А вот циклический многоязыковой квайн, который бы в одной из фаз был визуальным представлением формулы и QR-кода с числом к.
Интересно, а можно ли уменьшить размер если использовать систему счиления кратную степени двойки?
Интересен другой момент, ведь эта формула описывает и свастику в том числе, и как привели выше если ее расширить до цветной и содержащий большее количество пикселей, то и детское порно можно найти, должна ли быть данная формула заблокирована РКНом?
Не понимаю, в чем ценность данного действия?
Можно ведь просто изображение сохранить в двухцветном *.BMP файле и полученный файл без заголовка просто принять за большое число сконвертировав его Base10 алгоритмом.
Можно ведь просто изображение сохранить в двухцветном *.BMP файле и полученный файл без заголовка просто принять за большое число сконвертировав его Base10 алгоритмом.
Закодировав число и декодировав полученную картинку, полученное число не будет изначальному. Хотя это вроде как логично из-за округления. С этим ничего не сделать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Формула Таппера и реализация алгоритма на Python