Изображение Твиттера, кодирующее [закрытую] проблему

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

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

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

Прекрасно !!! Теперь вы, ребята, пробудили мой интерес. Остаток дня работы производиться не будут ...

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

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

Общий обзор моего решения был бы следующим:

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 байтам).
     • Измените размер изображения примерно до 50x50 пикселей, затем попытайтесь сжать его с различными уровнями сжатия до тех пор, пока не получите изображение размером как можно ближе к 542 байтам, не переходя при этом.
     • Это пример Мона Лиза сжата до 536 байт.
   • Кодировать необработанные биты сжатого изображения в символы UTF-8.
     • Замените каждый x в следующих байтах: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx битами из изображения.
     • Эта часть, вероятно, была бы той частью, где нужно было бы написать большую часть кода, потому что в настоящее время нет ничего, что могло бы делать это.

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

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

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

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

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

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

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

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

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

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

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

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

Размер изображения и список точек закодированы в UTF-8

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

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

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

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

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

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 байт.

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

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

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

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

Mona Lisa DLI http://i40.tinypic.com/2md5q4m.png

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

файлы изображений и исходный код 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"
• Ширина / высота документа, упакованные в один символ
• Цвет пути, упакованный в один символ
• Сжатие цвета достигается с помощью Автоматизация этого ограничения потребует либо пикселизации изображения (что устраняет основное преимущество векторов), либо повторного прохождения путей через этап упрощения до тех пор, пока не будет достигнуто желаемое количество узлов (что я сейчас делаю вручную в Inkscape).

  Версия 2

  ОБНОВЛЕНИЕ : v2 теперь подходит для участия в соревнованиях. Изменения:

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

    Версия 2

    ОБНОВЛЕНИЕ : v2 теперь подходит для участия в соревнованиях. Изменения:

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

      Версия 2

      ОБНОВЛЕНИЕ : v2 теперь допущена к участию. Изменения:

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

        Версия 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', чтобы уменьшить количество путей.

        Simplify работает нормально, но может работать медленно с таким количеством путей.

        Пример autotrace http: //www.warriorhut. org / graphics / svg_to_unicode / autotrace_16_color_manual_reduction.png Корнелл-бокс http://www.warriorhut.com/graphics/svg_to_unicode/cornell_box_simplified.png lena http://www.warriorhut.com/traas_unicodel/ .png

        эскизы, отслеживаемые http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_autotrace.png[1235 visibleHere ' s несколько снимков в сверхнизком разрешении. Это будет ближе к ограничению в 140 символов, хотя может потребоваться и некоторое умное сжатие пути.

        подготовлено http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_groomed.png Упрощенный и без пятен.

        триангулированный 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.

The following is my approach to the problem and I must admit that this was quite an interesting project to work on, it is definitely outside of my normal realm of work and has given me a something new to learn about.

The basic idea behind mine is as follows:

1. Down-sample the image gray-scale such that there were a total of 16 different shades
2. Preform RLE on the image
3. Pack the results into the UTF-16 characters
4. Preform RLE on the packed results to remove any duplication of characters

It turns out that this does work, but only to a limited extent as you can see from the sample images below. In terms of output, what follows is a sample tweet, specifically for the Lena image shown in the samples.

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

As you can see, I did try and constrain the character set a bit; however, I ran into issues doing this when storing the image color data. Also, this encoding scheme also tends to waste a bunch of bits of data that could be used for additional image information.

In terms of run times, for small images the code is extremely fast, about 55ms for the sample images provided, but the time does increase with larger images. For the 512x512 Lena reference image the running time was 1182ms. I should note that the odds are pretty good that the code itself isn't very optimized for performance (e.g. everything is worked with as a Bitmap) so the times could go down a bit after some refactoring.

Please feel free to offer me any suggestions on what I could have done better or what might be wrong with the code. The full listing of run times and sample output can be found at the following location: http://code-zen.info/twitterimage/

Update One

I've updated the the RLE code used when compressing the tweet string to do a basic look back and if so so use that for the output. This only works for the number value pairs, but it does save a couple of characters of data. The running time is more or less the same as well as the image quality, but the tweets tend to be a bit smaller. I will update the chart on the website as I complete the testing. What follows is one of the example tweet strings, again for the small version of Lena:

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

Update Two

Another small update, but I modified the code to pack the color shades into groups of three as opposed to four, this uses some more space, but unless I'm missing something it should mean that "odd" characters no longer appear where the color data is. Also, I updated the compression a bit more so it can now act upon the entire string as opposed to just the color count block. I'm still testing the run times, but they appear to be nominally improved; however, the image quality is still the same. What follows is the newest version of the Lena tweet:

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

StackOverflow Logo http://code-zen.info/twitterimage/images/stackoverflow-logo.bmp Cornell Box http://code-zen.info/twitterimage/images/cornell-box.bmp Lena http://code-zen.info/twitterimage/images/lena.bmp Mona Lisa http://code-zen.info/twitterimage/images/mona-lisa.bmp

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

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 байт.

Поскольку область x является локальной для функции stupid (). как только вы вызываете функцию и она завершается, вы выходите из ее области видимости, и вы печатаете значение «x», которое определено вне функции stupid () - и x, который определен внутри функции stupid () больше не существует в стеке (после того, как эта функция завершится)

отредактируйте после вашего комментария:

external x упоминается, когда вы печатаете его, как и вы сделал.

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

О «глобальном»

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

  Некоторые функции:

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

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

Okay, I'm late to the game, but nevertheless I made my project.

It's a toy genetic algorithm that uses translucent colorful circles to recreate the initial image.

Features:

• pure Lua. Runs anywhere where a Lua interpreter runs.
• uses netpbm P3 format
• comes with a comprehensive suite of unit tests
• preserves original image size

Mis-feautres:

• slow
• at this space constraints it preserves only the basic color scheme of the initial image and a general outline of few features thereof.

Here's an example twit that represents Lena: 犭楊谷杌蒝螦界匘玏扝匮俄归晃客猘摈硰划刀萕码摃斢嘁蜁嚎耂澹簜僨砠偑婊內團揕忈義倨襠凁梡岂掂戇耔攋斘眐奡萛狂昸箆亲嬎廙栃兡塅受橯恰应戞优猫僘瑩吱賾卣朸杈腠綍蝘猕屐稱悡詬來噩压罍尕熚帤厥虤嫐虲兙罨縨炘排叁抠堃從弅慌螎熰標宑簫柢橙拃丨蜊缩昔儻舭勵癳冂囤璟彔榕兠摈侑蒖孂埮槃姠璐哠眛嫡琠枀訜苄暬厇廩焛瀻严啘刱垫仔

The code is in a Mercurial repository at bitbucket.org. Check out http://bitbucket.org/tkadlubo/circles.lua