Pull to refresh

Comments 32

Забавно!
А подобные алгоритмы с другими параметрами (размерностями растра, например) бывают?
Легко подобрать, играясь коэффициентами. Вместо 17 в знаменателях ставите ваше число строк.
Изображеня можно делать и цветные, тогда будет 3 числа к — для каждого цвета (если с альфа-каналом то 4-е), потом нужно просто после преобразования из к в битплейн, перевести из 3(4-х) битплейновых массивов в 1-н 32-х битный.

Пост о неравенстве Таппера… которое показано лишь на картинке в самом начале и дальше никакого упоминания о нем нет.
Почему бы не объяснить как (и почему) работает эта формула, не написать ее в нормальном виде?
Хоть бы в Python-коде использовали эту функцию для рисования, что ли…
А так, любую картинку в любом предопределенном разрешении можно в число и обратно перевести, даже на 17 умножать не надо.

Если вам интересен механизм работы самого неравенства, доказательство его работы, то вам сюда ТЫК (Если руки дойдут, то и перевод возможно напишу)

Впринципе, можно сделать реализацию через 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'


Заодно монохром будет выглядеть немножко лучше.
Да, действительно, спасибо за исправление.
Когда писал программу, думал, что функция getpixel вернет мне 1 или 0, т.к. изображение черно белое, потом понял, что это не так работает. Так и появился этот костыль
Забавно.
Но позвольте сделать несколько замечаний к самому коду.
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)]
Да, Вы правы. Проверял свой код на изображении хабра в статье, и там баг не выявился, т.к. первый и последний элементы списка совпали.
Более обобщенно, здесь подойдет lists[-(x % 17) - 1]
JungleTryne, сорри за внесенную путаницу.
UPD: Добавлен новая реализация функции from_k_to_bin, которая использует непосредственно функцию. Также были исправлены кусочки кода и заменены на более красивые, которые были предложены комментаторами. Добавлена теория про само неравенство в самое начало статьи
К сожалению, формула Таппера — это просто способ закодировать изображение, а не как-нибудь его сжать.
Число К из статьи — 1807 бит. Количество пиксель в картинке 106*17 = 1802.
Для сжатия не пойдет, и практической ценности видимо не имеет. Или всё же имеет?
А само число сжимается или у него слишком высокая энтропия?
Ну тут надо смотреть на энтропию изображения и энтропию его числа. Думаю что порядок величин одинаковый, так что не выстрелит.
Ну строковое представление числа, отлично сжимается, там энтропия априори низкая (и чем длинее число тем ниже). Сжатие строкового представления числа «хабр» более чем в два раза с помощью bz2. Если число перевести в 256 бит то уже не нужно сжимать — 32 байта. Только нет гарантии, что для любой картинки нам хватит 256 бит.
Да, это даже не квайн, просто способ обфускации. А вот циклический многоязыковой квайн, который бы в одной из фаз был визуальным представлением формулы и QR-кода с числом к.
Интересно, а можно ли уменьшить размер если использовать систему счиления кратную степени двойки?
Интересен другой момент, ведь эта формула описывает и свастику в том числе, и как привели выше если ее расширить до цветной и содержащий большее количество пикселей, то и детское порно можно найти, должна ли быть данная формула заблокирована РКНом?
Ответ такой же, как и на следующий вопрос: В Вавилонской Библиотеке есть все совпадения симоволов. Одни из них могут содержать гос тайну всех стран. Должно ли РКН заблокировать Вавилонскую библиотеку?
Скажите, доктор, а откуда у вас такие картинки?
Не понимаю, в чем ценность данного действия?
Можно ведь просто изображение сохранить в двухцветном *.BMP файле и полученный файл без заголовка просто принять за большое число сконвертировав его Base10 алгоритмом.
Закодировав число и декодировав полученную картинку, полученное число не будет изначальному. Хотя это вроде как логично из-за округления. С этим ничего не сделать?
Вопрос закрыт. Извиняюсь за беспокойство.
Sign up to leave a comment.

Articles