Data-to-Image библиотека на Python

Здравствуйте, пикабушники.

Я создал библиотеку (и интерфейс командной строки для неё), кодирующую информацию в картинку посредством записи по 3/4 байта (в зависимости от цветового пространства, с альфа каналом или без) в каждый пиксель как описание цветов RGB(A). Идея моя, я ее не украл, хотя, возможно, ее кто-то уже придумал и реализовал раньше меня. Для чего это нужно? Многие файлообменники не требуют регистрации, нежели Скайп, FileShare, Mega и т.д. Так вот, теперь есть возможность передать файлы через такие хостинги картинок. Это больше подходит для опубликования файлов если передача другим способом невозможна или анонимная передача файлов (нет прямой передачи файлов как в Skype, ты выложил, другой взял, и все без регистрации). Берешь архив с файлами, ставишь на него пароль (лучше полное шифрование, если файл один то там можно и без таблицы файлов разобраться, особенно если картинка или текст) и, используя мою либу, кодируешь в картинку и выкладываешь.
Есть вопрос, который некоторых может волновать: почему не использовать steghide или добавит данные в конец памяти после марки end? Ответы: 1) малое количество памяти для кодирования; 2) размер картинки и маленькое разрешение создаст подозрение даже у самого неопытного юзера

Я был бы рад, чтобы кто-либо протестировал её, инструкция по использованию в README.md (--help страничка, потом в 0.0.3 добавлю поэтапную инструкцию. Репозиторий:

https://www.github.com/dredsss/d2i-lib

P.S. Тестировать лучше надо второй релиз v0.0.2, он работает быстрее из-за стороннего способа записи в пиксель. Первый релиз использовал методы для использования на отдельных пикселях, работают они медленней.
P.S.2. прошу прощения за пропущенные буквы (если есть) и за исправления T9 (если есть), писал с телефона

GNU/Linux

1K поста15.5K подписчика

Добавить пост

Правила сообщества

Все дистрибутивы хороши.

Будьте людьми.

Автор поста оценил этот комментарий

Для передачи файлов есть mega.nz и dropmefiles.com без регистрации.
Хранить на фотохостинге значимый объём данных не выйдет: "Ограничение на размер изображения 16 MB" у того же imgBB

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Ну да,  у меня была такая мысль. Кодирование в картинки все же обладает некими плюсами:

1) Не подозрительно. Если мамка увидит у тебя в сообщениях ссылку, она скажет: "что это такое? давай - переходи". Ты туда заходишь, а там файл "ГДЗ алгебра 8 класс.pdf". А если будет картинка вместо ссылки, мама скажет: "лол, ну окей - делай уроки", и уйдет

2) Прикольноо же, твой Майнкрафт.екзе в картинке.

показать ответы
1
DELETED
Автор поста оценил этот комментарий
Чем это лучше/хуже LSB?
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Нет ограничения по разрешению картинки и размеру файла

1
Автор поста оценил этот комментарий

Человек не знаком с LSB, чего ты.

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

> почему не использовать steghide

> малое количество памяти для кодирования

Моя библиотека не основана на LSB, она кодирует по инфу сразу в пиксель, а не скрывает ее в последних битах значений RGB. Посмотри первую цитату: это - не stegide

3
Автор поста оценил этот комментарий

Хостеры пережимают картинки, так что смысла тут не шибко много.
А устойчивые к сжатию методы давно известны - это QR коды.

Ну и ты уж не обижайся, но с использованием PIL/Pillow сильно много ума не надо, чтобы такое написать.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Хостеры вроде ImgBB и ImgHost.com не пережимают картинки (это делают в основом в соцсетях). А про то, что это легко сделать, ты прав. Хотя OpenCV не сложнее. PIL легкий и произовдительный

P.S. У QR кодов вместимость данных ограничена не хуже, чем со steghide'ом

показать ответы
DELETED
Автор поста оценил этот комментарий

ну хорошо. Всё равно это глупость - я про шифрование. Зачем? Чтобы было? Что мне мешает шифрануть выданную тобой картинку? например PGP? Я помню там идет уже сжатие.

Ты сделал выходную картинку более приятной со стороны пользователя?

Кстати, я тут вспомнил на днях. Такой софт был (который жмет данные в катринку) был популярен в начале 00-х годов. для открытых мейл серверов.

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

Если бы я хрень подобную делал я бы сделал. на основе RSA/DSA какого нибудь. дешево и сердито

раскрыть ветку (1)
Автор поста оценил этот комментарий
Дай название, будет интересно имплементировать эту фичу
показать ответы
DELETED
Автор поста оценил этот комментарий

шифрование то зачем? Хочешь раздуть ещё больше файл?

Короче, твой png (даешь JPEG! ) какой то совсем уж не красивый. Попробуй добавить кривые вместо пиксельного киселя.

https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B2%D0%B0...

Как ты всё это расшифруешь? Ну ты ж умный. ты поймешь :3

Если что тебе на кривые, как будешь использовать - сам придумай. Этакая триповая картинка может получиться.

во вторых в jpeg есть прямо вот спецификация, http://www.martinreddy.net/gfx/2d/JPEG.txt

раскрыть ветку (1)
Автор поста оценил этот комментарий
Rjindael не увеличивает размер
показать ответы
DELETED
Автор поста оценил этот комментарий

шифрование то зачем? Хочешь раздуть ещё больше файл?

Короче, твой png (даешь JPEG! ) какой то совсем уж не красивый. Попробуй добавить кривые вместо пиксельного киселя.

https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B2%D0%B0...

Как ты всё это расшифруешь? Ну ты ж умный. ты поймешь :3

Если что тебе на кривые, как будешь использовать - сам придумай. Этакая триповая картинка может получиться.

во вторых в jpeg есть прямо вот спецификация, http://www.martinreddy.net/gfx/2d/JPEG.txt

раскрыть ветку (1)
Автор поста оценил этот комментарий
Необязательно PNG, pillow много форматов поддерживает (PNG сжимает сильнее). Твоими кривыми Безье информации больше не закодируешь.
показать ответы
DELETED
Автор поста оценил этот комментарий

Я бы ещё по хафману сжал. Чтобы картинка меньше была.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да, сжатие данных перед кодированием я добавлю в версии 0.0.4.

Плюс еще шифрование AES где-то к 0.0.3

показать ответы
2
Автор поста оценил этот комментарий

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

Для таких вещей лучше как минимум numpy использовать.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Пока точно не знаю, что в нем использовать. На форуме спросил вчера

Автор поста оценил этот комментарий

А можешь составить график зависимости времени (с) конвертирования от размера файла (Мб)?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Можно)

показать ответы
1
Автор поста оценил этот комментарий

Есть мной замеченный минус: в Instagram'е, VK или других соцсетях размер картинок могут изменить или применить какие-нибудь фильтры, тогда наши данные восстановить уже будет очень трудно (можно, если знать алгоритм, которым меняли картинку (кроме блюра, там уже бесполезно))

показать ответы
1
Автор поста оценил этот комментарий

Это не программа для стеганографии, а для использования image хостингов в качестве файлообменников без регистрации

показать ответы
1
DELETED
Автор поста оценил этот комментарий
> размер картинки и маленькое разрешение создаст подозрение даже у самого неопытного юзера
Это мотивы из стегано.
Почему тогда вообще все пиксели не заменить на целевые данные и добавить нужный хедер картинки, чтобы хостеры приняли за картинку?
раскрыть ветку (1)
Автор поста оценил этот комментарий

Сайт не примет картинку, которую не может расжать. А таким способом данные и сожмутся, и в картинке будут как пиксели.

показать ответы
DELETED
Автор поста оценил этот комментарий

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


* Игнорирование PEP8 (табуляции в оступах, неправильные кавычки в docstring, пустые строки между классами, множественные команды в одной строке)

* Странная смесь приватных переменных (с __) и псевдоприватных (_)

* Куча валидации смешана с "бизнес-логикой", код был бы сильно чище если их разделить

* Куча магических констант в коде

* Сомнительный синтаксический прием "_ = [self._source_data.append(x) for x in self._image_PixelAccess[x, y]]"

* tuple([ <list comprehension> ]) - зачем конвертировать генератор в лист, чтобы сразу конвертировать в tuple?


и мне надоело, там еще куча мелочей. Код на троечку. На mid-level можно попробовать :)

раскрыть ветку (1)
Автор поста оценил этот комментарий
Pep8 - херня полная, разве что в каких-нибудь местах. Тот пункт с 'сомнительным синтаксическим приемом' имеет смысл, странно я это сделал, тут можно было и map использовать, но оператор += ни в коем случае, он перевыделяет полность память для данных, а массив работает по принципу вектора в C++

Я сейчас переписываю код, на исходный код обеих версий потратил 1 час (на обе).
показать ответы