Проблема кодування зображень Twitter [закрита]

Якщо малюнок вартує 1000 слів, на скільки зображень ви можете вмістити 140 символів?

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

Я натрапив на цей цікавий пост про спробу стиснення зображень до коментаря у Twitter, і багато людей із цієї теми (та нитки на Reddit ) мали пропозиції щодо різних способів, як це можна зробити. Отже, я вважаю, що це може стати гарним завданням кодування; дозвольте людям покласти свої гроші туди, де є рот, і покажіть, як їхні уявлення про кодування можуть призвести до більш детальної інформації в обмеженому просторі, яке у вас є.

Я закликаю вас придумати систему загального призначення для кодування зображень у повідомлення 140 Twitter із символів та знову їх декодування у зображення. Ви можете використовувати символи Unicode, тому ви отримуєте більше 8 біт на символ. Однак, навіть допускаючи символи Unicode, вам потрібно буде стиснути зображення в дуже невеликому просторі; це, безумовно, призведе до стиснення втрат, і тому доведеться суб'єктивно оцінювати, наскільки добре виглядає кожен результат.

Ось результат, який отримав оригінальний автор, Quasimondo , від його кодування (зображення ліцензоване за ліцензією Creative Commons Attribution-некомерційна ):

Ви можете зробити краще?

Правила

1. Ваша програма повинна мати два режими: кодування та декодування .
2. При кодуванні :
   1. Ваша програма повинна приймати як введення графіку у будь-якому розумному растровому графічному форматі на ваш вибір. Ми скажемо, що будь-який растровий формат, підтримуваний ImageMagick, вважається розумним.
   2. Ваша програма повинна вивести повідомлення, яке може бути представлено у 140 або менших кодових точках Unicode; 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 бал за використання обмеженого набору символів, безпечних для передачі через Twitter або в різних ситуаціях
  • 2 бали за використання тематичної підмножини символів, таких як лише ідеографи Хана або лише символи справа наліво
  • 3 бали за те, що ви робите щось по-справжньому охайне, як-от генерувати текст, прочитаний чи використовуючи символи, схожі на зображення
• 3 бали за розумні алгоритмічні підходи та стиль коду
  • 0 балів за те, що становить 1000 рядків коду, щоб лише зменшити масштаб зображення, розглянути його як 1 біт на піксель та базовий код 64
  • 1 бал за те, що використовує стандартну техніку кодування та добре написане та коротке
  • 2 бали за те, що впроваджує порівняно нову техніку кодування, або це напрочуд коротко і чисто
  • 3 бали за один вкладиш, який фактично дає хороші результати або щось, що порушує нову основу в графічному кодуванні (якщо це здається низькою кількістю балів за прорив нового ґрунту, пам’ятайте, що результат цього товару, ймовірно, матиме високий бал за естетику так само)
• 2 бали за швидкість. За інших рівних ситуацій швидше - краще, але вищезазначені критерії важливіші за швидкість
• 1 бал для запуску вільного програмного забезпечення (з відкритим кодом), тому що я віддаю перевагу вільному програмному забезпеченню (зауважте, що C # як і раніше буде придатним до цього пункту, поки він працює на Mono; аналогічно, код MATLAB був би придатним, якщо він працює на GNU Octave)
• 1 бал за фактичне дотримання всіх правил. Ці правила стали трохи великими і складними, тому я, мабуть, прийму хороші відповіді в іншому випадку, якщо одна маленька деталь буде неправильною, але я дам додаткову точку будь-якому рішенню, яке насправді дотримується всіх правил

Довідкові зображення

Деякі люди попросили довідкові зображення. Ось кілька довідкових зображень, які ви можете спробувати; Тут вбудовані менші версії, усі вони посилаються на більші версії зображення, якщо вам потрібні:

Приз

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

Примітка про термін

Цей конкурс триватиме до виграшу щедрості, близько 18:00 у суботу, 30 травня. Я не можу сказати точного часу, коли він закінчиться; він може бути десь від 5 до 19 вечора. Я гарантую, що я перегляну всі записи, подані до 14:00, і зроблю все можливе, щоб переглянути всі записи, подані до 16:00; якщо після цього будуть подані рішення, я, можливо, не маю шансу надати їм справедливий вигляд, перш ніж приймати своє рішення. Крім того, чим раніше ви подасте заявку, тим більше шансів на голосування матимете змогу допомогти мені вибрати найкраще рішення, тож спробуйте подати раніше, а не правильно в крайній термін.

Примітки Unicode

Була також деяка плутанина щодо того, які саме символи Unicode дозволено Діапазон можливих точок коду Unicode - U+0000до U+10FFFF. Є деякі точки коду, які ніколи не можна використовувати як символи Unicode при будь-якій відкритій обміні даними; це нехарактерні та сурогатні кодові точки . 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 Standard 5.1.0 як U+D800- U+DFFF, використовуються для кодування символів, що перебувають за межами базової багатомовної площини в UTF-16; таким чином, неможливо представити ці кодові точки безпосередньо в кодуванні UTF-16, і кодування їх у будь-якому іншому кодуванні недійсне. Таким чином, для цього конкурсу я дозволю будь-яку програму, яка кодує зображення в послідовності не більше 140 кодів Unicode з діапазону U+0000- U+10FFFFза винятком усіх нехарактерних та сурогатних пар, як визначено вище.

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

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

Поради та посилання

• Визначення дійсних символів Unicode у правилах дещо складне. Вибір одного блоку символів, наприклад, CJK Unified Ideographs (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. По-перше, він генерує дуже великий бінум для представлення даних у блок-таблиці та розміру зображення. Підхід до цього схожий на рішення Сема Хочевара - різновид великої кількості з радіацією, що змінюється залежно від положення.

Потім він перетворює це в базу будь-якого розміру наявного набору символів. За замовчуванням він повністю використовує призначений набір символів unicode, мінус менше, більше, ніж, амперсанд, керування, поєднання та сурогатних та приватних символів. Це не дуже, але це працює. Ви також можете прокоментувати таблицю за замовчуванням і вибрати замість неї 7-бітний ASCII для друку (знову виключаючи <,> та & символи) або CJK Unified Ideographs. У таблиці, в якій доступні коди символів, зберігається довжина виконання, закодована з чергуванням прогонів недійсних та дійсних символів.

У будь-якому випадку, ось декілька зображень та часів (як виміряно на моєму старому PG 3,0 ГГц), і стиснуто до 140 символів у повному призначеному наборі унікоду, описаному вище. В цілому я досить задоволений тим, як у них все вийшло. Якби у мене було більше часу на роботу над цим, я, мабуть, спробував би зменшити блокадність декомпресованих зображень. Тим не менш, я думаю, що результати є досить хорошими для надзвичайного коефіцієнта стиснення. Декомпресовані зображення трохи імпресіоністичні, але мені здається порівняно легко зрозуміти, як біти відповідають оригіналу.

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

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

Mona Lisa (43,2s для кодування, 14,5s для декодування, 490 байт):
http://i41.tinypic.com/ekgwp3.png http://i43.tinypic.com/ngsxep.png

Редагувати: Уніфіковані символи CJK

Сем запитав у коментарях щодо використання цього з CJK. Ось версія Mona Lisa, стиснута до 139 символів із набору символів CJK Unified:

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

Параметри налаштування у верхній частині програми, яку я використовував для цього, були: 19, 19, 4, 4, 3, 10, 11, 1000, 1000. Я також прокоментував перше визначення числа_призначений і кодів і прокоментував останні їх визначення для вибору набору символів CJK Unified.

файли зображень та джерело 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, що обмежує мою роздільну здатність на персонаж. Я також обмежив максимальний діапазон до нижнього кінця зарезервованого діапазону Unicode 0xD800, однак, коли я будую список дозволених символів та фільтр, щоб уникнути їх, я теоретично можу підсунути необхідну кількість символів до рівня 70-100 для логотип зверху.

На сьогодні обмеження цього способу полягає в тому, що розмір виводу не фіксований. Це залежить від кількості векторних вузлів / точок після векторизації. Автоматизація цього ліміту вимагатиме або пікселяції зображення (що видаляє головну перевагу векторів), або повторного проходження контурів через етап спрощення, поки не буде досягнуто потрібного числа вузлів (що я зараз роблю вручну в Inkscape).

Версія 2

ОНОВЛЕННЯ : v2 тепер кваліфікована для змагання. Зміни:

• Контрольний вхід / вихід та налагодження в командному рядку
• Використовує XML-аналізатор (lxml) для обробки SVG замість регулярного вираження
• Пакує 2 сегменти шляху на символ unicode
• Документація та очищення
• Стиль підтримки = "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 'спростити', щоб зменшити кількість шляхів.

Спростити працює нормально, але це може бути повільним з цим багатьма шляхами.

Приклад автоматичного відстеження http://www.warriorhut.org/graphics/svg_to_unicode/autotrace_16_color_manual_reduction.png cornell box http://www.warriorhut.com/graphics/svg_to_unicode/cornell_box_simplified.png lena http://www.warriorhut.com/graphics /svg_to_unicode/lena_std_washed_autotrace.png

ескізи простежуються http://www.warriorhut.org/graphics/svg_to_unicode/comcharge_thumbnails_autotrace.png

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

groomed http://www.warriorhut.org/graphics/svg_to_unicode/comcharge_thumbnails_groomed.png Спрощений і зневірений.

трикутник http://www.warriorhut.org/graphics/svg_to_unicode/comcharge_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, Symbols) можна вибрати під час виконання
• Довжина повідомлення та набір символів автоматично визначаються під час декомпресії
• Дуже ефективна упаковка інформації

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). Для цього потрібні обчислення бінтуму, і, звичайно, набагато повільніше, але це дає мені 2009.18 біт замість 1960 року, коли використовуються 20902 основні символи CJK (це ще три моменти, які я можу помістити в дані). А при використанні 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-байтного зображення. Праворуч Mona Lisa стискається до 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 для стиснення зображень, і я подумав, що було б цікаво подивитися, як він виконує цю конкретну задачу. Я використав поданий посилання на зображення Mona Lisa і зменшив його до 100x150, потім застосував DLI для стиснення до 344 байт.

Mona Lisa 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.)
   • Використовуючи цей faq utf8 , я обчислюю, що максимальна кількість бітів, які ви можете кодувати в одному символі 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 байтів, не переходячи.
   • Це приклад стиснення мони лізи до 536 байт.
3. Кодуйте необроблені біти стисненого зображення в символи utf-8.
   • Кожен х замініть на наступні байти: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, бітами із зображення.
   • Ця частина, ймовірно, буде тією частиною, де потрібно було б записати більшість кодів, тому що в даний час немає нічого такого, що це робить.

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

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

Ще одна важлива примітка - це те, що якщо вирішено, що utf16 є кращим кодуванням, то це рішення розпадається. jpegs насправді не працює при стисненні до 280 байт. Хоча, можливо, є кращий алгоритм стиснення, ніж jpg для цієї конкретної постановки проблеми.

Гаразд, я запізнююся на гру, але все-таки я зробив свій проект.

Це іграшковий генетичний алгоритм, який використовує напівпрозорі барвисті кола для відтворення початкового зображення.

Особливості:

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

Міс-феотри:

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

Ось приклад твіт, який представляє Лену: 犭 楊 谷 杌 蒝 螦 界 匘 玏 扝 俄 归 晃 客 猘 摈 硰 划 萕 码 摃 斢 嘁 蜁 嚎 耂 澹 簜 僨 砠 婊 內 團 揕 揕 義 倨 襠 凁 凁岂 掂 戇 耔 攋 斘 眐 奡 萛 狂 昸 箆 亲 廙 栃 兡 塅 受 橯 恰 应 优 猫 僘 瑩 吱 賾 卣 杈 腠 腠 綍 蝘 屐 稱 悡 ​​詬 來 噩 压 罍 尕 熚 熚 熚虲 兙 罨 縨 炘 排 叁 抠 堃 從 弅 慌 螎 標 宑 簫 柢 橙 拃 丨 蜊 昔 儻 舭 勵 癳 冂 囤 彔 榕 榕 兠 摈 蒖 孂 埮 槃 姠 璐 哠 眛 嫡 琠 琠 琠厇 廩 焛 瀻 严 啘 刱 垫 仔

Код знаходиться у сховищі 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 мс. Слід зазначити, що шанси досить хороші, що сам код не дуже оптимізований для продуктивності (наприклад, все працює з Bitmap ), тому час може трохи знизитися після рефакторингу.

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

Оновіть один

Я оновив код RLE, який використовується при стисненні рядка твіт, щоб зробити основний огляд назад, і якщо так, то використайте його для виводу. Це працює лише для пар значень чисел, але це зберігає пару символів. Час роботи приблизно такий же, як і якість зображення, але твіти, як правило, трохи менші. Коли я завершу тестування, я оновлю графік на веб-сайті. Далі - одна з прикладів твітних рядків, знову ж таки для невеликої версії Lena:

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

Оновлення два

Ще одне невелике оновлення, але я змінив код, щоб упакувати кольорові відтінки в три групи на відміну від чотирьох, для цього використовується трохи більше місця, але якщо я щось не пропускаю, це повинно означати, що "непарні" символи більше не з’являються там, де колір дані є. Крім того, я оновив стиснення трохи більше, так що тепер він може діяти на всю рядок на відміну від блоку лише підрахунку кольорів. Я все ще тестую час виконання, але, здається, вони були номінально покращені; однак якість зображення залишається однаковою. Далі йде новітня версія твіту Lena:

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 Lena http: // code-zen .info / twitterimage / images / lena.bmp Mona Lisa http://code-zen.info/twitterimage/images/mona-lisa.bmp

Цей генетичний алгоритм, який написав Роджер Альсінг, має хороший коефіцієнт стиснення за рахунок тривалих часів стиснення. Отриманий вектор вершин можна додатково стиснути за допомогою алгоритму втрат або втрат.

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

Була б цікава програма для реалізації, але я пропущу її.

В оригінальному виклику обмеження розміру визначається як те, що ще дозволяє вам надсилати, якщо вставити текст у їх текстове поле і натиснути «оновити». Оскільки деякі люди правильно помітили, це відрізняється від того, що ви можете надіслати у вигляді SMS-повідомлення з мобільного телефону.

Що конкретно не згадується (але те, що було моїм особистим правилом), це те, що ви маєте змогу вибрати твітне повідомлення у своєму браузері, скопіювати його у буфер обміну та вставити його у поле введення тексту вашого декодера, щоб він міг відобразити його. Звичайно , ви також можете вільно , щоб зберегти повідомлення як текстовий файл і читати його назад або написати інструмент , який отримує доступ до Twitter API і відфільтровує будь-яке повідомлення , яке виглядає як код зображення (спеціальні маркери хто? Подмигивание підморгування ). Але правило полягає в тому, що повідомлення має пройти через Twitter, перш ніж вам дозволять його розшифрувати.

Удачі з 350 байтами - я сумніваюся, що ви зможете ними скористатися.

Опублікування монохромного або відтінку сірого має покращити розмір зображення, яке можна закодувати в цей простір, оскільки вам не важливо колір.

Можливо, посилити завдання для завантаження трьох зображень, які при їх рекомбінації надають повнокольорове зображення, зберігаючи при цьому монохромну версію в кожному окремому зображенні.

Додайте трохи стиснення до вищезазначеного, і це може почати виглядати життєздатним ...

Приємно !!! Тепер ви, хлопці, викликали мій інтерес. Решту дня не буде виконано жодної роботи ...

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

Деякі функції:

• Використовує лише приватні користувальницькі області Unicode
• Кодує до 17 біт на символ; майже втричі ефективніший, ніж Base64
• Надано посилання на реалізацію Javascript кодування / декодування
• Деякі зразки кодування включені, включаючи Twitter та Wordpress

Вибачте, ця відповідь надто пізно виходить для початкового змагання. Я розпочав проект незалежно від цієї посади, яку виявив на півдорозі.

Цікава ідея зберігання купки довідкових зображень. Чи було б таким неправильним зберігати скажімо, 25 Мб зразкових зображень, і кодер спробувати скомпонувати зображення, використовуючи біти цих зображень? З такою мізерною трубою обладнання на будь-якому кінці за необхідністю буде набагато більшим, ніж об'єм даних, що проходять, тож яка різниця між 25Mb коду та 1Mb коду та 24Mb графічних даних?

(зауважте, оригінальні вказівки виключали обмеження введення зображень, які вже є в бібліотеці - я цього не пропоную).

Дурна думка, але 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

Тут ця компресія хороша.

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 для вертикальної лінії, а - для горизонтальної? Просто ідея.