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

597

Если картинка стоит 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 балл за фактическое соблюдение всех правил. Эти правила стали немного большими и сложными, поэтому я, вероятно, приму хорошие ответы, в которых одна маленькая деталь ошибочна, но я дам дополнительный балл любому решению, которое действительно следует всем правилам.

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

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

Лена Мона Лиза Cornell Box Логотип StackOverflow

приз

Я предлагаю вознаграждение в 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 для преобразования в него и из него.
Brian Campbell
источник
Не стесняйтесь предлагать предложения по правилам, которые я написал в комментариях; Я, конечно, готов их подправить, если люди чувствуют, что им нужно разъяснение или они слишком завышены.
Брайан Кэмпбелл
6
Вы, вероятно, должны сказать, что загрузка изображения на сервер и размещение на нем URL-адреса недопустимы.
Шей Эрличмен
2
@ Разве я уже не говорил это? «Процесс декодирования может не иметь доступа ни к какому другому выходу процесса кодирования, кроме указанного выше; то есть вы не можете загрузить изображение куда-либо и вывести URL-адрес для загрузки процесса декодирования, или что-нибудь глупое подобное «.
Брайан Кэмпбелл
1
@ Конрад Рудольф Я согласен; Я не имел в виду «глупый» с практической точки зрения (ясно, что весь этот конкурс глуп с практической точки зрения), я имел в виду «глупый» в контексте этого конкурса. Использование URI на самом деле не является алгоритмом сжатия, в смысле теории информации, так как он не позволяет передавать больше информации без простого использования альтернативного канала. Вы могли бы предоставить кодировщику и декодеру большую базу данных изображений и назвать это сжатием, которое работает только для ограниченного набора изображений, но я указал, что вы должны иметь возможность обрабатывать произвольное изображение.
Брайан Кэмпбелл
2
Вот несколько ссылок, по которым я столкнулся, которые могут помочь людям: azillionmonkeys.com/qed/unicode.html для объяснения допустимого диапазона символов Unicode. Обратите внимание, что кодировки UTF - это те, которые могут кодировать весь диапазон Unicode; UCS-4 - это расширенный набор Unicode, а UCS-2 и ASCII - это подмножества. Что касается сжатия, то здесь метод, аналогичный оригинальному сообщению, хотя он позволяет себе 1к, а не 350 байт: screamingduck.com/Article.php?ArticleID=46&Show=ABCE
Брайан Кэмпбелл

Ответы:

244

Хорошо, вот мое: 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.

Боуджум
источник
Вот Это Да! Хорошая работа. Я скептически относился к сжатию фрактальных изображений для таких маленьких изображений, но на самом деле это дает довольно приличные результаты. Это было также довольно легко скомпилировать и запустить.
Брайан Кэмпбелл
1
Спасибо, парни! Сэм, ты имеешь в виду результаты всего с 140 символами CJK? Если это так, то да, вам нужно настроить числа в верхней части. Окончательный размер в битах составляет около log2 (steps_in_x steps_in_y steps_in_red steps_in_green steps_in_blue) * blocks_in_x blocks_in_y + log2 (Maximum_width Maximum_height).
Boojum
Изменить: * * 16 в первом log2 (), который я пропустил. Это для возможных ориентаций.
Boojum
20
У кого-нибудь еще есть твиттер с помощью этого изображения?
DBR
288

файлы изображений и исходный код 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.

SpliFF
источник
2
Отлично! Сначала я хотел создать гибридное векторное решение с острыми краями и гладкими областями, но оно оказалось слишком сложным без использования библиотеки трассировки (которую я не хотел использовать). Я с нетерпением жду возможности увидеть, как далеко вы сможете продвинуться с вашим методом
Сэм Хоцевар
Ницца! Я надеялся, что мы увидим некоторые попытки почти без потерь подходов векторизацией. Это означает, что оно имеет более низкую общность, но более высокое качество для изображений, которые оно покрывает. Хорошо использовать онлайн-сервис для векторизации. Удачи в дальнейшем уменьшении размера!
Брайан Кэмпбелл
Я бы рассматривал сжатие изображений и кодирование символов как два разных шага - техника Сэма кажется оптимальной для кодирования и может быть легко встроена в отдельную программу. Вы получите больше отдачи, сконцентрировавшись на уникальной части вашего решения (то есть на части сжатия) и просто выдав строку битов.
Марк Рэнсом
70
Ух ты. Эти изображения выглядят действительно стильно.
Ринат Абдуллин
199

Мое полное решение можно найти на 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 на новейшие версии изображений.

Сэм Хоцевар
источник
На самом деле мне не нужно иметь возможность запускать код (я поставил часть о его запуске в руководствах, а не в правилах); Я бы предпочел иметь возможность его запускать, но я буду судить об этом больше по качеству изображений, которые вы генерируете, коду и любым интересным трюкам или алгоритмам. Если я хочу запустить его, и для него требуются пакеты, которых у меня нет или я не хочу устанавливать в моей основной системе, я могу просто загрузить экземпляр Amazon EC2 и установить его. Пока вы работаете с библиотеками, упакованными для одного из основных дистрибутивов, я смогу запустить его. Не стесняйтесь использовать CGAL.
Брайан Кэмпбелл
2
Хорошо, вот мое решение (исходный код): caca.zoy.org/browser/libpipi/trunk/examples/img2twit.cpp Моя попытка объяснения и несколько примеров на caca.zoy.org/wiki/img2twit
sam hocevar
2
Мне очень нравится ваше решение. Вы должны попытаться уменьшить количество значений, назначенных для синего канала, так как человеческий глаз не может хорошо распознать синий: nfggames.com/games/ntsc/visual.shtm ; это позволит вам получить больше деталей за счет потери некоторой информации о цвете. Или, возможно, назначить его на зеленый?
rpetrich
5
Хорошая точка зрения. Я попробовал несколько вариантов этой идеи (см. Комментарии перед определением RANGE_X), но не очень тщательно. Как видите, использование 5 значений синего вместо 6 увеличило ошибку чуть меньше, чем использование 7 значений зеленого уменьшило ее. Я не пытался делать оба из лени. Другая проблема, с которой я столкнулся, заключается в том, что у меня не очень хорошая функция ошибок. В настоящее время я использую ∑ (∆r² + ∆g² + ∆b²) / 3, который работает нормально. Я пробовал ∑ (0.299∆r² + 0.587∆g² + 0.114∆b²), основываясь (без физического обоснования) на Y-компоненте YUV, но он был слишком терпимым с синими ошибками. Я постараюсь найти документы по этому вопросу.
Сэм Хоцевар
2
@rpetrich: я изменил программу, чтобы она динамически увеличивала диапазоны r / g / b, пока доступно достаточно битов. Это гарантирует, что мы никогда не тратим больше 13 бит на весь поток битов (но на практике это обычно 1 или 2). И изображения выглядят немного лучше.
Сэм Хоцевар
45

Следующее не является формальным представлением, так как мое программное обеспечение никоим образом не было приспособлено для указанной задачи. 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 удается сохранить некоторые черты лица, в частности, знаменитую улыбку :).

Brian Campbell
источник
6
К сожалению. Вышесказанное следует отнести к Деннису Ли, который представил его изначально. Я просто отредактировал его, чтобы встроить изображения и ссылку на ссылку, которую я нашел в Google. И я должен сказать, вау, я впечатлен сжатием. Я должен буду проверить сжатие DLI.
Брайан Кэмпбелл
1
Кстати, автор DLI упоминает «длительное время обработки». Поскольку я не могу запустить его программное обеспечение, не могли бы вы дать нам приблизительные значения времени сжатия?
Сэм Хоцевар
1
При использовании AMD Athlon64 2,4 ГГц сжатие изображения Мона Лизы 100x150 занимает 38 секунд, а декомпрессии - 6 секунд. Сжатие до 251 байта является более жестким, качество вывода значительно снижается. Используя эталонное изображение Моны Лизы, я уменьшил его до 60x91, затем использовал DLI, чтобы сжать его до 243 байтов (ближайший к 251 без перехода). Это вывод i43.tinypic.com/2196m4g.png Детализация не приближается к 534-байтовому DLI, хотя битрейт был уменьшен только на ~ 50%. Однако структура изображения сохранилась довольно хорошо.
1
Решил упростить сравнение 250-байтовых сжатых выборок. 243-байтовый DLI был масштабирован и помещен рядом с образцом IMG2TWIT. IMG2TWIT слева, DLI справа. Вот изображение i40.tinypic.com/30ndks6.png
1
DLI использует параметр качества, такой как JPEG, поэтому, если требуется целевой выходной размер, необходимо использовать метод проб и ошибок.
21

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

  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 для этой конкретной задачи.

Стивен Маккарти
источник
Я сейчас на работе, но я окончательно внедряю это решение, когда вернусь домой.
Пауло Сантос
2
Из моих экспериментов выяснилось, что UTF-16 - это действительно то, как Twitter считает символы; Символы BMP считаются как 1, а символы более высокой плоскости - как 2. Это не задокументировано, но именно так их счетчик символов JavaScript считается при вводе в поле ввода. Это также упоминается в комментариях в оригинальной теме. Я не пробовал отправлять через API, чтобы увидеть, не сломан ли счетчик; если это так, я обновлю проблему для фактических ограничений. Однако вы вряд ли сможете использовать произвольный UTF-8, поскольку многие из этих более длинных последовательностей, которые вы можете кодировать, не являются допустимым Unicode.
Брайан Кэмпбелл
4
После тестирования с использованием их API выясняется, что они действительно учитывают символы Unicode (кодовые точки), а не единицы кода UTF-16 (это счетчик символов JavaScript, который рассчитывает с помощью UTF-16, поскольку, очевидно, именно это делает метод длины JavaScript) , Таким образом, вы можете получить немного больше информации там; допустимые символы Unicode находятся в диапазоне от U + 0000 до U + 10FFFF (чуть более 20 бит на символ; 2 ^ 20 + 2 ^ 16 возможных значений на символ). UTF-8 позволяет кодировать больше значений, чем разрешено в Юникоде, поэтому, если вы ограничитесь Юникодом, вы можете получить около 350 байт, а не 542.
Брайан Кэмпбелл
3
Эта 536-байтовая Мона Лиза выглядит на удивление хорошо, учитывая экстремальное сжатие!
Крис
3
В настоящее время мы можем кодировать 129 775 различных (назначенных, неконтролируемых, не закрытых) символов Юникода. Если мы ограничимся этим подмножеством, это будет всего 2377 бит или 297 байтов. Код здесь: porg.es/blog/what-can-we-fit-in-140-characters
porges
20

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

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

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

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

Mis-feautres:

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

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

оригинал лена закодирована Лена

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

Тадеуш А. Кадлубовский
источник
2
Потрясающие! Создает аккуратные, художественно выглядящие изображения. Я рад, что люди все еще работают над этим; Было очень весело видеть все разные подходы.
Брайан Кэмпбелл
1
Мне бы хотелось, чтобы это использовалось как прозрачное наложение на оригинал, давая что-то вроде эффекта боке.
Ник Рэдфорд
19

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

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

  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

Rob Z
источник
1
Отлично, спасибо за вход! Оттенки серого на самом деле работают довольно хорошо для большинства из них, хотя Лену немного сложно разобрать. Я искал ваш источник, но получил 404; не могли бы вы убедиться, что он там?
Брайан Кэмпбелл
Проверьте это сейчас, я обновлял сайт, чтобы вы могли поймать меня между обновлениями.
rjzii
Да, я могу скачать его сейчас. Теперь, конечно, мне нужно выяснить, смогу ли я получить Mono для его компиляции.
Брайан Кэмпбелл
Ага! Работая под Mono, я скомпилировал с помощью «gmcs -r System.Drawing TwitterImage.cs Program.cs» и запустил с «mono TwitterImage.exe encode lena.png lena.txt»
Брайан Кэмпбелл,
Круто! Я дважды проверил, чтобы убедиться, что библиотеки, которые я использовал, были перечислены для Mono, но на самом деле я еще не работал с Mono, поэтому я не был уверен, будет ли это или нет.
rjzii
15

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

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

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

CiscoIPPhone
источник
12

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

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

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

Quasimondo
источник
1
Да, я добавил рубрику оценки, которая указывает, что более жесткие ограничения на набор символов предпочтительны, но не обязательны. Я хотел бы иметь правило, которое требует, чтобы сообщения проходили через Twitter в целости и сохранности, но это потребовало бы много проб и ошибок, чтобы выяснить точные детали того, что работает, и я хотел бы оставить некоторую свободу действий для творческого использования кодовое пространство. Таким образом, единственное требование в моем задании - 140 действительных символов Юникода. Кстати, спасибо, что заглянули! Мне действительно нравится ваше решение, и я хочу посмотреть, сможет ли кто-нибудь из кибитцеров улучшить его.
Брайан Кэмпбелл
12

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

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

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

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

Gineer
источник
9
s / peaked / piqued / g
одиннадцать81
1
Мне нравится идея трех изображений, должна быть возможность реализовать такую ​​идею в твиттере, и результат будет довольно хорошим.
Макис
9

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

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

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

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


источник
8

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

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


источник
1
Это было бы хорошо, если у вас есть фиксированный, конечный объем данных в любой конечной точке. Конечно, вам нужно продемонстрировать, что он работает с изображениями, которых нет в обучающем наборе, как любая статистическая проблема естественного языка. Я хотел бы увидеть что-то, что использует статистический подход к кодированию изображений.
Брайан Кэмпбелл
16
Я, например, хотел бы, чтобы Мона Лиза переделала, используя только фан-арт Боба Фетта в качестве источника.
Носредна
Я согласен - фотомозаичный подход, кажется, соответствует правилам и было бы чрезвычайно интересно увидеть, как кто-то нанесет удар.
AndreW
8

Глупая идея, но 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
оборота дбр
источник
10
Проблема с sha1 (my_image) состоит в том, что если вы потратите свое время на грубое форсирование, вы, вероятно, найдете много столкновений, прежде чем найдете реальное изображение; и, конечно, грубое форсирование sha1 практически невозможно с вычислительной точки зрения.
Брайан Кэмпбелл
5
Даже лучше, чем сжатие SHA1: мой алгоритм сжатия "flickr"! Шаг 1: загрузить изображение на Flickr. Шаг 2: опубликовать ссылку на него в твиттере. Tadda! Используется только 15 байтов!
niXar
2
niXar: Нет, правило 3.4: «Процесс декодирования может не иметь доступа ни к какому другому выходу процесса кодирования, кроме указанного выше; то есть вы не можете загрузить изображение куда-либо и вывести URL-адрес для процесса декодирования в скачать, или что-нибудь глупое, как это. "
DBR
6
Я знаю, я был с сарказмом.
niXar
0

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

Maurits
источник