32

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 (если есть), писал с телефона

Дубликаты не найдены

+7

ты серьезно думаешь что никто не придумал ничего?
https://yandex.ru/search/?text=%D1%81%D1%82%D0%B5%D0%B3%D0%B...

раскрыть ветку 3
-1

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

раскрыть ветку 2
+3

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

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

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

0

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

+3

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

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

раскрыть ветку 6
+1

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

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

раскрыть ветку 5
+2

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

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

раскрыть ветку 1
0

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

раскрыть ветку 2
+1
Чем это лучше/хуже LSB?
раскрыть ветку 1
+2

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

0

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

раскрыть ветку 8
0

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

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

раскрыть ветку 7
0

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

Короче, твой 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

раскрыть ветку 6
0

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


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

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

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

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

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

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


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

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

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

И тем не менее, несмотря на ваше сугубо личное время, PEP8 свято чтится в подавляющем большинстве компаний.

Сомнительный прием - это использовать list comprehension, строить массив и назначать его в неиспользуемую переменную, все для того чтобы просто выполнить функцию на наборе. Есть map, или просто цикл.


Про += бред написан. Лист в питоне - динамический массив, так что память довыделяется по мере необходимости, массив растет.

0

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

раскрыть ветку 2
+1

Да, вк кушоет такие картинки и восстановить их тяжело. Проверено на твоём алгоритме месяца 2 назад, слева оригинал справа вк

Иллюстрация к комментарию
+1

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

0

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

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

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

раскрыть ветку 1
0

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

раскрыть ветку 2
+2

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

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

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

раскрыть ветку 1
Похожие посты
Похожие посты не найдены. Возможно, вас заинтересуют другие посты по тегам: