Twitter圖像編碼挑戰[關閉]

若是一張圖片價值1000字，你能夠在140個字符中放入多少圖片？

注意 ：那就是你們！ 賞金的最後期限就在這裏，通過一番艱難的考慮後，我認爲Boojum的進入只是勉強淘汰Sam Hocevar的 。 一旦我有機會寫下來，我會發布更詳細的筆記。 固然，每一個人都應該隨時繼續提交解決方案並改進人們投票的解決方案。 感謝全部提交和參賽的人; 我很喜歡他們。 這對我來講很是有趣，我但願這對參賽者和觀衆來講都頗有趣。

我遇到了一篇關於嘗試將圖像壓縮成Twitter評論的有趣帖子 ，該線程中的不少人（以及Reddit上的一個帖子 ）都提出了有關不一樣方法的建議。 因此，我認爲這將是一個很好的編碼挑戰; 讓人們將錢放在嘴邊，並展現他們對編碼的見解如何在有限的空間中提供更多細節。

我挑戰你想出一個通用系統，用於將圖像編碼成140個字符的Twitter消息，並將它們再次解碼爲圖像。 您可使用Unicode字符，所以每一個字符的字符數超過8位。 可是，即便容許使用Unicode字符，也須要將圖像壓縮到很是小的空間內; 這確定會是一種有損壓縮，所以必須對每種結果的好看進行主觀判斷。

如下是原做者Quasimondo從他的編碼中得到的結果（圖片根據知識共享署名 - 非商業許可證受權 ）：

你能作得更好嗎？

規則

1. 您的程序必須有兩種模式： 編碼和解碼 。
2. 編碼時 ：
   1. 您的程序必須以您選擇的任何合理光柵圖形格式輸入圖形做爲輸入。 咱們會說ImageMagick支持的任何柵格格式都算合理。
   2. 您的程序必須輸出一條消息，該消息能夠用140個或更少的Unicode代碼點表示; 140個代碼點，範圍爲U+0000 - U+10FFFF ，不包括非字符（ U+FFFE ， U+FFFF ， U+ n FFFE ， U+ n FFFF ，其中n爲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意味着它能夠生成一些圖像的完美複製品，即便對於更大和更復雜的圖像，它也能提供可識別的東西。 或者，它可能不會使圖像具備很強的識別性，但會產生明顯來自原始圖像的精美圖像。
• 聰明地使用Unicode字符集3分
  • 簡單地使用整組容許的字符爲0分
  • 1點使用一組有限的字符，這些字符能夠安全地經過Twitter或更普遍的狀況進行傳輸
  • 使用主題字符子集的2分，例如僅漢字表意文字或僅從右到左字符
  • 作一些很是整潔的事情須要3分，例如生成可讀文本或使用看起來像有問題的圖像的字符
• 聰明的算法方法和代碼風格有3個點
  • 只有1000行代碼的0分才能縮小圖像，將其視爲每像素1位，而base64編碼爲
  • 對於使用標準編碼技術而且寫得很好而且簡短的東西的1分
  • 對於引入相對新穎的編碼技術或者使人驚訝的短而乾淨的東西的2分
  • 實際上能夠產生良好效果的一個襯墊有3個點，或者在圖形編碼方面突破新領域的東西（若是這看起來像是一個不多的分數用於突破新的領域，請記住，這個優勢可能會對美學產生高分以及）
• 2分的速度。 在其餘條件相同的狀況下，速度越快越好，但上述標準都比速度更重要
• 在免費（開源）軟件上運行1分 ，由於我更喜歡免費軟件（請注意，只要它在Mono上運行，C＃仍然符合此要求，若是在GNU Octave上運行，MATLAB代碼也是合格的）
• 實際遵照全部規則的1分 。 這些規則變得有點大而複雜，因此我可能會接受其餘好的答案，這會讓一個小細節錯誤，但我會給任何實際遵循全部規則的解決方案額外的一點

參考圖片

有些人要求提供一些參考圖像。 如下是一些您能夠嘗試的參考圖像; 這裏嵌入了較小的版本，若是您須要，它們都連接到更大版本的圖像：

獎

根據上述標準，我提供了500個表明獎金 （加上StackOverflow推出的50個獎勵 ），用於我最喜歡的解決方案。 固然，我也鼓勵其餘人在這裏投票選出他們最喜歡的解決方案。

關於截止日期的說明

這場比賽將持續到賞金用完，即5月30日星期六下午6點左右。我不能說它將結束的確切時間; 它多是從下午5點到7點。 我保證我會查看下午2點提交的全部參賽做品，我會盡力查看下午4點提交的全部參賽做品; 若是在此以後提交解決方案，我可能沒有機會在我作出決定以前給他們一個公平的見解。 此外，您提交的越早，您投票的機會就越大，能夠幫助我選擇最佳解決方案，所以請儘早提交，而不是在截止日期前提交。

Unicode註釋

到底是什麼容許Unicode字符也存在一些混淆。 可能的Unicode代碼點範圍是U+0000到U+10FFFF 。 在任何開放的數據交換中，有一些代碼點永遠沒法用做Unicode字符; 這些都是noncharacters和代理代碼點 。 Noncharacters在所定義的Unidode標準5.1.0節16.7爲值U+FFFE ， U+FFFF ， U+ Ñ FFFE ， U+ Ñ FFFF ，其中n爲1 - 10十六進制和範圍U+FDD0 - U+FDEF 。 這些值旨在用於特定於應用程序的內部使用，而且符合要求的應用程序可能會將這些字符從它們處理的文本中刪除。 代理點代碼點在Unicode標準5.1.0第3.8節中定義爲U+D800 - U+DFFF ，用於編碼UTF-16中基本多語言平面以外的字符; 所以，不可能直接在UTF-16編碼中表示這些代碼點，而且在任何其餘編碼中對它們進行編碼是無效的。 所以，爲了本次比賽的目的，我將容許任何編碼圖像的程序從U+0000 - U+10FFFF範圍內不超過140個Unicode代碼點的序列，不包括上面定義的全部非字符和代理對。

我更喜歡只使用指定字符的解決方案，甚至更喜歡使用指定字符的聰明子集或使用他們使用的字符集作一些有趣事情的解決方案。 有關指定字符的列表，請參閱Unicode字符數據庫 ; 請注意，某些字符是直接列出的，而有些字符僅列爲範圍的開頭和結尾。 另請注意，代理代碼點列在數據庫中，但如上所述是禁止的。 若是您但願利用字符的某些屬性來使輸出的文本更有趣，則可使用各類字符信息數據庫 ，例如命名代碼塊列表和各類字符屬性 。

因爲Twitter沒有指定他們支持的確切字符集，所以我會對那些實際上不適用於Twitter的解決方案感到寬容，由於某些字符會計算額外的或某些字符被剝離。 優選但不要求全部編碼輸出應該可以經過Twitter或其餘微博服務（例如identi.ca）無損地傳輸。 我已經看到一些文檔聲明Twitter實體編碼<，>和＆，所以分別計算爲4個，4個和5個字符，但我沒有本身測試過，他們的JavaScript字符計數器彷佛沒有以那種方式來統計他們。

提示和連接

• 規則中有效Unicode字符的定義有點複雜。 選擇單個字符塊，例如CJK統一表意文字（U + 4E00-U + 9FCF）可能更容易。
• 您可使用現有的圖像庫（如ImageMagick或Python Imaging Library ）進行圖像處理。
• 若是您須要一些幫助來理解Unicode字符集及其各類編碼，請參閱本快速指南或有關Linux和Unix中UTF-8的詳細常見問題解答 。
• 越早得到解決方案，我（以及其餘人投票）就必須有更多時間來查看它。 若是您改進了解，您能夠編輯解決方案; 當我最後一次查看解決方案時，我將以最新版本爲基礎。
• 若是你想要一個簡單的圖像格式來解析和寫（而且不想只使用現有的格式），我建議使用PPM格式 。 它是一種基於文本的格式，很是易於使用，您可使用ImageMagick進行轉換。

---

#1樓

這種壓縮很好。

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個字節。

---

#2樓

關於此挑戰的編碼/解碼部分。 base16b.org是我嘗試指定一種標準方法，用於在更高的Unicode平面中安全有效地編碼二進制數據。

一些功能：

• 僅使用Unicode的私有用戶區
• 每一個字符最多可編碼17位; 效率幾乎是Base64的三倍
• 提供了編碼/解碼的參考Javascript實現
• 包括一些示例編碼，包括Twitter和Wordpress

對不起，這個答案對於原始比賽來講太晚了。 我獨立於這篇文章開始了這個項目，我在其中發現了一半。

---

#3樓

好吧，我已經遲到了，但不過我作了個人項目。

這是一種玩具遺傳算法，它使用半透明的彩色圓圈來重建初始圖像。

特徵：

• 純淨的Lua。 運行Lua解釋器運行的任何地方。
• 使用netpbm P3格式
• 附帶一套全面的單元測試
• 保留原始圖像大小

誤的feautres：

• 慢
• 在該空間限制下，它僅保留初始圖像的基本顏色方案和其幾個特徵的通常輪廓。

這是一個表明莉娜的例子：犭楊谷杌蒝螦匘匘匱匱匱匱匱刀刀刀刀刀刀刀嚎嚎嚎嚎嚎嚎嚎嚎嚎嚎嚎婊婊婊婊婊婊婊婊婊婊婊襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠襠豈掂戇耔攋斘眐奡萛狂昸箆親嬎廙栃兡塅受橯恰應戞優貓僘瑩吱賾卣朸杈腠綍蝘獼屐稱悡詬來噩壓罍尕熚帤厥虤嫐虲兙罨縨炘排叄摳堃從弅慌螎熰標宑簫柢橙拃丨蜊縮昔儻舭勵癳冂囤璟彔榕兠擯侑蒖孂埮槃姠璐哠眛嫡琠枀訜苄暬厇廩焛瀻嚴啘刱墊仔

該代碼位於bitbucket.org的Mercurial存儲庫中。 查看http://bitbucket.org/tkadlubo/circles.lua

---

#4樓

想法：你能用字體做爲調色板嗎？ 嘗試在一系列向量中打破圖像，試圖用向量集的組合來描述它們（每一個字符本質上是一組向量）。 這是使用字體做爲字典。 例如，我可使用al做爲垂直線，使用 - 做爲水平線？ 只是一個想法。

---

#5樓

個人解決方案的通常概述是：

1. 我首先計算能夠容納140個utf8字符的最大原始數據量。
   • （我假設utf8，這是原始網站聲稱twitter存儲它的消息。這不一樣於上面的問題陳述，它要求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是首選編碼，那麼這個解決方案就會崩潰。 壓縮到280字節時，jpegs不能正常工做。 雖然，對於這個特定的問題陳述，可能有比jpg更好的壓縮算法。