关于Unicode:Twitter图像编码挑战

Twitter image encoding challenge

如果一张图片值1000个字,那么140个字符能容纳多少张图片?

注意:伙计们,就是这样!赏金截止日期到了,经过一番艰难的考虑,我决定布琼姆的加入几乎没有超过萨姆·霍切瓦尔的。一旦我有机会写下,我会发表更详细的笔记。当然,每个人都应该自由地继续提交解决方案并改进解决方案,以供人们投票表决。感谢所有提交和进入的人;我喜欢他们。这对我来说很有趣,我希望这对参赛者和观众来说都很有趣。

我在Twitter上看到了一篇有趣的文章,内容是试图将图片压缩成一条推特评论,其中很多人(以及Reddit上的一条)都对你可以采用的不同方式提出了建议。所以,我认为这将是一个很好的编码挑战;让人们把他们的钱放在他们的嘴上,并展示他们对编码的想法如何在有限的空间中产生更多的细节。

我向你提出一个通用的系统,把图片编码成140个字符的推特信息,然后再把它们解码成一个图片。您可以使用Unicode字符,因此每个字符可以获得8位以上的数据。但是,即使允许使用Unicode字符,也需要将图像压缩到非常小的空间中;这当然是一种有损压缩,因此必须对每个结果的外观进行主观判断。

这是原始作者Quasimondo从他的编码中得到的结果(图像是根据一个创意共享属性非商业许可获得许可的):Mona Lisa

你能做得更好吗?

规则

  • 您的程序必须有两种模式:编码和解码。
  • 编码时:
  • 您的程序必须将您选择的任何合理的光栅图形格式的图形作为输入。我们会说,ImageMagick支持的任何光栅格式都是合理的。
  • 您的程序必须输出一条可以用140个或更少的unicode码点表示的消息;140个码点在U+0000U+10FFFF范围内,不包括非字符(U+FFFEU+FFFFU+n FFFEU+n FFFF,其中n是110十六进制,以及U+FDD0范围内。—U+FDEF和替代码点(U+D800U+DFFF)。它可以以您选择的任何合理编码输出;GNU iconv支持的任何编码都将被认为是合理的,您的平台本机编码或区域设置编码可能是一个不错的选择。有关详细信息,请参阅下面的Unicode说明。
  • 解码时:
  • 程序应该将编码模式的输出作为输入。
  • 您的程序必须以您选择的任何合理格式输出图像,如上所述,但对于输出矢量格式也可以。
  • 图像输出应该是输入图像的近似值;越接近输入图像,效果越好。
  • 解码过程可能无法访问除上述指定输出之外的任何其他编码过程输出;也就是说,您不能将图像上载到某处并输出解码过程要下载的URL,或类似的愚蠢行为。
  • 为了用户界面的一致性,程序的行为必须如下:

  • 您的程序必须是一个脚本,可以使用适当的解释器在平台上设置为可执行,或者是一个可以编译为可执行的程序。
  • 您的程序必须以encodedecode作为第一个参数来设置模式。
  • 您的程序必须以以下一种或多种方式接受输入(如果您实现了采用文件名的输入,则如果缺少文件名,还可以从stdin和stdout读取和写入):

  • 从标准输入中获取输入,在标准输出中生成输出。

    1
    2
    my-program encode <input.png >output.txt
    my-program decode <output.txt >output.png
  • 从第二个参数中名为的文件中获取输入,并在第三个参数中名为的文件中生成输出。

    1
    2
    my-program encode input.png output.txt
    my-program decode output.txt output.png
  • 对于您的解决方案,请发布:
  • 您的完整代码和/或托管在其他地方的指向它的链接(如果代码很长,或者需要编译许多文件,或者其他东西)。
  • 如果代码中没有明显的内容,或者代码很长,人们会对摘要感兴趣,那么可以解释它是如何工作的。
  • 一个示例图像,其中包含原始图像、压缩到的文本以及解码后的图像。
  • 如果你是建立在别人的想法之上,请将它们归为属性。试着对别人的想法进行提炼是可以的,但你必须把它们归为属性。
  • 指南

    这些基本上是可能被打破的规则、建议或评分标准:

  • 美学


    图像文件和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好的。

    时间:不测量,但实际上是即时的(不包括矢量化/光栅化步骤)好的。

    下一步是为每个Unicode字符嵌入4个符号(SVG路径点和命令)。目前,我的python构建没有宽字符支持ucs4,这限制了每个字符的分辨率。我还将最大范围限制在Unicode保留范围0xD800的下端,但是一旦我建立了一个允许的字符列表和一个过滤器来避免它们,我理论上可以将上述徽标所需的字符数推低到70-100。好的。

    目前这种方法的一个局限是输出大小不固定。它取决于矢量化后的矢量节点/点的数量。自动化此限制将需要对图像进行像素化(这会消除向量的主要好处),或者在简化阶段重复运行路径,直到达到所需的节点计数(我目前正在Inkscape中手动执行此操作)。好的。

    版本2好的。

    更新:V2现在有资格参加比赛。变化:好的。

    • 命令行控制输入输出及调试
    • 使用XML解析器(lxml)来处理SVG,而不是regex
    • 每个Unicode符号包2个路径段
    • 文档和清理
    • 支持style="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清理出不必要的路径,但没有时间尝试自动化。我用inkscape的"simplife"函数制作了一些SVG示例,以减少路径的数量。好的。

    Simplify工作正常,但在这么多路径下可能很慢。好的。

    Autotrace示例http://www.warriorhut.org/graphics/svg_to_unicode/autotrace_16_color_manual_reducation.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_到u unicode/competitionu缩略图u autotrace.png好的。

    这是一些超低分辨率的照片。虽然可能还需要一些巧妙的路径压缩,但这些压缩将接近140个字符的限制。好的。

    整理http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_broomed.png简化和取消检查。好的。

    三角化http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_triangulated.png简化、取消检查和三角测量。好的。

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

    上面:使用自动跟踪简化路径。好的。

    不幸的是,我的解析器不处理自动跟踪输出,所以我不知道点是如何使用的,也不知道要简化多远,遗憾的是,在截止日期之前写它的时间很少。不过,解析起来要比Inkscape输出容易得多。好的。好啊。


    好的,这是我的:nanocrunch.cpp和cmakelists.txt文件,用cmake构建它。它的大部分图像处理都依赖magick++imagemagick API。它还需要用于bignum算术的gmp库来进行字符串编码。

    我的解决方案基于分形图像压缩,有一些独特的扭曲。其基本思想是获取图像,将副本缩小到50%,并在不同方向上查找与原始图像中不重叠块相似的块。这个搜索需要一种非常暴力的方法,但这只会使我的修改更容易介绍。

    第一个修改是,我的程序不只是考虑90度的旋转和翻转,而是考虑45度的方向。它是一个更多的位每块,但它极大地帮助图像质量。

    另一件事是存储每个块的每个颜色组件的对比度/亮度调整太贵了。相反,我存储了大量量化的颜色(调色板只有4*4*4=64种颜色),它们只是以某种比例混合。在数学上,这相当于每种颜色的可变亮度和恒定对比度调整。不幸的是,它也意味着没有负对比度来翻转颜色。

    一旦计算出每个块的位置、方向和颜色,它就会将其编码为一个UTF-8字符串。首先,它生成一个非常大的bignum来表示块表中的数据和图像大小。这种方法类似于SamHocevar的解决方案——一种以位置变化为基数的大数字。

    然后,它将其转换为可用字符集大小的基。默认情况下,它充分利用指定的Unicode字符集,减去小于、大于、和号、控制、组合、代理和专用字符。它不漂亮,但很管用。您还可以注释掉默认表并选择可打印的7位ASCII(同样不包括<、>和&;字符)或CJK统一汉字。字符代码可用的表存储一个运行长度,用无效和有效字符交替运行进行编码。

    无论如何,这里有一些图像和时间(在我以前的3.0GHz P4上测量),并在上面描述的完整的指定Unicode集中压缩到140个字符。总的来说,我对结果相当满意。如果我有更多的时间来处理这个问题,我可能会尝试减少解压缩图像的阻塞。不过,我认为这个结果对于极限压缩比来说还是很好的。解压后的图像有点印象派,但我发现它相对容易看到位如何对应于原始图像。

    堆栈溢出徽标(8.6秒进行编码,7.9秒进行解码,485字节):http://i44.tinypic.com/2w7lok1.png

    Lena(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统一汉字

    Sam在评论中询问了如何将此与CJK一起使用。以下是从CJK统一字符集压缩到139个字符的蒙娜丽莎版本:

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

    我用于此操作的程序顶部的调整参数是:19、19、4、4、3、10、11、1000、1000。我还注释了分配的数字和代码的第一个定义,并取消注释了它们的最后一个定义以选择CJK统一字符集。


    我的完整解决方案可以在http://caca.zoy.org/wiki/img2twit上找到。它具有以下特点:

    • 合理的压缩时间(高质量约1分钟)
    • 快速减压(不到一秒钟)
    • 保留原始图像大小(不只是纵横比)
    • 体面重建质量(IMHO)
    • 可以在运行时选择消息长度和字符集(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)。这需要进行bignum计算,当然速度要慢得多,但在使用20902个主要的CJK字符时,它给了我2009.18位,而不是1960位(这是我可以在数据中再加三个点)。当使用ASCII时,它给了我917.64位而不是840位。

    我决定反对一种最初的图像计算方法,这种方法需要重型武器(角检测、特征提取、颜色定量等),因为一开始我不确定它是否真的有用。现在我意识到收敛是缓慢的(1分钟是可以接受的,但是它是缓慢的),我可能会尝试改进这一点。

    主要的拟合循环是松散地从直接二进制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的比较。左边是Jamoes的536字节以上的图片。在右边,蒙娜丽莎使用这里描述的方法压缩到534字节(这里提到的字节是指数据字节,因此忽略了使用Unicode字符浪费的位):

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

    编辑:刚刚用最新版本的图片替换了CJK文本。


    以下不是正式的提交,因为我的软件没有以任何方式为指定的任务定制。DLI可以描述为一种优化的通用有损图像编解码器。它是用于图像压缩的psnr和ms-ssim记录保持器,我想看看它如何执行这个特定的任务会很有趣。我使用提供的参考蒙娜丽莎图像,并将其缩小到100x150,然后使用DLI将其压缩到344字节。

    蒙娜丽莎DLI http://i40.tinypic.com/2md5qdm.png

    为了与jpeg和img2twit压缩的示例进行比较,我还使用dli将图像压缩到534字节。jpeg为536字节,img2twit为534字节。为了便于比较,图像被放大到大致相同的大小。jpeg是左图像,img2twit是中心,dli是右图像。

    比较http://i42.tinypic.com/302yjdg.png

    DLI图像保留了一些面部特征,尤其是著名的微笑:)。


    我的解决方案概述如下:

  • 我首先计算可以容纳140个utf8字符的最大原始数据量。
    • (我假设是utf8,这是原始网站声称twitter存储的信息。这与上面的问题语句不同,后者要求utf16。)
    • 使用这个utf8常见问题解答,我计算出可以用单个utf8字符编码的最大位数是31位。为此,我将使用U-04000000–U-7fffffff范围内的所有字符。(111111 x 10x x x x 10x x x x 10x x x x 10x x x x 10x x x x 10x x x x,共有31个x,因此我最多可以编码31位)。
    • 31位乘以140个字符等于4340位。除以8得到524.5,然后四舍五入到542字节。
    • (如果我们将自己限制为UTF16,那么每个字符只能存储2个字节,相当于280个字节)。
  • 使用标准JPG压缩将图像向下压缩。
    • 将图像的大小调整为大约50x50px,然后尝试在不同的压缩级别对其进行压缩,直到您的图像尽可能接近542字节,而无需进行转换。
    • 这是一个蒙娜丽莎压缩到536字节的例子。
  • 将压缩图像的原始位编码为UTF-8字符。
    • 用图像中的位替换以下字节中的每个X:111111 x 10x x x x 10x x x x 10x x x x 10x x x x 10x x x x。
    • 这部分可能是需要编写大部分代码的部分,因为目前没有任何东西可以做到这一点。
  • 我知道你在要求代码,但我不想花时间来真正地编写代码。我认为一个有效的设计至少可以激励其他人编写代码。

    我认为我提出的解决方案的主要好处是它尽可能地重用现有的技术。尝试编写一个好的压缩算法可能很有趣,但有保证会有一个更好的算法,很可能是由拥有高等数学学位的人编写的。

    另一个重要的注意事项是,如果确定UTF16是首选编码,那么这个解决方案就会分崩离析。当压缩到280字节时,jpeg实际上不起作用。不过,对于这个特定的问题语句,可能有比JPG更好的压缩算法。


    好吧,我迟到了,但我还是做了我的项目。

    这是一个玩具遗传算法,使用半透明的彩色圆圈来重建初始图像。

    特征:

    • 纯卢阿。在Lua解释器运行的任何地方运行。
    • 使用netpbm p3格式
    • 附带一套全面的单元测试
    • 保留原始图像大小

    MIS公司:

    • 缓慢的
    • 在这个空间限制条件下,它只保留初始图像的基本配色方案和少量特征的大致轮廓。

    下面是一个代表Lena的twit示例:犭楊谷杌蒝螦界匘玏扝匮俄归晃客猘摈硰划刀萕码摃斢嘁蜁嚎耂澹簜僨砠偑婊內團揕忈義倨襠凁梡岂掂戇耔攋斘眐奡萛狂昸箆亲嬎廙栃兡塅受橯恰应戞优猫僘瑩吱賾卣朸杈腠綍蝘猕屐稱悡詬來噩压罍尕熚帤厥虤嫐虲兙罨縨炘排叁抠堃從弅慌螎熰標宑簫柢橙拃丨蜊缩昔横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横横棉纱

    original lenaencoded Lena

    代码在bitback.org的mercurial存储库中。查看http://bitback.org/tkadlubo/circles.lua


    下面是我处理这个问题的方法,我必须承认这是一个非常有趣的项目,它绝对超出了我的正常工作范围,并且给了我一些新的东西去了解。

    我的基本思想是:

  • 对图像灰度进行向下采样,总共有16种不同的阴影。
  • 图像上的预成型器
  • 将结果打包成UTF-16字符
  • 在压缩结果上执行rle,以删除任何重复的字符
  • 事实证明,这确实有效,但仅限于从下面的示例图像中可以看到的有限范围。在输出方面,下面是一个示例tweet,专门针对示例中显示的lena图像。

    乤乤万乐唂伂倂倁企儂2企倁3企倁2企伂8企伂3企伂5企倂倃伂倁3企儁企2伂倃5企倁3企倃4企倂企倁企伂2企伂5企倁企伂?皗鞹鐾??阹??椿籫?靭???歩?歉?鑹?鞷?獴鏙?鍴祳??殞焻?乹?靆?

    如您所见,我确实尝试过稍微约束字符集;但是,在存储图像颜色数据时,我遇到了这样做的问题。此外,这种编码方案还倾向于浪费大量可用于附加图像信息的数据位。

    在运行时间方面,对于小图像,代码速度非常快,提供的示例图像大约为55ms,但时间随着大图像的增加而增加。对于512x512 Lena参考图像,运行时间是1182毫秒。我应该注意的是,代码本身的性能没有很好地优化(例如,所有内容都作为位图进行处理),因此经过一些重构之后,时间可能会下降一点。

    请随时为我提供关于我可以做得更好或代码可能有什么问题的任何建议。运行时间和示例输出的完整列表可以在以下位置找到:http://code-zen.info/twitterimage/

    更新一

    我已经更新了在压缩tweet字符串时使用的rle代码来做一个基本的回顾,如果是这样的话,就将其用于输出。这只适用于数值对,但它确实保存了几个字符的数据。运行时间或多或少与图像质量相同,但tweet往往会小一些。完成测试后,我会更新网站上的图表。下面是一个tweet字符串示例,同样适用于小版本的Lena:

    乤乤万乐唂伂倂倁企儂2企倁3企倁ウ伂8企伂エ伂5企倂倃伂倁グ儁企2伂倃ガ倁ジ倃4企倂企倁企伂ツ伂ス倁企伂?皗鞹鐾??阹??椿籫?靭???歩?歉?鑹?鞷?獴鏙?鍴祳??殞焻?乹?靆?

    更新二

    另一个小的更新,但是我修改了代码,将颜色阴影分为三组,而不是四组,这会使用更多的空间,但是除非我遗漏了一些东西,否则这意味着"奇数"字符不再出现在颜色数据所在的位置。另外,我对压缩进行了更多的更新,这样它就可以作用于整个字符串,而不仅仅是颜色计数块。我仍在测试运行时间,但它们在名义上似乎得到了改进;但是,图像质量仍然是相同的。下面是最新版本的Lena tweet:

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

    StackOverflow徽标http://code-zen.info/twitterimage/images/stackOverflow-logo.bmp康奈尔盒子http://code-zen.info/twitterimage/images/cornell-box.bmp莉娜http://code-zen.info/twitterimage/images/lena.bmp蒙娜丽莎http://code-zen.info/twitterimage/images/mona-lisa.bmp


    罗杰·阿尔辛写的这种遗传算法具有很好的压缩比,但压缩时间长。使用有损或无损算法可以进一步压缩顶点的矢量。

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

    这是一个很有意思的程序,但我会错过的。


    张贴单色或灰度图像应该可以提高图像的大小,可以编码到该空间,因为你不关心颜色。

    可能会增加上传三张图片的挑战,当重新组合时,会给你一张全彩的图片,同时在每个单独的图片中保持一个单色版本。

    在上面添加一些压缩,它会开始看起来可行…

    好极了!!!!现在你们激发了我的兴趣。这一天剩下的时间里不会有任何工作……


    在最初的挑战中,大小限制被定义为如果你将你的文本粘贴到他们的文本框中并按下"更新",Twitter仍然允许你发送什么。正如一些人正确地注意到的那样,这与您可以通过手机发送的短信息不同。

    没有明确提到的是(但我的个人规则是),你应该能够在浏览器中选择推特信息,将其复制到剪贴板上,并粘贴到解码器的文本输入字段中,以便显示。当然,你也可以自由地将消息保存为文本文件,然后重新读取或编写一个访问TwitterAPI的工具,并过滤掉任何看起来像图像代码的消息(特殊标记任何人?眨眼眨眼但是规则是在你被允许解码之前,信息必须通过Twitter。

    祝你在350字节上好运-我怀疑你是否能利用它们。


    关于这个挑战的编码/解码部分。base16b.org是我试图指定一种标准方法,用于在更高的Unicode平面中安全有效地编码二进制数据。

    一些特点:

    • 仅使用Unicode的专用用户区域
    • 每个字符最多可编码17位;效率几乎是base64的三倍
    • 提供了编码/解码的参考javascript实现
    • 包括一些示例编码,包括twitter和wordpress

    抱歉,这个答案对于最初的比赛来说太晚了。我独立于这篇文章开始了这个项目,我在其中发现了一半。


    这里的压缩效果很好。

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

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

    我使用了以下批处理文件:

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

    结果文件大小为559字节。


    愚蠢的想法,但是sha1(my_image)会导致任何图像的"完美"表示(忽略碰撞)。明显的问题是解码过程需要大量的暴力强制。

    1位单色会更容易一点。每个像素变为1或0,因此对于100*100像素的图像,您将拥有1000位数据。由于sha1散列是41个字符,我们可以在一条消息中放入3个字符,只需强制使用2组3333位和一组3334(尽管这可能仍然不正常)。

    这不太实际。即使使用固定长度的1位100*100px图像,也会有..假设我没有计算错,49995000个组合,或者16661667个,当拆分为三个时。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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


    存储一堆参考图像的想法很有趣。存储25MB的样本图像,让编码器尝试使用这些图像的位组成图像,这样做是错误的吗?有了这样一个微小的管道,两端的机器必然要比通过的数据量大得多,那么25MB的代码和1MB的代码和24MB的图像数据有什么区别呢?

    (请注意,最初的指导原则排除了限制对库中已有图像的输入的限制——我不是建议这样做)。


    想法:你能用字体作为调色板吗?尝试将图像分解成一系列向量,尝试用向量集的组合来描述它们(每个字符本质上都是一组向量)。这是将字体用作词典。例如,我可以用l表示垂直线,用a-表示水平线?只是一个想法。