Проблема кодирования изображений в Твиттере [закрыто]

Если картинка стоит 1000 слов, сколько из картинки вы можете уместить в 140 символов?

Примечание : вот и все, ребята! Крайний срок получения щедрости здесь, и после некоторого трудного обсуждения я решил, что вступление Боджума едва ли вытеснило вступление Сэма Хочевара . Я опубликую более подробные заметки, как только у меня будет возможность написать их. Конечно, каждый может свободно представлять свои решения и улучшать решения, чтобы люди могли голосовать за них. Спасибо всем, кто представил и запись; Я наслаждался всеми ими. Мне было очень весело бегать, и я надеюсь, что это было весело и для участников, и для зрителей.

Я наткнулся на этот интересный пост о попытке сжать изображения в комментарии в Твиттере, и у многих людей в этой теме (и в теме Reddit ) были предложения о том, как можно это сделать. Итак, я полагаю, что это было бы хорошим испытанием для кодирования; пусть люди вкладывают свои деньги туда, где они говорят, и покажут, как их идеи о кодировании могут привести к более подробной информации в ограниченном пространстве, которое у вас есть.

Я призываю вас придумать систему общего назначения для кодирования изображений в сообщения Twitter из 140 символов и их повторного декодирования в изображение. Вы можете использовать символы Юникода, так что вы получите более 8 бит на символ. Однако, даже учитывая символы Юникода, вам нужно будет сжимать изображения в очень небольшое пространство; это, безусловно, будет сжатие с потерями, и поэтому должны быть субъективные суждения о том, как хорошо выглядит каждый результат.

Вот результат, который оригинальный автор, Квазимондо , получил из своей кодировки (изображение под лицензией Creative Commons Attribution-Noncommercial ):

Вы можете сделать лучше?

правила

1. Ваша программа должна иметь два режима: кодирование и декодирование .
2. При кодировании :
   1. Ваша программа должна принимать в качестве входных данных графику в любом приемлемом растровом графическом формате по вашему выбору. Мы скажем, что любой растровый формат, поддерживаемый ImageMagick, считается разумным.
   2. Ваша программа должна вывести сообщение, которое может быть представлено в 140 или менее кодовых точках Юникода; 140 кодовых точек в диапазоне U+0000- U+10FFFF, без учета символов ( U+FFFE, U+FFFF, U+пFFFE , U+пFFFF , где п является 1- 10шестнадцатеричное, а диапазон U+FDD0- U+FDEF) и суррогатной кодовые точки ( U+D800- U+DFFF). Он может быть выведен в любой разумной кодировке на ваш выбор; любая кодировка, поддерживаемая GNU,iconv будет считаться разумной, и, скорее всего, хорошим выбором будет исходная кодировка вашей платформы или кодировка локали. См. Примечания Unicode ниже для более подробной информации.
3. При декодировании :
   1. Ваша программа должна принимать в качестве входных данных вывод вашего режима кодирования .
   2. Ваша программа должна выводить изображение в любом приемлемом формате по вашему выбору, как определено выше, хотя для выходных векторных форматов тоже все в порядке.
   3. Выходное изображение должно быть приближенным к входному изображению; чем ближе вы можете добраться до входного изображения, тем лучше.
   4. Процесс декодирования может не иметь доступа к какому-либо другому выходу процесса кодирования, кроме выходных данных, указанных выше; то есть вы не можете загрузить изображение куда-нибудь и вывести URL для процесса декодирования, чтобы загрузить, или что-нибудь глупое, как это.

4. Для согласованности в пользовательском интерфейсе ваша программа должна вести себя следующим образом:

   1. Ваша программа должна быть скриптом, который можно установить на исполняемый файл на платформе с соответствующим интерпретатором, или программой, которая может быть скомпилирована в исполняемый файл.
   2. Ваша программа должна принять в качестве первого аргумента либо encodeлибо decodeустановить режим.

   3. Ваша программа должна принимать данные одним или несколькими из следующих способов (если вы реализуете тот, который принимает имена файлов, вы также можете читать и писать из stdin и stdout, если имена файлов отсутствуют):

      1. Возьмите вход от стандартного входа и произведите выход на стандартный выход.

         my-program encode <input.png >output.txt
         my-program decode <output.txt >output.png
         

      2. Возьмите ввод из файла, названного во втором аргументе, и произведите вывод в файле, названном в третьем.

         my-program encode input.png output.txt
         my-program decode output.txt output.png
         

5. Для вашего решения, пожалуйста, напишите:
   1. Ваш код полностью и / или ссылка на него размещена в другом месте (если он очень длинный или требует много файлов для компиляции или что-то в этом роде).
   2. Объяснение того, как это работает, если это не сразу видно из кода или если код длинный, и люди будут заинтересованы в резюме.
   3. Пример изображения с исходным изображением, текстом, сжимаемым до него, и декодированным изображением.
   4. Если вы основываетесь на идее, которая была у кого-то другого, приписывайте их. Можно попытаться усовершенствовать чужую идею, но вы должны приписать их.

Методические рекомендации

Это в основном правила, которые могут быть нарушены, предложения или критерии оценки:

1. Эстетика важна. Я буду судить и предположить, что другие люди судят, основываясь на:
   1. Насколько хорошо выглядит выходное изображение и насколько оно похоже на оригинал.
   2. Как красиво выглядит текст. Полностью случайный gobbledigook - это нормально, если у вас действительно умная схема сжатия, но я также хочу увидеть ответы, которые превращают изображения в многоязычные стихи или что-то умное в этом роде. Обратите внимание, что автор оригинального решения решил использовать только китайские иероглифы, так как это выглядело лучше.
   3. Интересный код и умные алгоритмы всегда хороши. Мне нравится короткий, понятный и понятный код, но действительно умные сложные алгоритмы тоже подходят, если они дают хорошие результаты.
2. Скорость также важна, хотя и не так важна, как хорошая работа по сжатию изображения. Я предпочел бы иметь программу, которая может конвертировать изображение за одну десятую секунды, чем что-то, что будет выполнять генетические алгоритмы целыми днями.
3. Я предпочту более короткие решения более длинным, если они достаточно сопоставимы по качеству; краткость это добродетель.
4. Ваша программа должна быть реализована на языке, который имеет свободно доступную реализацию в Mac OS X, Linux или Windows. Я хотел бы иметь возможность запускать программы, но если у вас есть отличное решение, которое работает только под MATLAB или что-то еще, это нормально.
5. Ваша программа должна быть максимально общей; он должен работать для максимально возможного количества различных изображений, хотя некоторые могут давать лучшие результаты, чем другие. В частности:
   1. Наличие нескольких изображений, встроенных в программу, с которой она сопоставляет и записывает ссылку, а затем создает соответствующее изображение при декодировании, довольно неудачно и охватывает только несколько изображений.
   2. Программа, которая может снимать изображения простых, плоских, геометрических фигур и разлагать их на какой-то векторный примитив, довольно изящна, но если она не работает на изображениях, выходящих за рамки определенной сложности, она, вероятно, недостаточно общая.
   3. Программа, которая может снимать только изображения с определенным фиксированным соотношением сторон, но с ними хорошо справляется, тоже будет в порядке, но не идеальна.
   4. Вы можете обнаружить, что черно-белое изображение может получить больше информации в меньшем пространстве, чем цветное изображение. С другой стороны, это может ограничивать типы изображений, к которым он применим; лица выглядят хорошо в черно-белом, но абстрактные рисунки могут не так хорошо выглядеть.
   5. Прекрасно, если выходное изображение меньше входного, но при этом примерно в той же пропорции. Это нормально, если вам нужно увеличить изображение, чтобы сравнить его с оригиналом; важно то, как это выглядит.
6. Ваша программа должна выдавать результаты, которые могут проходить через Twitter и выходить невредимыми. Это всего лишь руководство, а не правило, так как я не смог найти никакой документации по конкретному поддерживаемому набору символов, но вам, вероятно, следует избегать управляющих символов, невидимых комбинационных символов, символов личного пользования и тому подобного.

Скоринговая рубрика

В качестве общего руководства о том, как я буду оценивать решения при выборе приемлемого решения, допустим, что я, вероятно, буду оценивать решения по 25-балльной шкале (это очень грубо, и я не буду ничего оценивать напрямую, просто используя это в качестве основного ориентира):

• 15 баллов за то, насколько хорошо схема кодирования воспроизводит широкий диапазон входных изображений. Это субъективное, эстетическое суждение
  • 0 означает, что он вообще не работает, каждый раз возвращает одно и то же изображение или что-то в этом роде.
  • 5 означает, что он может кодировать несколько изображений, хотя декодированная версия выглядит некрасиво и может не работать вообще на более сложных изображениях
  • 10 означает, что он работает с широким диапазоном изображений и создает приятные на вид изображения, которые иногда могут быть различимы
  • 15 означает, что он создает идеальные копии некоторых изображений, и даже для больших и более сложных изображений дает что-то узнаваемое. Или, возможно, он не делает изображения, которые достаточно узнаваемы, но создает красивые изображения, которые явно получены из оригинала.
• 3 балла за умное использование набора символов Unicode
  • 0 баллов за простое использование всего набора разрешенных символов
  • 1 балл за использование ограниченного набора символов, которые можно переносить через Твиттер или в самых разных ситуациях.
  • 2 балла за использование тематического подмножества символов, таких как только иероглифы Хань или только символы справа налево
  • 3 балла за то, что вы делаете что-то действительно аккуратное, например, генерирование читаемого текста или использование символов, похожих на изображение, о котором идет речь
• 3 балла за умные алгоритмические подходы и стиль кода
  • 0 баллов за что-то, что составляет 1000 строк кода только для уменьшения изображения, обрабатывать его как 1 бит на пиксель, а base64 кодировать это
  • 1 балл за то, что использует стандартную технику кодирования и хорошо написано и кратко
  • 2 балла за то, что вводит относительно новый метод кодирования, или, что удивительно коротко и чисто
  • 3 балла за один вкладыш, который на самом деле дает хорошие результаты, или что-то новое, что открывает новые возможности в графическом кодировании (если это кажется малым количеством баллов за выход на новый уровень, помните, что такой результат, скорее всего, будет иметь высокий балл за эстетику также)
• 2 очка за скорость. При прочих равных условиях, чем быстрее, тем лучше, но приведенные выше критерии важнее скорости.
• 1 балл за запуск на свободном (с открытым исходным кодом) программном обеспечении, потому что я предпочитаю бесплатное программное обеспечение (обратите внимание, что C # будет по-прежнему иметь право на этот балл, пока он работает на Mono, аналогично, код MATLAB будет иметь право, если он будет работать на GNU Octave)
• 1 балл за фактическое соблюдение всех правил. Эти правила стали немного большими и сложными, поэтому я, вероятно, приму хорошие ответы, в которых одна маленькая деталь ошибочна, но я дам дополнительный балл любому решению, которое действительно следует всем правилам.

Эталонные изображения

Некоторые люди просили некоторые эталонные изображения. Вот несколько эталонных изображений, которые вы можете попробовать; здесь встроены уменьшенные версии, все они ссылаются на увеличенные версии изображения, если они вам нужны:

приз

Я предлагаю вознаграждение в 500 представителей (плюс 50, которые получает StackOverflow) для решения, которое мне нравится больше всего, на основе вышеуказанных критериев. Конечно, я призываю всех остальных голосовать здесь за их любимые решения.

Обратите внимание на крайний срок

Этот конкурс будет продолжаться до тех пор, пока не закончится щедрость, около 18:00 в субботу, 30 мая. Я не могу сказать точное время, когда оно закончится; это может быть где-то с 5 до 7 вечера. Я гарантирую, что посмотрю все записи, представленные до 14:00, и сделаю все возможное, чтобы просмотреть все записи, представленные до 16:00; если решения будут представлены после этого, у меня может не быть возможности оценить их до того, как я приму решение. Кроме того, чем раньше вы отправите заявку, тем больше у вас будет шансов на голосование, чтобы помочь мне выбрать лучшее решение, поэтому постарайтесь подать заявку раньше, чем прямо в срок.

Примечания Юникода

Также возникла путаница относительно того, какие символы Unicode разрешены. Диапазон возможных кодовых точек Юникода U+0000в U+10FFFF. Есть некоторые кодовые точки, которые никогда не могут использоваться в качестве символов Юникода при любом открытом обмене данными; это нехарактеры и суррогатные кодовые точки . Noncharacters определены в 5.1.0 секции Unidode Standard 16.7 в качестве значений U+FFFE, U+FFFF, U+пFFFE , U+пFFFF , где п является 1- 10шестнадцатеричное, а диапазонU+FDD0 -U+FDEF, Эти значения предназначены для внутреннего использования для конкретного приложения, и соответствующие приложения могут вырезать эти символы из текста, обработанного ими. Суррогатные кодовые точки, определенные в разделе 3.8 стандарта Unicode 5.1.0 как U+D800- U+DFFF, используются для кодирования символов за пределами базовой многоязычной плоскости в UTF-16; таким образом, невозможно представить эти кодовые точки непосредственно в кодировке UTF-16, и недопустимо кодировать их в любом другом кодировании. Таким образом, для целей этого конкурса я разрешу любую программу, которая кодирует изображения в последовательность не более чем 140 кодовых точек Юникода из диапазона U+0000- U+10FFFFисключая все нехарактерные и суррогатные пары, как определено выше.

Я предпочитаю решения, которые используют только назначенные символы, и даже лучшие, которые используют умные подмножества назначенных символов или делают что-то интересное с набором символов, который они используют. Список назначенных символов см. В базе данных символов Unicode ; обратите внимание, что некоторые символы перечислены непосредственно, а некоторые перечислены только как начало и конец диапазона. Также обратите внимание, что суррогатные кодовые точки перечислены в базе данных, но запрещены, как указано выше. Если вы хотите воспользоваться определенными свойствами символов, чтобы сделать выводимый текст более интересным, существует множество доступных баз данных символьной информации , таких как список именованных блоков кода и различные свойства символов.,

Поскольку в Twitter не указан точный набор символов, который они поддерживают, я буду снисходительно относиться к решениям, которые на самом деле не работают с Twitter, потому что некоторые символы имеют дополнительное значение или определенные символы удаляются. Желательно, но не обязательно, чтобы все закодированные выходы могли передаваться целыми и невредимыми через Twitter или другой сервис микроблогов, такой как identi.ca . Я видел некоторую документацию, в которой говорится, что Twitter-сущности кодирует <,> и &, и, таким образом, считает их как 4, 4 и 5 символов соответственно, но я сам не проверял это, и их счетчик символов JavaScript не кажется считать их таким образом.

Советы и ссылки

• Определение допустимых символов Юникода в правилах немного сложнее. Выбор одного блока символов, такого как унифицированные идеограммы CJK (U + 4E00 – U + 9FCF), может быть проще.
• Вы можете использовать существующие библиотеки изображений, такие как ImageMagick или Python Imaging Library , для манипулирования изображениями.
• Если вам нужна помощь в понимании набора символов Unicode и его различных кодировок, см. Это краткое руководство или подробный FAQ по UTF-8 в Linux и Unix .
• Чем раньше вы получите свое решение, тем больше времени мне (и другим людям, участвующим в голосовании) придется рассмотреть его. Вы можете редактировать свое решение, если улучшите его; Я буду основывать свою награду на самой последней версии, когда я в последний раз рассмотрю решения.
• Если вам нужен простой формат изображения для анализа и записи (и вы не хотите просто использовать существующий формат), я бы предложил использовать формат PPM . Это текстовый формат, с которым очень легко работать, и вы можете использовать ImageMagick для преобразования в него и из него.

Хорошо, вот мое: nanocrunch.cpp и файл CMakeLists.txt для его сборки с использованием CMake. Он использует API-интерфейс Magick ++ ImageMagick для большей части обработки изображений. Это также требует библиотеки GMP для арифметики bignum для ее кодирования строки.

Я основал свое решение на сжатии фрактальных изображений с несколькими уникальными поворотами. Основная идея состоит в том, чтобы взять изображение, уменьшить копию до 50% и искать фрагменты в различных ориентациях, которые выглядят как неперекрывающиеся блоки в исходном изображении. В этом поиске используется очень грубый подход, но это облегчает внедрение моих модификаций.

Первая модификация состоит в том, что вместо того, чтобы просто смотреть на повороты и перевороты на девяносто градусов, моя программа также учитывает ориентации на 45 градусов. Это еще один бит на блок, но это очень помогает качеству изображения.

Другое дело, что хранение регулировки контрастности / яркости для каждого компонента цвета каждого блока слишком дорого. Вместо этого я храню сильно квантованный цвет (палитра имеет только 4 * 4 * 4 = 64 цвета), который просто смешивается в некоторой пропорции. Математически это эквивалентно переменной яркости и постоянной настройке контрастности для каждого цвета. К сожалению, это также означает, что нет отрицательного контраста, чтобы перевернуть цвета.

Как только он вычисляет позицию, ориентацию и цвет для каждого блока, он кодирует это в строку UTF-8. Во-первых, он генерирует очень большой объем данных для представления данных в таблице блоков и размера изображения. Подход к этому аналогичен решению Сэма Хоцевара - вид большого числа с основанием, которое меняется в зависимости от положения.

Затем он преобразует это в базу любого размера набора символов. По умолчанию он в полной мере использует назначенный набор символов Юникода, минус символы амперсанд меньше, больше, контроль, объединение и суррогатные и частные символы. Это не красиво, но это работает. Вы также можете закомментировать таблицу по умолчанию и выбрать для печати 7-битный ASCII для печати (опять-таки без символов <,> и &) или унифицированные идеограммы CJK. В таблице, в которой доступны коды символов, хранится длина серии, закодированная чередующимися сериями недопустимых и допустимых символов.

В любом случае, вот некоторые изображения и времена (измеренные на моем старом 3.0 ГГц P4), сжатые до 140 символов в полном назначенном наборе Unicode, описанном выше. В целом, я вполне доволен тем, как все у них получилось. Если бы у меня было больше времени для работы над этим, я бы, вероятно, попытался уменьшить блочность распакованных изображений. Тем не менее, я думаю, что результаты довольно хороши для экстремальной степени сжатия. Распакованные изображения немного импрессионистичны, но мне довольно легко увидеть, как биты соответствуют оригиналу.

Логотип переполнения стека (8,6 с для кодирования, 7,9 с для декодирования, 485 байт):
http://i44.tinypic.com/2w7lok1.png

Лена (32,8 с для кодирования, 13,0 с для декодирования, 477 байт):
http://i42.tinypic.com/2rr49wg.png http://i40.tinypic.com/2rhxxyu.png

Мона Лиза (43,2 с для кодирования, 14,5 с для декодирования, 490 байтов):
http://i41.tinypic.com/ekgwp3.png http://i43.tinypic.com/ngsxep.png

Изменить: Объединенные символы CJK

Сэм спросил в комментариях об использовании этого с CJK. Вот версия Моны Лизы, сжатой до 139 символов из унифицированного набора символов CJK:

http://i43.tinypic.com/2yxgdfk.png 咏璘驞凄脒鵚据蛥鸂拗朐朖辿韩瀦魷歪痫栘璯緍脲蕜抱揎頻蓼債鑡嗞靊寞柮嚛嚵籥聚隤慛絖銓馿渫櫰矍昀鰛掾撄粂敽牙稉擎蔍螎葙峬覧絀蹔抆惫冧笻哜搀澐芯譶辍澮垝黟偞媄童竽梀韠镰猳閺狌而羶喙伆杇婣唆鐤諽鷍鴞駫搶毤埙誖萜愿旖鞰萗勹鈱哳垬濅鬒秀瞛洆认気狋異闥籴珵仾氙熜謋繴茴晋髭杍嚖熥勳縿餅珝爸擸萿

Параметры настройки в верхней части программы, которую я использовал для этого, были: 19, 19, 4, 4, 3, 10, 11, 1000, 1000. Я также закомментировал первое определение number_assigned и кодов и раскомментировал последние определения из них, чтобы выбрать унифицированный набор символов CJK.

файлы изображений и исходный код Python (версии 1 и 2)

Версия 1 Вот моя первая попытка. Я буду обновлять, как я иду.

Я получил логотип SO до 300 символов почти без потерь. Моя техника использует преобразование в векторную графику SVG, поэтому она лучше всего работает с штриховой графикой. Это на самом деле компрессор SVG, он все еще требует оригинального искусства пройти этап векторизации.

Для своей первой попытки я использовал онлайн-сервис для трассировки PNG, однако есть МНОГИЕ бесплатные и несвободные инструменты, которые могут обрабатывать эту часть, включая potrace (с открытым исходным кодом).

Вот результаты

Оригинальный логотип SO http://www.warriorhut.org/graphics/svg_to_unicode/so-logo.png Оригинальный логотип SO http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded.png После кодирования и декодирование

Персонажи : 300

Время : не измерено, но практически мгновенно (не включая этапы векторизации / растеризации)

Следующим этапом будет внедрение 4 символов (точки пути SVG и команды) на символ юникода. На данный момент моя сборка Python не имеет поддержки широких символов UCS4, которая ограничивает мое разрешение на символ. Я также ограничил максимальный диапазон нижним пределом зарезервированного диапазона Юникода 0xD800, однако, как только я создаю список разрешенных символов и фильтр, чтобы избежать их, я теоретически могу выдвинуть необходимое количество символов до 70-100 для логотип выше.

Ограничением этого метода в настоящее время является то, что размер вывода не является фиксированным. Это зависит от количества векторных узлов / точек после векторизации. Автоматизация этого предела потребует либо пикселизации изображения (что устраняет основное преимущество векторов), либо повторного прохождения путей через стадию упрощения до тех пор, пока не будет достигнуто желаемое количество узлов (что я сейчас делаю вручную в Inkscape).

Версия 2

ОБНОВЛЕНИЕ : v2 теперь квалифицирован, чтобы конкурировать. Изменения:

• Командная строка управления вводом / выводом и отладкой
• Использует синтаксический анализатор XML (lxml) для обработки SVG вместо регулярных выражений
• Упаковывает 2 сегмента пути на символ Юникод
• Документация и уборка
• Поддержка стиля = "fill: color" и fill = "color"
• Ширина / высота документа упакованы в один символ
• Цвет пути упакован в один символ
• Сжатие цветов достигается путем отбрасывания 4 битов цветовых данных на цвет, а затем упаковкой их в символ с помощью шестнадцатеричного преобразования.

Персонажи : 133

Время : несколько секунд

декодирование v2 http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded-v2.png после кодирования и декодирования (версия 2)

Как вы видите, на этот раз есть некоторые артефакты. Это не ограничение метода, а ошибка где-то в моих конверсиях. Артефакты возникают, когда точки выходят за пределы диапазона 0,0–127,0, и мои попытки их ограничить имели смешанный успех. Решение состоит в том, чтобы просто уменьшить изображение, однако у меня возникли проблемы с масштабированием реальных точек, а не матрицы или артборда, и я слишком устал, чтобы беспокоиться. Короче говоря, если ваши очки находятся в поддерживаемом диапазоне, это обычно работает.

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

ОБНОВЛЕНИЕ : Этот метод подходит для простых объектов, поэтому мне нужен был способ упростить сложные пути и уменьшить шум. Я использовал Inkscape для этой задачи. Мне повезло с выделением ненужных путей с помощью Inkscape, но у меня не было времени попробовать его автоматизировать. Я сделал несколько примеров svgs, используя функцию Inkscape «Simplify», чтобы уменьшить количество путей.

Упрощение работает хорошо, но это может быть медленным с таким количеством путей.

Пример автотрассировка http://www.warriorhut.org/graphics/svg_to_unicode/autotrace_16_color_manual_reduction.png Cornell поле http://www.warriorhut.com/graphics/svg_to_unicode/cornell_box_simplified.png лена http://www.warriorhut.com/graphics /svg_to_unicode/lena_std_washed_autotrace.png

прослежены эскизы http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_autotrace.png

Вот несколько снимков с ультра низким разрешением. Они были бы ближе к пределу в 140 символов, хотя может потребоваться и некоторое умное сжатие пути.

Ухоженный http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_groomed.png Упрощенный и с пестрыми краями.

trianglulated http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_triangulated.png Упрощенный, пятнистый и триангулированный.

autotrace --output-format svg --output-file cornell_box.svg --despeckle-level 20 --color-count 64 cornell_box.png

ВЫШЕ: упрощенные пути с использованием автотрассировки .

К сожалению, мой синтаксический анализатор не обрабатывает вывод автотрассировки, поэтому я не знаю, как могут использоваться точки или насколько их упростить, к сожалению, у меня мало времени для написания этого до истечения срока. Это намного проще, чем анализ inkscape.

Мое полное решение можно найти на http://caca.zoy.org/wiki/img2twit . Он имеет следующие особенности:

• Разумное время сжатия (около 1 минуты для высокого качества)
• Быстрая декомпрессия (доли секунды)
• Сохраняет исходный размер изображения (не только соотношение сторон)
• Достойное качество реконструкции (ИМХО)
• Длина сообщения и набор символов (ASCII, CJK, символы) могут быть выбраны во время выполнения
• Длина сообщения и набор символов определяются автоматически во время распаковки
• Очень эффективная упаковка информации

http://caca.zoy.org/raw-attachment/wiki/img2twit/so-logo.png http://caca.zoy.org/raw-attachment/wiki/img2twit/twitter4.png

蜥 秓 鋖 筷 聝 诿 缰 偺 腶 漷 庯 祩 皙 靊 谪 獜 岨 幻 寤 厎 趆 脘 搇 梄 踥 桻 理 戂 溥 欇 渹 裏 軱 骿 苸 髙 骟 市 簶 璨 粭 浧 鱉 捕 弫 潮 衍 蚙 瀹 岚玧 霫 鏓 蓕 戲 債 鼶 襋 躻 弯 袮 足 庭 侅 旍 凼 飙 驅 據 嘛 掔 倾 诗 籂 阉 嶹 婻 椿 糢 墤 渽 緛 赐 更 儅 棫 武 婩 縑 逡 荨 璙 杯 翉 珸 齸 陁 颗 鳣 憫擲 舥 攩 寉 鈶 兓 庭 璱 篂 鰀 乾 丕 耓 庁 錸 努 樀 肝 亖 弜 喆 蝞 躐 葌 熲 谎 蛪 曟 暙 刍 镶 媏 嘝 驌 慸 盂 氤 缰 殾 譑

Вот приблизительный обзор процесса кодирования:

• Количество доступных битов вычисляется из желаемой длины сообщения и используемой кодировки
• Исходное изображение сегментируется на столько квадратных ячеек, сколько позволяют доступные биты.
• На каждую ячейку влияет фиксированное количество точек (в настоящее время 2) с начальными координатами и значениями цвета
• Следующее повторяется до тех пор, пока не будет выполнено условие качества:
  • Точка выбирается случайной
  • В этой точке операция выполняется случайным образом (перемещение внутри ячейки, изменение ее цвета)
  • Если полученное изображение (см. Процесс декодирования ниже) ближе к исходному изображению, операция сохраняется
• Размер изображения и список точек закодированы в UTF-8

И это процесс декодирования:

• Размер изображения и точки считываются из потока UTF-8
• Для каждого пикселя в целевом изображении:
  • Список естественных соседей вычисляется
  • Окончательный цвет пикселя устанавливается как средневзвешенное значение цветов его естественных соседей.

То, что я считаю самой оригинальной частью программы, это битовый поток. Вместо упаковки значений, выровненных по битам ( stream <<= shift; stream |= value), я упаковываю произвольные значения, не входящие в диапазоны степеней двух ( stream *= range; stream += value). Это требует больших вычислений и, конечно, намного медленнее, но при использовании 20902 основных символов CJK я получаю 2009,18 бит вместо 1960 (это еще три пункта, которые я могу добавить в данные). И при использовании ASCII он дает мне 917,64 бит вместо 840.

Я выбрал метод для первоначального вычисления изображения, который потребовал бы тяжелого вооружения (обнаружение углов, выделение объектов, количественное определение цвета ...), потому что сначала я не был уверен, что это действительно поможет. Теперь я понимаю, что конвергенция медленная (допустима 1 минута, но тем не менее медленная), и я могу попытаться улучшить ее.

Основной цикл подгонки слабо связан с алгоритмом дизеринга Direct Binary Seach (где пиксели случайным образом меняются местами или переворачиваются до тех пор, пока не будет получен лучший полутон). Вычисление энергии представляет собой простое среднеквадратичное расстояние, но сначала я выполняю медианный фильтр 5x5 для исходного изображения. Размытие по Гауссу, вероятно, лучше отражает поведение человеческого глаза, но я не хотел терять острые края. Я также отказался от имитации отжига или других трудно настраиваемых методов, потому что у меня нет месяцев на калибровку процесса. Таким образом, флаг «качества» просто представляет количество итераций, которые выполняются в каждой точке до окончания кодирования.

http://caca.zoy.org/raw-attachment/wiki/img2twit/Mona_Lisa_scaled.jpg http://caca.zoy.org/raw-attachment/wiki/img2twit/twitter2.png

苉 憗 揣 嶕 繠 剳 腏 篮 濕 茝 霮 墧 蒆 棌 杚 蓳 縳 樟 赒 肴 飗 噹 砃 燋 任 朓 峂 釰 靂 陴 貜 犟 掝 喗 讄 荛 砙 矺 敨 鷾 瓔 亨 髎 芟 氲 簵 鸬 嫤 鉸 俇激 躙 憮 鄴 甮 槺 骳 佛 愚 猪 駪 惾 嫥 綖 珏 矯 坼 堭 颽 箽 赭 飉 訥 偁 箝 窂 蹻 熛 漧 衆 橼 愀 航 玴 毡 裋 頢 羔 恺 墎 嬔 鑹 楄 瑥 鶼 呍 蕖 抲 鸝 秓苾 绒 酯 嵞 脔 婺 污 囉 酼 俵 菛 琪 棺 则 辩 曚 鸸 職 銛 蒝 礭 鱚 蟺 稿 纡 醾 陴 鳣 尥 蟀 惘 鋁 髚 忩 祤 脤 养 趯 沅 况

Несмотря на то, что не все изображения хорошо сжимаются, я удивлен результатами, и мне действительно интересно, какие существуют другие методы, которые могут сжимать изображение до 250 байт.

У меня также есть небольшие фильмы об эволюции состояния кодера из случайного начального состояния и из «хорошего» начального состояния .

Изменить : вот как метод сжатия сравнивается с JPEG. Слева - изображение выше 536-байтового изображения. Справа Мона Лиза сжала до 534 байтов, используя метод, описанный здесь (байты, упомянутые здесь, ссылаются на байты данных, поэтому игнорируя биты, потраченные впустую с использованием символов Unicode):

http://caca.zoy.org/raw-attachment/wiki/img2twit/minimona.jpg http://caca.zoy.org/raw-attachment/wiki/img2twit/minimona2.png

Редактировать : просто заменил текст CJK на новейшие версии изображений.

Следующее не является формальным представлением, так как мое программное обеспечение никоим образом не было приспособлено для указанной задачи. DLI может быть описан как оптимизирующий кодек изображения с потерями общего назначения. Это держатель записей PSNR и MS-SSIM для сжатия изображений, и я подумал, что было бы интересно посмотреть, как он справляется с этой конкретной задачей. Я использовал предоставленное эталонное изображение Моны Лизы и уменьшил его до 100x150, затем использовал DLI, чтобы сжать его до 344 байтов.

Мона Лиза DLI http://i40.tinypic.com/2md5q4m.png

Для сравнения со сжатыми образцами JPEG и IMG2TWIT я использовал DLI для сжатия изображения до 534 байтов. Размер файла JPEG составляет 536 байтов, а IMG2TWIT - 534 байта. Изображения были увеличены до примерно одинакового размера для удобства сравнения. JPEG является левым изображением, IMG2TWIT является центром, а DLI является правым изображением.

Сравнение http://i42.tinypic.com/302yjdg.png

Изображение DLI удается сохранить некоторые черты лица, в частности, знаменитую улыбку :).

Общий обзор моего решения:

1. Я начну с подсчета максимального количества необработанных данных, которые можно уместить в 140 символов utf8.
   • (Я предполагаю, что utf8 - это то, на чем исходный веб-сайт утверждал, что твиттер хранил свои сообщения. Это отличается от формулировки проблемы выше, которая запрашивает utf16.)
   • Используя этот utf8 faq , я вычисляю, что максимальное количество битов, которые вы можете кодировать одним символом utf8, составляет 31 бит. Для этого я бы использовал все символы в диапазоне U-04000000 - U-7FFFFFFF. (1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, есть 31 x, поэтому я мог бы кодировать до 31 бита).
   • 31 бит, умноженный на 140 символов, равен 4340 битам. Разделите это на 8, чтобы получить 524,5, и округлите это до 542 байтов .
   • (Если мы ограничимся utf16, то мы можем хранить только 2 байта на символ, что будет равно 280 байтов).
2. Сожмите изображение, используя стандартное сжатие JPG.
   • Измените размер изображения примерно до 50x50px, затем попытайтесь сжать его с различными уровнями сжатия, пока у вас не будет изображения, максимально приближенного к 542 байтам, без перебора.
   • Это пример того, как mona lisa сжимается до 536 байтов.
3. Кодируйте необработанные биты сжатого изображения в символы utf-8.
   • Замените каждый x в следующих байтах: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, битами из изображения.
   • Эта часть, вероятно, будет той частью, где большая часть кода должна быть написана, потому что в настоящее время не существует ничего, что могло бы сделать это.

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

Я думаю, что главное преимущество моего предлагаемого решения заключается в том, что оно использует как можно больше существующих технологий. Может быть интересно попытаться написать хороший алгоритм сжатия, но там наверняка найдется лучший алгоритм, скорее всего, написанный людьми, имеющими высшее образование по математике.

Еще одно важное замечание заключается в том, что если решено, что utf16 является предпочтительной кодировкой, то это решение рушится. JPEG действительно не работает при сжатии до 280 байт. Хотя, может быть, есть лучший алгоритм сжатия, чем jpg для этой конкретной задачи.

Хорошо, я опоздал на игру, но тем не менее я сделал свой проект.

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

Особенности:

• чистый Луа. Работает везде, где работает интерпретатор Lua.
• использует формат netpbm P3
• поставляется с полным набором юнит-тестов
• сохраняет исходный размер изображения

Mis-feautres:

• медленный
• при этих ограничениях пространства он сохраняет только базовую цветовую схему исходного изображения и общую схему нескольких его признаков.

Вот пример твика, который представляет Лену:岂 掂 戇 耔 攋 斘 眐 奡 萛 狂 昸 箆 亲 嬎 廙 栃 兡 塅 受 橯 恰 应 戞 优 猫 僘 瑩 吱 賾 卣 朸 杈 腠 綍 蝘 猕 屐 稱 悡 ​​詬 來 噩 压 罍 尕 熚 帤 厥 虤 嫐虲 兙 罨 縨 炘 排 叁 抠 堃 從 弅 慌 螎 熰 標 宑 簫 柢 橙 拃 丨 蜊 缩 昔 儻 舭 勵 癳 冂 囤 璟 彔 榕 兠 摈 侑 蒖 孂 埮 槃 姠 璐 哠 眛 嫡 琠 枀 訜 苄 暬厇 廩 焛 瀻 严 啘 刱 垫 仔

Код находится в репозитории Mercurial на bitbucket.org. Проверьте http://bitbucket.org/tkadlubo/circles.lua

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

Основная идея позади меня заключается в следующем:

1. Уменьшите частоту серого, чтобы получить 16 разных оттенков.
2. Преформа RLE на изображении
3. Упакуйте результаты в символы UTF-16
4. Предварительно сформируйте RLE для упакованных результатов, чтобы удалить любое дублирование символов

Оказывается, это работает, но только в ограниченной степени, как вы можете видеть из примеров изображений ниже. Что касается вывода, то ниже приводится пример твита, специально для изображения Лены, показанного в примерах.

乤 乤 万 乐 唂 伂 倂 倁 企 儂 2 企 倁 3 企 倁 2 企 伂 8 企 伂 3 企 伂 5 企 倂 倃 伂 倁 3 企 儁 企 2 伂 倃 5 企 倁 3 企 倃 4 企 倂 企 倁 企伂 2 企 伂 5 企 倁 企 伂 쥹 皗 鞹 鐾 륶 䦽 阹 럆 䧜 椿 籫 릹 靭 욶 옷뎷 歩 㰷 歉 䴗 鑹 㞳 鞷 㬼 獴 鏙 돗 鍴 祳 㭾 뤶 殞 焻 乹 Ꮛ 靆 䍼

Как видите, я попытался немного ограничить набор символов; Однако я столкнулся с проблемами при сохранении данных о цвете изображения. Кроме того, эта схема кодирования также имеет тенденцию тратить кучу бит данных, которые могут быть использованы для дополнительной информации изображения.

С точки зрения времени выполнения, для маленьких изображений код очень быстрый, около 55 мс для предоставленных образцов изображений, но время увеличивается с большими изображениями. Для эталонного изображения 512x512 Lena время работы составило 1182 мс. Я должен отметить, что вероятность того, что сам код не очень оптимизирован для производительности (например, все работает как растровое изображение) ), поэтому после некоторого рефакторинга время может немного снизиться.

Пожалуйста, не стесняйтесь предлагать мне какие-либо предложения о том, что я мог бы сделать лучше или что может быть не так с кодом. Полный список времени выполнения и пример выходных данных можно найти по следующему адресу : http://code-zen.info/twitterimage/

Обновите Один

Я обновил код RLE, используемый при сжатии строки твита, чтобы сделать базовый просмотр и, если это так, использовать его для вывода. Это работает только для пар числовых значений, но сохраняет пару символов данных. Время работы примерно такое же, как и качество изображения, но твиты, как правило, немного меньше. Я буду обновлять таблицу на веб-сайте после завершения тестирования. Ниже приведен пример строки твита, опять же для маленькой версии Lena:

乤 乤 万 乐 唂 伂 倂 倁 企 儂 2 企 倁 3 企 倁 ウ 伂 8 企 伂 エ 伂 5 企 倂 倃 伂 倁 グ 儁 企 2 伂 倃 ガ 倁 ジ 倃 4 企 倂 企 倁 企 伂 ツ 伂 ス 倁企 伂 쥹 皗 鞹 鐾 륶 䦽 阹 럆 䧜 椿 籫 릹 靭 욶 옷뎷 歩 㰷 歉 䴗 鑹 㞳 鞷 㬼 獴 鏙 돗 鍴 祳 㭾 뤶 殞 焻 乹 Ꮛ 靆 䍼

Обновление Два

Еще одно небольшое обновление, но я изменил код, чтобы упаковать цветовые оттенки в группы по три, а не в четыре. Это занимает немного больше места, но если я что-то упустил, это должно означать, что «нечетные» символы больше не появляются там, где цвет данные есть. Кроме того, я обновил сжатие немного больше, чтобы оно теперь могло воздействовать на всю строку, а не только на блок подсчета цветов. Я все еще тестирую времена выполнения, но они кажутся номинально улучшенными; однако качество изображения остается прежним. Далее следует новейшая версия твита Лены:

2 乤 万 乐 唂 伂 倂 倁 企 儂 2 企 倁 3 企 倁 ウ 伂 8 企 伂 エ 伂 5 企 倂 倃 伂 倁 グ 儁 企 2 伂 倃 ガ 倁 ジ 倃 4 企 倂 企 倁 企 伂 ツ 伂 ス 倁企 伂 坹 坼 坶 坻 刾 啩 容 力 吹 婩 媷 劝 圿 咶 坼 妛 啭 奩 嗆 婣 冷 咛 啫 凃 奉 佶 坍 均 喳 女 媗 决 兴宗 喓 夽 兴 唹 屹 冷 圶 埫 奫 唓 坤 喝 奎 似商 嗉 乃

Логотип StackOverflow http://code-zen.info/twitterimage/images/stackoverflow-logo.bmp Cornell Box http://code-zen.info/twitterimage/images/cornell-box.bmp Лена http: // code-zen .info / twitterimage / images / lena.bmp Мона Лиза http://code-zen.info/twitterimage/images/mona-lisa.bmp

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

http://rogeralsing.com/2008/12/07/genetic-programming-evolution-of-mona-lisa/

Была бы интересная программа для реализации, но я ее пропущу.

В исходном задании ограничение размера определяется как то, что Twitter по-прежнему позволяет отправлять, если вы вставите свой текст в их текстовое поле и нажмете «обновить». Как некоторые люди правильно заметили, это отличается от того, что вы можете отправить в виде SMS-сообщения со своего мобильного телефона.

Что конкретно не упоминается (но мое личное правило было таковым), так это то, что вы должны иметь возможность выбирать твит-сообщение в своем браузере, копировать его в буфер обмена и вставлять в поле ввода текста вашего декодера, чтобы оно могло отображать его. Конечно, вы также можете свободно сохранить сообщение в виде текстового файла и прочитать его обратно или написать инструмент, который обращается к API Twitter и отфильтровывает любое сообщение, похожее на код изображения (кто-нибудь особые метки? Wink wink ). Но правило состоит в том, что сообщение должно пройти через Twitter, прежде чем вам разрешат его расшифровать.

Удачи с 350 байтами - я сомневаюсь, что вы сможете использовать их.

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

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

Добавьте немного сжатия к вышеупомянутому, и это могло бы начать выглядеть жизнеспособным ...

Ницца!!! Теперь вы, ребята, пробудили во мне интерес. Никакая работа не будет сделана до конца дня ...

Относительно кодирования / декодирования часть этой задачи. base16b.org - моя попытка указать стандартный метод для безопасного и эффективного кодирования двоичных данных в более высоких плоскостях Unicode.

Некоторые особенности:

• Использует только частные области пользователя Unicode
• Кодирует до 17 бит на символ; почти в три раза эффективнее, чем Base64
• Ссылочная реализация Javascript кодирования / декодирования предоставляется
• Некоторые примеры кодирования включены, в том числе Twitter и Wordpress

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

Идея хранения набора эталонных изображений интересна. Было бы так неправильно хранить, скажем, 25 МБ образцов изображений, и чтобы кодировщик пытался составить изображение, используя их биты? При таком маленьком канале аппарат на каждом конце по необходимости будет намного больше, чем объем передаваемых данных, так в чем же разница между 25 МБ кода и 1 МБ кода и 24 МБ данных изображения?

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

Глупая идея, но sha1(my_image)приведет к «идеальному» представлению любого изображения (игнорируя столкновения). Очевидная проблема заключается в том, что процесс декодирования требует чрезмерного количества перебора.

1-битный монохромный будет немного проще. Каждый пиксель становится 1 или 0, поэтому у вас будет 1000 бит данных для изображения размером 100 * 100 пикселей. Поскольку хэш SHA1 составляет 41 символ, мы можем вписать три в одно сообщение, нужно только перебрать 2 набора по 3333 бита и один набор из 3334 (хотя даже это, вероятно, все еще не соответствует)

Это не совсем практично. Даже с 1-битным 100 * 100px изображением фиксированной длины есть .., если я не ошибаюсь, 49995000 комбинаций или 16661667 при разделении на три.

def fact(maxu):
        ttl=1
        for i in range(1,maxu+1):
                ttl=ttl*i
        return ttl

def combi(setsize, length):
    return fact(length) / (fact(setsize)*fact(length-setsize))

print (combi(2, 3333)*2) + combi(2, 3334)
# 16661667L
print combi(2, 10000)
# 49995000L

Здесь это сжатие хорошо.

http://www.intuac.com/userport/john/apt/

http://img86.imageshack.us/img86/4169/imagey.jpg http://img86.imageshack.us/img86/4169/imagey.jpg

Я использовал следующий пакетный файл:

capt mona-lisa-large.pnm out.cc 20
dapt out.cc image.pnm
Pause

Полученный размер файла составляет 559 байт.

Идея: не могли бы вы использовать шрифт в качестве палитры? Попробуйте разбить изображение на серию векторов, пытаясь описать их комбинацией векторных наборов (каждый символ по сути является набором векторов). Это использование шрифта в качестве словаря. Я мог бы, например, использовать AL для вертикальной линии и - для горизонтальной линии? Просто идея.