Comments 50
(Linux) cacaview - ASCII image browser.
для сравнения в cacaview в cli
А автору нужно перехватывать исключение (когда не указываются вх/вых данные:
File "/home/user/soft/jpgtxt/jpgtxt.py", line 81, in <module>
jpgtxt(sys.argv[1], sys.argv[2])
IndexError: list index out of range
Насчет исключения да, спасибо, надо поправить. Но судя по тому, что вы сохранили как txt, замечу, что это не рендерер img->ascii. Более наглядно получается, если в исходном изображении нет мелких деталей.
Как сделать такой же терминал на телефоне, как у вас?
Нужно не исключения перехватывать, а входные данные валидировать.
Такое ощущение, что у вас не fixed-font, а это важно для asc2 art
По заголовку подумал, что сейчас про rarjpeg расскажут, а тут такое веселье. Спасибо
Напоминает известную иллюстрацию ограниченности применения ECB-режима блочных шифров:
Строго говоря если jpeg слева сжать, то ничего видно не будет, артефакты сжатия добавят шум которые неузнаваемо изменит результат. Артефакты сжатия видны при увеличении картинки невооруженным глазом, если кликнуть по картинке. А если оригинал 10 000 * 10 000 пикселей и оригинал без потерь информации (bmp, png формат), тогда да, при шифровании блочным шифром будет видна структура оригинала.
У кого программа шифрования под рукой можно проверить именно на картинке слева, именно что прикреплена, а не оригинал. Думаю не останется ни одного узнаваемого пикселя.
Ну, о JPEG тут речи и нет. Это о BMP и подобных форматах.
Но я ради интереса выполнил предложенный Вами эксперимент.
Я сделал скриншот левого изображения из моего комментария со всеми артефактами пережатия вот прямо "как есть", конвертировал его в bmp, получил файл 478x536 пикселей и размером примерно в 1 мегабайт.
Далее я зашифровал его таким образом:
openssl enc -des-ecb -in tux.bmp -nosalt -out out.bmp
(DES выбрал из-за размера блока. Все таки изображение достаточно небольшое)
Чтоб посмотреть результат в обычной программе просмотра изображений, я заменил первые 90 байт получившегося шифрованного файла на оригинальные (по википедии это максимальный размер заголовка BMP)
И вот что получилось:
Возможно, где-то ошибся в процессе, но мне кажется, внешний контур рисунка вполне угадывается... )
А разве применение режима ECB шифрования приводит к изменению исходных данных?
Что примечательно - я не могу сходу вспомнить утилиту командной строки, которая позволяла бы манипулировать к-тами AC и DC при сжатии.
Забавно, что перекодировщик хабра из 31кб оригинальной картинки сгенерировал 144кб "уменьшенную версию" :)
Я сначала скачал её и, естественно, ничего не сработало. Если что, на ПК надо нажать на картинку для зума и только потом её скачать.
А, у меня была старая версия Хабра, в ней все норм. Спасибо, добавил примечание!
Да это типичнейший программистский ляп. ВК, Facebook, telegram - все подряд если отправлять в сообщении оптимизированный png как изображение прекрасно понимают, что это картинка, конвертируют в jpg, добавляя заметных артефактов и увеличивая размер. Очень бесит.
Практическое применение отсутствует. Просто забавно.
Моя улыбка (как и всех остальных хабровчан) очень даже практична и полезна. Не стоит её недооценивать. Всех с пятницей со средой!!
О, мне та же мысль пришла пару лет назад: https://bolknote.ru/all/kartinka-v-terminale/
Много-много лет назад, для однокурсницы написал графический редактор который из bmp делал txt. Дальше она на файл натравливала нейросеть и что-то там делала.
Почему практического применения нет? Очень даже есть. Бывают системы без графического интерфейса, типичный ssh-терминал, например. И они всегда будут. Если стандарт jpeg доработать, то можно вначале файла пихать в нем символьное представление. Это не сильно утяжелит файл.
Или найти как в обычном jpeg в виде комментария такое вставлять.
Проще установить текстовый вьюер для графических файлов, чем менять формат
Есть ли готовая реализация на PHP?
Шрифты же у нас давно не квадратные, а прямоугольные, что видно на вытянутых ASCII. Точно не уверен, как сейчас, но у vga был режим знакоместа 8*16, т.е. 1 к 2, почему бы и тут не использовать схожие параметры?
Вы ещё один, который подумал, что я сделал рендерер в ascii. Одни и те же символы предназначены и для визуализации и для декодера
Стоило показать весь jpg-файл в блокноте, не всем очевидно что кроме самого текстового рисунка там больше ничего нет, это не rar-jpeg.
Меня ещё отсутствие стандартного заголовка JFIF, который есть почти в каждой картинке. Узнал, что истинный заголовок jpg — это байты 0xFF 0xD8 0xFF.
Метаданные все равно остаются. Это тоже может быть непонятно.
JFIF в начале - это комментарий, там может быть что угодно. У вас 3-й байт 0xFF относится уже к следующему маркеру. Парсер пропускает все от данных (структрура которых задается маркером) до следующего маркера. У начального маркера данных нет, поэтому файл может начинаться например как 0xFF, 0xD8, "Hello world", 0xFF, 0xDB.
Интересно, а можно ли подобным образом встроить исходный код, который тоже делал что-нибудь полезное по типу генерации этой же картинки?
Это уже следующий уровень вложенности, учитывая что ещё надо сделать код, который бы "генерировал" картинку, а не просто, скажем, распаковывал или декодировал. К тому же, как сделать граф, который бы выдавал разные символы на одни и те же байты изображения? Возможно, тут уже придётся возвращаться к цвету, меняя оттенки исходного изображения, чтобы был необходимый запас цветов. Но тогда наоборот, один и тот же символ не может выдавать разные цвета.
JPEG, который можно посмотреть в блокноте