ver una todas portada persona para online muestra las imagenes fotos descargar como carga twitter unicode compression

una - Desafío de codificación de la imagen de Twitter



twitter no carga imagenes 2018 (15)

Bien, aquí está el mío: nanocrunch.cpp y el archivo CMakeLists.txt para construirlo usando CMake. Se basa en la API de Magick++ ImageMagick para la mayor parte de su manejo de imágenes. También requiere la biblioteca GMP para la aritmética bignum para su codificación de cadena.

Basé mi solución en la compresión de imágenes fractales, con unos pocos giros únicos. La idea básica es tomar la imagen, reducir una copia al 50% y buscar piezas en varias orientaciones que se parezcan a bloques no superpuestos en la imagen original. Se requiere un enfoque de fuerza bruta para esta búsqueda, pero eso hace que sea más fácil introducir mis modificaciones.

La primera modificación es que, en lugar de solo observar rotaciones y giros de noventa grados, mi programa también considera orientaciones de 45 grados. Es un bit más por bloque, pero ayuda enormemente a la calidad de la imagen.

La otra cosa es que almacenar un ajuste de contraste / brillo para cada componente de color de cada bloque es demasiado costoso. En cambio, almaceno un color muy cuantificado (la paleta tiene solo 4 * 4 * 4 = 64 colores) que simplemente se mezcla en alguna proporción. Matemáticamente, esto es equivalente a un brillo variable y un ajuste de contraste constante para cada color. Desafortunadamente, también significa que no hay un contraste negativo para cambiar los colores.

Una vez que se calcula la posición, la orientación y el color de cada bloque, se codifica en una cadena UTF-8. Primero, genera un gran valor para representar los datos en la tabla de bloques y el tamaño de la imagen. El enfoque de esto es similar a la solución de Sam Hocevar: una especie de gran número con una raíz que varía según la posición.

Luego lo convierte en una base cualquiera que sea el tamaño del conjunto de caracteres disponible. De forma predeterminada, hace uso completo del conjunto de caracteres Unicode asignado, menos los caracteres menor que, mayor que, comercial, control, combinación y sustituto y privado. No es bonito pero funciona. También puede comentar la tabla predeterminada y seleccionar ASCII de 7 bits imprimible (nuevamente excluyendo <,> y & caracteres) o IJografías Unificadas CJK en su lugar. La tabla de los códigos de caracteres disponibles se almacena una longitud de ejecución codificada con ejecuciones alternas de caracteres no válidos y válidos.

De todos modos, aquí hay algunas imágenes y tiempos (según lo medido en mi antiguo P4 de 3.0GHz), y comprimidos a 140 caracteres en el conjunto completo de Unicode asignado descrito anteriormente. En general, estoy bastante satisfecho con la forma en que resultaron. Si tuviera más tiempo para trabajar en esto, probablemente trataría de reducir el bloqueo de las imágenes descomprimidas. Aún así, creo que los resultados son bastante buenos para la relación de compresión extrema. Las imágenes descomprimidas son poco impresionistas, pero me resulta relativamente fácil ver cómo se corresponden con el original.

Logotipo de desbordamiento de pila (8.6s para codificar, 7.9s para decodificar, 485 bytes):
http://i44.tinypic.com/2w7lok1.png

Lena (32.8s para codificar, 13.0s para decodificar, 477 bytes):
http://i42.tinypic.com/2rr49wg.png http://i40.tinypic.com/2rhxxyu.png

Mona Lisa (43.2s para codificar, 14.5s para decodificar, 490 bytes):
http://i41.tinypic.com/ekgwp3.png http://i43.tinypic.com/ngsxep.png

Edición: CJK personajes unificados

Sam preguntó en los comentarios sobre el uso de esto con CJK. Aquí hay una versión de la Mona Lisa comprimida a 139 caracteres del juego de caracteres Unificado CJK:

http://i43.tinypic.com/2yxgdfk.png隤 慛 絖 銓 馿 渫 櫰 矍 昀 鰛 掾 撄 粂 敽 牙 稉 擎 蔍 螎 葙 峬 覧 絀 蹔 抆 惫 冧 笻 哜 搀 澐 芯 譶 辍 澮 垝 黟 偞 媄 童 竽 梀 韠 镰 猳 閺 狌 而 羶 喙伆 杇 婣 唆 鐤 諽 鷍 鴞 駫 搶 毤 埙 誖 萜 愿 旖 鞰 萗 勹 鈱 哳 垬 濅 鬒 秀 瞛 洆 认 気 狋 異 闥 籴 珵 仾 氙 熜 謋 繴 茴 晋 髭 杍 嚖 熥 勳 縿 餅 珝 爸擸 萿

Los parámetros de ajuste en la parte superior del programa que utilicé para esto fueron: 19, 19, 4, 4, 3, 10, 11, 1000, 1000. También comenté la primera definición de number_assigned y codes, y no comenté la últimas definiciones de ellos para seleccionar el conjunto de caracteres unificado CJK.

Si una imagen vale más que 1000 palabras, ¿qué cantidad de una imagen puede caber en 140 caracteres?

Nota : ¡Eso es todo gente! La fecha límite de recompensa está aquí, y después de una dura deliberación, he decidido que la entrada de Boojum apenas superó a Sam Hocevar . Publicaré notas más detalladas una vez que haya tenido la oportunidad de escribirlas. Por supuesto, todos deben sentirse libres de continuar presentando soluciones y mejorando las soluciones para que las personas voten. Gracias a todos los que presentaron y la entrada; Los disfruté todos. Ha sido muy divertido para mí correr, y espero que haya sido divertido tanto para los participantes como para los espectadores.

Me encontré con esta interesante publicación sobre cómo tratar de comprimir imágenes en un comentario de Twitter, y muchas personas en ese hilo (y un hilo en Reddit ) tuvieron sugerencias sobre las diferentes formas en que podría hacerlo. Entonces, me imagino que sería un buen desafío de codificación; deje que las personas pongan su dinero donde están, y muestre cómo sus ideas sobre la codificación pueden llevar a más detalles en el espacio limitado que tiene disponible.

Lo desafío a que cree un sistema de propósito general para codificar imágenes en mensajes de Twitter de 140 caracteres y decodificarlos en una imagen nuevamente. Puede usar caracteres Unicode, por lo que obtiene más de 8 bits por carácter. Sin embargo, incluso teniendo en cuenta los caracteres Unicode, deberá comprimir las imágenes en una cantidad muy pequeña de espacio; esto ciertamente será una compresión con pérdida, por lo que tendrá que haber juicios subjetivos sobre qué tan bien se ve cada resultado.

Aquí está el resultado que el autor original, Quasimondo , obtuvo de su codificación (la imagen está bajo una licencia Creative Commons Reconocimiento-No comercial ):

¿Puedes hacerlo mejor?

Reglas

  1. Su programa debe tener dos modos: codificación y decodificación .
  2. Al codificar :
    1. Su programa debe tomar como entrada un gráfico en cualquier formato de ráster razonable de su elección. Diremos que cualquier formato raster compatible con ImageMagick cuenta como razonable.
    2. Su programa debe generar un mensaje que se pueda representar en 140 puntos de código Unicode o menos; 140 puntos de código en el rango U+0000 - U+10FFFF , sin incluir caracteres ( U+FFFE , U+FFFF , U+ n FFFE , U+ n FFFF donde n es 1 - 10 hexadecimal y el rango U+FDD0 - U+FDEF ) y puntos de código sustitutos ( U+D800 - U+DFFF ). Puede obtenerse en cualquier codificación razonable de su elección; cualquier codificación admitida por GNU iconv se considerará razonable, y la codificación nativa o la codificación local de su plataforma probablemente sea una buena opción. Vea las notas de Unicode a continuación para más detalles.
  3. Al decodificar :
    1. Su programa debe tomar como entrada la salida de su modo de codificación .
    2. Su programa debe generar una imagen en cualquier formato razonable de su elección, como se definió anteriormente, aunque para los formatos de vectores de salida también están bien.
    3. La salida de la imagen debe ser una aproximación de la imagen de entrada; cuanto más cerca se puede llegar a la imagen de entrada, mejor.
    4. El proceso de decodificación puede no tener acceso a ninguna otra salida del proceso de codificación que no sea la salida especificada anteriormente; es decir, no puede cargar la imagen en algún lugar y generar la URL para que se descargue el proceso de decodificación, o algo tan estúpido como eso.

  4. En aras de la coherencia en la interfaz de usuario, su programa debe comportarse de la siguiente manera:

    1. Su programa debe ser un script que pueda configurarse como ejecutable en una plataforma con el intérprete apropiado, o un programa que pueda compilarse en un ejecutable.
    2. Su programa debe tomar como primer argumento encode o decode para configurar el modo.

    3. Su programa debe ingresar datos de una o más de las siguientes maneras (si implementa el que toma nombres de archivos, también puede leer y escribir desde stdin y stdout si faltan nombres de archivos):

      1. Tome la entrada de la entrada estándar y produzca una salida en la salida estándar.

        my-program encode <input.png >output.txt my-program decode <output.txt >output.png

      2. Tome la entrada de un archivo nombrado en el segundo argumento y produzca una salida en el archivo nombrado en el tercero.

        my-program encode input.png output.txt my-program decode output.txt output.png

  5. Para su solución, por favor publique:
    1. Su código, completo, y / o un enlace a él alojado en otro lugar (si es muy largo, o requiere muchos archivos para compilar, o algo así).
    2. Una explicación de cómo funciona, si no es inmediatamente evidente a partir del código o si el código es largo y la gente estará interesada en un resumen.
    3. Una imagen de ejemplo, con la imagen original, el texto que se comprime y la imagen descodificada.
    4. Si está construyendo sobre una idea que alguien más tuvo, por favor atribúyalos. Está bien intentar hacer un refinamiento de la idea de otra persona, pero debe atribuirla.

Pautas

Estas son básicamente reglas que pueden romperse, sugerencias o criterios de puntuación:

  1. La estética es importante. Estaré juzgando y sugeriré que otras personas juzguen, basándose en:
    1. Qué tan bien se ve la imagen de salida, y qué aspecto tiene la original.
    2. Qué bonito se ve el texto. Si tienes un esquema de compresión realmente inteligente, si quieres tener un esquema de compresión realmente inteligente, también quiero ver respuestas que conviertan las imágenes en poemas multilingües, o algo así. Tenga en cuenta que el autor de la solución original decidió usar solo caracteres chinos, ya que se veía mejor así.
    3. Código interesante y algoritmos inteligentes siempre son buenos. Me gusta el código claro, conciso y claro, pero los algoritmos complicados realmente inteligentes también están bien, siempre y cuando produzcan buenos resultados.
  2. La velocidad también es importante, aunque no tan importante como el buen trabajo de comprimir la imagen que haces. Prefiero tener un programa que pueda convertir una imagen en una décima de segundo que algo que ejecute algoritmos genéticos durante días y días.
  3. Preferiré soluciones más cortas a las más largas, siempre y cuando sean razonablemente comparables en calidad; La concisión es una virtud.
  4. Su programa debe implementarse en un lenguaje que tenga una implementación disponible de forma gratuita en Mac OS X, Linux o Windows. Me gustaría poder ejecutar los programas, pero si tiene una gran solución que solo se ejecuta bajo MATLAB o algo así, está bien.
  5. Su programa debe ser lo más general posible; debería funcionar para tantas imágenes diferentes como sea posible, aunque algunas pueden producir mejores resultados que otras. En particular:
    1. Tener algunas imágenes integradas en el programa con el que coincide y escribe una referencia, y luego produce la imagen correspondiente al descodificar, es bastante escaso y solo cubrirá algunas imágenes.
    2. Un programa que puede tomar imágenes de formas geométricas simples, planas y descomponerlas en algún vector primitivo es bastante ingenioso, pero si falla en imágenes más allá de cierta complejidad, probablemente sea lo suficientemente general.
    3. Un programa que solo pueda tomar imágenes de una relación de aspecto fija particular pero que haga un buen trabajo con ellas también estaría bien, pero no sería lo ideal.
    4. Puede encontrar que una imagen en blanco y negro puede obtener más información en un espacio más pequeño que una imagen en color. Por otro lado, eso puede limitar los tipos de imagen a los que se aplica; Las caras salen bien en blanco y negro, pero los diseños abstractos pueden no ser tan buenos.
    5. Está perfectamente bien si la imagen de salida es más pequeña que la entrada, mientras que es aproximadamente la misma proporción. Está bien si tiene que ampliar la imagen para compararla con la original; Lo importante es cómo se ve.
  6. Su programa debe producir una salida que realmente pueda pasar por Twitter y salir ilesa. Esto es solo una pauta en lugar de una regla, ya que no pude encontrar ninguna documentación sobre el conjunto exacto de caracteres admitidos, pero probablemente debería evitar los caracteres de control, los caracteres de combinación invisibles, los personajes de uso privado y demás.

Rúbrica de puntuación

Como una guía general de cómo clasificaré las soluciones al elegir mi solución aceptada, digamos que probablemente evaluaré las soluciones en una escala de 25 puntos (esto es muy aproximado y no puntuaré nada directamente, solo usaré esto como una pauta básica):

  • 15 puntos por lo bien que el esquema de codificación reproduce una amplia gama de imágenes de entrada. Este es un juicio subjetivo, estético.
    • 0 significa que no funciona en absoluto, devuelve la misma imagen cada vez, o algo así
    • 5 significa que puede codificar algunas imágenes, aunque la versión descodificada parece fea y puede que no funcione en absoluto en imágenes más complicadas
    • 10 significa que funciona en una amplia gama de imágenes y produce imágenes de aspecto agradable que en ocasiones pueden distinguirse
    • 15 significa que produce réplicas perfectas de algunas imágenes, e incluso para imágenes más grandes y complejas, proporciona algo que es reconocible. O tal vez no produce imágenes que sean bastante reconocibles, pero sí produce imágenes hermosas que se derivan claramente del original.
  • 3 puntos para un uso inteligente del conjunto de caracteres Unicode
    • 0 puntos por usar el conjunto completo de caracteres permitidos
    • 1 punto por usar un conjunto limitado de caracteres que son seguros para transferir a través de Twitter o en una variedad más amplia de situaciones
    • 2 puntos por usar un subconjunto temático de caracteres, como solo ideogramas Han o solo caracteres de derecha a izquierda
    • 3 puntos por hacer algo realmente limpio, como generar texto legible o usar caracteres que se parecen a la imagen en cuestión
  • 3 puntos para enfoques algorítmicos inteligentes y estilo de código
    • 0 puntos por algo que es 1000 líneas de código solo para reducir la escala de la imagen, tratarla como 1 bit por píxel y codificar en base64
    • 1 punto por algo que usa una técnica de codificación estándar y está bien escrito y es breve
    • 2 puntos por algo que introduce una técnica de codificación relativamente novedosa, o que es sorprendentemente corto y limpio
    • 3 puntos para una línea que realmente produce buenos resultados, o algo que abre nuevos caminos en la codificación de gráficos (si esto parece ser un número bajo de puntos para abrir nuevos caminos, recuerde que un buen resultado tendrá una alta puntuación en estética también)
  • 2 puntos para la velocidad. Todo lo demás es igual, más rápido es mejor, pero los criterios anteriores son más importantes que la velocidad
  • 1 punto por ejecutar en software libre (de código abierto), porque prefiero el software libre (tenga en cuenta que C # todavía será elegible para este punto siempre que se ejecute en Mono, de manera similar, el código MATLAB sería elegible si se ejecuta en GNU Octave)
  • 1 punto por seguir todas las reglas. Estas reglas se han vuelto un poco grandes y complicadas, por lo que probablemente aceptaré buenas respuestas que tengan un pequeño detalle equivocado, pero le daré un punto adicional a cualquier solución que realmente siga todas las reglas

Imágenes de referencia

Algunas personas han pedido algunas imágenes de referencia. Aquí hay algunas imágenes de referencia que puedes probar; Las versiones más pequeñas están integradas aquí, todas ellas se vinculan a versiones más grandes de la imagen si las necesita:

Premio

Estoy ofreciendo una recompensa de 500 repeticiones (más las 50 que entra en juego StackOverflow) por la solución que más me gusta, según los criterios anteriores. Por supuesto, también animo a todos los demás a votar sobre sus soluciones favoritas aquí.

Nota sobre el plazo

Este concurso se ejecutará hasta que la recompensa se agote, alrededor de las 6 pm del sábado 30 de mayo. No puedo decir la hora exacta en que terminará; puede ser de 5 a 7 de la tarde. Garantizaré que miraré todas las entradas enviadas antes de las 2 PM y haré lo mejor para mirar todas las entradas enviadas antes de las 4 PM; Si después de eso se presentan las soluciones, es posible que no tenga la oportunidad de darles una mirada justa antes de tomar una decisión. Además, cuanto antes realice la presentación, más posibilidades tendrá de votar para poder ayudarme a elegir la mejor solución, así que intente enviarla antes, en lugar de hacerlo en el plazo establecido.

Notas unicode

También ha habido cierta confusión sobre qué se permite exactamente los caracteres Unicode. El rango de posibles puntos de código Unicode es de U+0000 a U+10FFFF . Hay algunos puntos de código que nunca son válidos para usar como caracteres Unicode en cualquier intercambio abierto de datos; estos son los no caracteres y los puntos de código sustituto . Los caracteres no definidos se definen en la sección 16.0 de Unidode Standard 5.1.0 como los valores U+FFFE , U+FFFF , U+ n FFFE , U+ n FFFF donde n es 1 - 10 hexadecimal y el rango U+FDD0 - U+FDEF . Estos valores están destinados a ser utilizados para el uso interno específico de la aplicación, y las aplicaciones conformes pueden eliminar estos caracteres del texto procesado por ellos. Los puntos de código sustitutos, definidos en la sección 3.8 de Unicode Standard 5.1.0 como U+D800 - U+DFFF , se utilizan para codificar caracteres más allá del Plano Multilingüe Básico en UTF-16; por lo tanto, es imposible representar estos puntos de código directamente en la codificación UTF-16, y no es válido codificarlos en cualquier otra codificación. Por lo tanto, para el propósito de este concurso, permitiré que cualquier programa que codifique imágenes en una secuencia de no más de 140 puntos de código Unicode del rango U+0000 - U+10FFFF , excluyendo todos los pares no característicos y sustitutos como se definió anteriormente.

Prefiero soluciones que usen solo caracteres asignados, e incluso mejores que usen subconjuntos inteligentes de caracteres asignados o hagan algo interesante con el conjunto de caracteres que usan. Para obtener una lista de los caracteres asignados, consulte la base de datos de caracteres Unicode ; tenga en cuenta que algunos caracteres se enumeran directamente, mientras que otros se enumeran solo como el inicio y el final de un rango. También tenga en cuenta que los puntos de código sustitutos se enumeran en la base de datos, pero están prohibidos como se mencionó anteriormente. Si desea aprovechar ciertas propiedades de los caracteres para hacer que el texto que imprima sea más interesante, hay una variedad de bases de datos de información de caracteres disponibles, como una lista de bloques de códigos con nombre y varias propiedades de caracteres .

Dado que Twitter no especifica el conjunto de caracteres exacto que admiten, seré indulgente con las soluciones que en realidad no funcionan con Twitter porque ciertos caracteres cuentan extra o se eliminan ciertos caracteres. Es preferible, pero no obligatorio, que todas las salidas codificadas puedan transferirse sin daños a través de Twitter u otro servicio de microblogging como identi.ca . He visto alguna documentación que indica que la entidad de Twitter codifica <,> y &, y por lo tanto cuenta con 4, 4 y 5 caracteres respectivamente, pero no lo he probado yo mismo, y su contador de caracteres de JavaScript no parece Para contarlos de esa manera.

Consejos y enlaces

  • La definición de caracteres Unicode válidos en las reglas es un poco complicada. La elección de un solo bloque de caracteres, como los ideogramas unificados CJK (U + 4E00 – U + 9FCF) puede ser más fácil.
  • Puede usar las bibliotecas de imágenes existentes, como ImageMagick o Python Imaging Library , para la manipulación de su imagen.
  • Si necesita ayuda para comprender el conjunto de caracteres de Unicode y sus diversas codificaciones, consulte esta guía rápida o estas preguntas frecuentes detalladas sobre UTF-8 en Linux y Unix .
  • Cuanto antes obtenga su solución, más tiempo tendré que verla yo (y otras personas que voten). Puedes editar tu solución si la mejoras; Basaré mi recompensa en la versión más reciente cuando analice las soluciones por última vez.
  • Si desea un formato de imagen fácil de analizar y escribir (y no quiere simplemente usar un formato existente), sugeriría usar el formato PPM . Es un formato basado en texto con el que es muy fácil trabajar, y puede usar ImageMagick para convertirlo y devolverlo.

Mi solución completa se puede encontrar en . Tiene las siguientes características:

  • Tiempo de compresión razonable (alrededor de 1 minuto para alta calidad)
  • Descompresión rápida (una fracción de segundo)
  • Mantiene el tamaño de la imagen original (no solo la relación de aspecto)
  • Calidad de reconstrucción decente (IMHO)
  • La longitud del mensaje y el conjunto de caracteres (ASCII, CJK, Símbolos) se pueden elegir en tiempo de ejecución
  • La longitud del mensaje y el conjunto de caracteres se detectan automáticamente en tiempo de descompresión
  • Embalaje de información muy eficiente.

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

蜥 秓 鋖 筷 聝 诿 缰 偺 腶 漷 庯 祩 皙 靊 谪 獜 岨 幻 寤 厎 趆 脘 搇 梄 踥 桻 理 戂 溥 欇 渹 裏 軱 骿 苸 髙 骟 市 簶 璨 粭 浧 鱉 捕 弫 潮 衍 蚙 瀹 岚玧 霫 鏓 蓕 戲 債 鼶 襋 躻 弯 袮 足 庭 侅 旍 凼 飙 驅 據 嘛 掔 倾 诗 籂 阉 嶹 婻 椿 糢 墤 渽 緛 赐 更 儅 棫 武 婩 縑 逡 荨 璙 杯 翉 珸 齸 陁 颗 鳣 憫擲 舥 攩 寉 鈶 兓 庭 璱 篂 鰀 乾 丕 耓 庁 錸 努 樀 肝 亖 弜 喆 蝞 躐 葌 熲 谎 蛪 曟 暙 刍 镶 媏 嘝 驌 慸 盂 氤 缰 殾 譑

Aquí hay una visión general del proceso de codificación:

  • El número de bits disponibles se calcula a partir de la longitud de mensaje deseada y el conjunto de caracteres utilizable
  • La imagen de origen está segmentada en tantas celdas cuadradas como lo permitan los bits disponibles
  • Un número fijo de puntos (actualmente 2) se ve afectado por cada celda, con coordenadas iniciales y valores de color
  • Se repite lo siguiente hasta que se cumpla una condición de calidad:
    • Se elige un punto al azar
    • Se realiza una operación al azar en este punto (moviéndolo dentro de su celda, cambiando su color)
    • Si la imagen resultante (consulte el proceso de decodificación a continuación) está más cerca de la imagen de origen, la operación se mantiene
  • El tamaño de la imagen y la lista de puntos están codificados en UTF-8

Y este es el proceso de decodificación:

  • El tamaño de la imagen y los puntos se leen de la secuencia UTF-8
  • Para cada píxel en la imagen de destino:
    • La lista de vecinos naturales está calculada.
    • El color final del píxel se establece como un promedio ponderado de los colores de sus vecinos naturales.

Lo que creo que es la parte más original del programa es el flujo de bits. En lugar de empaquetar valores alineados en bits ( stream <<= shift; stream |= value ), empaqueté valores arbitrarios que no están en el rango de potencia de dos ( stream *= range; stream += value ). Esto requiere grandes cálculos y, por supuesto, es mucho más lento, pero me da 2009.18 bits en lugar de 1960 cuando se usan los 20902 caracteres principales CJK (eso es tres puntos más que puedo incluir en los datos). Y cuando uso ASCII, me da 917.64 bits en lugar de 840.

Decidí no usar un método para el cálculo de imagen inicial que hubiera requerido armamento pesado (detección de esquinas, extracción de características, cuantificación de color ...) porque al principio no estaba seguro de que realmente ayudaría. Ahora me doy cuenta de que la convergencia es lenta (1 minuto es aceptable pero no obstante, es lenta) y puedo intentar mejorar eso.

El bucle de ajuste principal está inspirado en el algoritmo de tramado Direct Binary Seach (donde los píxeles se intercambian o voltean aleatoriamente hasta obtener un mejor tono medio). El cálculo de energía es una simple distancia raíz cuadrada media, pero primero realizo un filtro de mediana 5x5 en la imagen original. Un desenfoque gaussiano probablemente representaría mejor el comportamiento del ojo humano, pero no quería perder bordes afilados. También decidí rechazar el recocido simulado u otros métodos difíciles de ajustar porque no tengo meses para calibrar el proceso. Por lo tanto, el indicador de "calidad" solo representa el número de iteraciones que se realizan en cada punto antes de que finalice el codificador.

http://caca.zoy.org/raw-attachment/wiki/img2twit/Mona_Lisa_scaled.jpg http://caca.zoy.org/raw-attachment/wiki/img2twit/twitter2.png

苉 憗 揣 嶕 繠 剳 腏 篮 濕 茝 霮 墧 蒆 棌 杚 蓳 縳 樟 赒 肴 飗 噹 砃 燋 任 朓 峂 釰 靂 陴 貜 犟 掝 喗 讄 荛 砙 矺 敨 鷾 瓔 亨 髎 芟 氲 簵 鸬 嫤 鉸 俇激 躙 憮 鄴 甮 槺 骳 佛 愚 猪 駪 惾 嫥 綖 珏 矯 坼 堭 颽 箽 赭 飉 訥 偁 箝 窂 蹻 熛 漧 衆 橼 愀 航 玴 毡 裋 頢 羔 恺 墎 嬔 鑹 楄 瑥 鶼 呍 蕖 抲 鸝 秓苾 绒 酯 嵞 脔 婺 污 囉 酼 俵 菛 琪 棺 则 辩 曚 鸸 職 銛 蒝 礭 鱚 蟺 稿 纡 醾 陴 鳣 尥 蟀 惘 鋁 髚 忩 祤 脤 养 趯 沅 况

Aunque no todas las imágenes se comprimen bien, me sorprenden los resultados y realmente me pregunto qué otros métodos existen que puedan comprimir una imagen a 250 bytes.

También tengo pequeñas películas de la evolución del estado del codificador desde un estado inicial aleatorio y desde un estado inicial "bueno" .

Edición : aquí es cómo el método de compresión se compara con JPEG. A la izquierda, la imagen de 536 bytes por encima de los jamoes. A la derecha, Mona Lisa se comprimió a 534 bytes utilizando el método descrito aquí (los bytes mencionados aquí se refieren a bytes de datos, por lo tanto, ignoran los bits desperdiciados al usar caracteres Unicode):

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

Edición : acaba de reemplazar el texto CJK con las versiones más recientes de las imágenes.

Archivos de imagen y fuente de Python (versión 1 y 2)

Versión 1 Aquí está mi primer intento. Voy a actualizar a medida que avanzo.

Tengo el logotipo SO hasta 300 caracteres casi sin pérdidas. Mi técnica utiliza la conversión al arte vectorial SVG, por lo que funciona mejor en el arte de línea. En realidad, es un compresor SVG, aún requiere que el arte original pase por una etapa de vectorización.

Para mi primer intento, utilicé un servicio en línea para el rastreo de PNG, sin embargo, hay MUCHAS herramientas gratuitas y no gratuitas que pueden manejar esta parte, incluida la potrace (fuente abierta).

Aquí están los resultados

Original SO Logo http://www.warriorhut.org/graphics/svg_to_unicode/so-logo.png Original Decoded SO Logo http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded.png Después de la codificación y descodificación

Personajes : 300

Tiempo : no medido pero prácticamente instantáneo (sin incluir los pasos de vectorización / rasterización)

La siguiente etapa será incrustar 4 símbolos (puntos de ruta SVG y comandos) por carácter Unicode. En este momento, mi compilación de Python no tiene un amplio soporte de caracteres UCS4, lo que limita mi resolución por carácter. También he limitado el rango máximo al extremo inferior del rango reservado de Unicode 0xD800; sin embargo, una vez que construyo una lista de caracteres permitidos y un filtro para evitarlos, puedo empujar teóricamente el número requerido de caracteres tan bajo como 70-100 para el logo de arriba

Una limitación de este método en la actualidad es que el tamaño de salida no es fijo. Depende de la cantidad de nodos / puntos vectoriales después de la vectorización. Automatizar este límite requerirá ya sea pixelar la imagen (lo que elimina el beneficio principal de los vectores) o repetir la ejecución de las rutas a través de una etapa de simplificación hasta que se alcance el recuento de nodos deseado (lo que estoy haciendo manualmente en Inkscape).

Versión 2

ACTUALIZACIÓN : v2 ahora está calificado para competir. Cambios:

  • Control de línea de comandos de entrada / salida y depuración
  • Utiliza el analizador XML (lxml) para manejar SVG en lugar de expresiones regulares
  • Packs 2 segmentos de ruta por símbolo unicode
  • Documentación y limpieza.
  • Estilo de soporte = "relleno: color" y relleno = "color"
  • Ancho / alto del documento empaquetado en un solo carácter
  • Color del camino empaquetado en un solo carácter.
  • La compresión de color se logra al desechar 4 bits de datos de color por color y luego empaquetarlos en un personaje mediante conversión hexadecimal.

Personajes : 133

Tiempo : unos segundos.

V2 descodificado http://www.warriorhut.org/graphics/svg_to_unicode/so-logo-decoded-v2.png Después de la codificación y decodificación (versión 2)

Como puedes ver, hay algunos artefactos esta vez. No es una limitación del método, sino un error en alguna parte de mis conversiones. Los artefactos suceden cuando los puntos van fuera del rango 0.0 - 127.0 y mis intentos de restringirlos han tenido un éxito mixto. La solución es simplemente reducir la imagen, sin embargo, tuve problemas para escalar los puntos reales en lugar de la mesa de trabajo o la matriz de grupo y ahora estoy demasiado cansado para preocuparme. En resumen, si sus puntos están en el rango admitido, generalmente funciona.

Creo que la torcedura en el medio se debe a un mango que se mueve al otro lado de un mango al que está vinculado. Básicamente, los puntos están demasiado juntos en primer lugar. Ejecutar un filtro simplificado sobre la imagen de origen antes de comprimirlo debería solucionar este problema y eliminar algunos caracteres innecesarios.

ACTUALIZACIÓN : este método está bien para objetos simples, así que necesitaba una forma de simplificar rutas complejas y reducir el ruido. Utilicé Inkscape para esta tarea. He tenido un poco de suerte con la preparación de rutas innecesarias utilizando Inkscape, pero no he tenido tiempo de intentar automatizarlo. He hecho algunos svgs de muestra utilizando la función ''Simplificar'' de Inkscape para reducir el número de rutas.

Simplificar funciona bien, pero puede ser lento con tantos caminos.

Ejemplo de autotrace 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

miniaturas rastreadas http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_autotrace.png

Aquí hay algunos tiros de ultra baja resolución. Estos estarían más cerca del límite de 140 caracteres, aunque también es posible que se necesite una compresión de ruta inteligente.

acicalado http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_groomed.png Simplificado y descartado.

trianglulado http://www.warriorhut.org/graphics/svg_to_unicode/competition_thumbnails_triangulated.png Simplificado, marcado y triangulado.

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

ARRIBA: autotrace simplificadas utilizando autotrace .

Desafortunadamente, mi analizador no maneja la salida de seguimiento automático, por lo que no sé cómo se pueden usar los puntos o cuánto simplificar, lamentablemente hay poco tiempo para escribirlos antes de la fecha límite. Sin embargo, es mucho más fácil de analizar que la salida de inkscape.

De acuerdo, llego tarde al juego, pero sin embargo hice mi proyecto.

Es un algoritmo genético de juguete que utiliza círculos coloridos translúcidos para recrear la imagen inicial.

caracteristicas:

  • Lua pura. Se ejecuta en cualquier lugar donde se ejecuta un intérprete de Lua.
  • utiliza el formato netpbm P3
  • viene con un conjunto completo de pruebas unitarias
  • conserva el tamaño de la imagen original

Mis-feautres:

  • lento
  • en este espacio, conserva solo el esquema de color básico de la imagen inicial y un esquema general de algunas de sus características.

Aquí hay un ejemplo de mierda que representa a Lena:岂 掂 戇 耔 攋 斘 眐 奡 萛 狂 昸 箆 亲 嬎 廙 栃 兡 塅 受 橯 恰 应 戞 优 猫 僘 瑩 吱 賾 卣 朸 杈 腠 綍 蝘 猕 屐 稱 悡 ​​詬 來 噩 压 罍 尕 熚 帤 厥 虤 嫐虲 兙 罨 縨 炘 排 叁 抠 堃 從 弅 慌 螎 熰 標 宑 簫 柢 橙 拃 丨 蜊 缩 昔 儻 舭 勵 癳 冂 囤 璟 彔 榕 兠 摈 侑 蒖 孂 埮 槃 姠 璐 哠 眛 嫡 琠 枀 訜 苄 暬廩

El código está en un repositorio de Mercurial en bitbucket.org. Echa un vistazo a http://bitbucket.org/tkadlubo/circles.lua

El siguiente es mi enfoque del problema y debo admitir que este fue un proyecto bastante interesante para trabajar, definitivamente está fuera de mi ámbito normal de trabajo y me ha dado algo nuevo para aprender.

La idea básica detrás de la mía es la siguiente:

  1. Realice una muestra de abajo de la imagen en escala de grises de manera que haya un total de 16 tonos diferentes
  2. Preforma RLE en la imagen
  3. Empaque los resultados en los caracteres UTF-16
  4. Preforme RLE en los resultados empaquetados para eliminar cualquier duplicación de caracteres

Resulta que esto funciona, pero solo hasta cierto punto, como se puede ver en las imágenes de muestra a continuación. En términos de resultados, lo que sigue es un tweet de muestra, específicamente para la imagen de Lena que se muestra en las muestras.

乤乤儂儂企倁企倁倃2 5 企 倁

Como puedes ver, intenté restringir un poco el conjunto de caracteres; sin embargo, tuve problemas al hacer esto al almacenar los datos de color de la imagen. Además, este esquema de codificación también tiende a desperdiciar un montón de bits de datos que podrían utilizarse para obtener información adicional de la imagen.

En términos de tiempos de ejecución, para imágenes pequeñas el código es extremadamente rápido, aproximadamente 55 ms para las imágenes de muestra proporcionadas, pero el tiempo aumenta con imágenes más grandes. Para la imagen de referencia de 512x512 de Lena, el tiempo de ejecución fue de 1182 ms. Debo tener en cuenta que las probabilidades son bastante buenas de que el código en sí no esté muy optimizado para el rendimiento (p. Ej., Todo se trabaja como un Bitmap ), por lo que los tiempos podrían disminuir un poco después de algunas refactorizaciones.

No dude en ofrecerme alguna sugerencia sobre lo que podría haber hecho mejor o qué podría estar mal con el código. La lista completa de tiempos de ejecución y resultados de muestra se puede encontrar en la siguiente ubicación: http://code-zen.info/twitterimage/

Actualización uno

He actualizado el código RLE utilizado al comprimir la cadena de tweet para hacer una revisión básica y, si es así, usarlo para la salida. Esto solo funciona para los pares de valores numéricos, pero guarda un par de caracteres de datos. El tiempo de ejecución es más o menos el mismo que la calidad de imagen, pero los tweets tienden a ser un poco más pequeños. Actualizaré la tabla en el sitio web a medida que complete la prueba. Lo que sigue es una de las cadenas de tweets de ejemplo, nuevamente para la versión pequeña de Lena:

乤企 伂 쥹 皗 鞹 鐾 륶 䦽 阹 럆 䧜 椿 籫 릹 靭 욶 옷뎷 歩 㰷 歉 䴗 鑹 㞳 鞷 㬼 獴 鏙 돗 鍴 祳 㭾 뤶 殞 焻 乹 Ꮛ 靆 䍼

Actualización dos

Otra pequeña actualización, pero modifiqué el código para agrupar los tonos de color en grupos de tres en lugar de cuatro, esto usa un poco más de espacio, pero a menos que me falte algo, debería significar que los caracteres "impares" ya no aparecen donde el color los datos son. Además, actualicé la compresión un poco más para que ahora pueda actuar sobre toda la cadena en lugar de solo el bloque de recuento de colores. Todavía estoy probando los tiempos de ejecución, pero parecen estar mejorados nominalmente; Sin embargo, la calidad de la imagen sigue siendo la misma. Lo que sigue es la versión más reciente del tweet de Lena:

2 2 企企 伂 坹 坼 坶 坻 刾 啩 容 力 吹 婩 媷 劝 圿 咶 坼 妛 啭 奩 嗆 婣 冷 咛 啫 凃 奉 佶 坍 均 喳 女 媗 决 兴宗 喓 夽 兴 唹 屹 冷 圶 埫 奫 唓 坤 喝 奎 似商 嗉 乃

Logo http://code-zen.info/twitterimage/images/-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

La descripción general de mi solución sería:

  1. Empiezo con el cálculo de la cantidad máxima de datos en bruto que puede encajar en 140 caracteres utf8.
    • (Supongo que utf8, que es lo que el website original de Twitter almacenó en sus mensajes. Esto difiere de la declaración del problema anterior, que solicita utf16).
    • Usando este utf8 faq , calculo que el número máximo de bits que puede codificar en un solo carácter utf8 es de 31 bits. Para hacer esto, usaría todos los caracteres que están en el rango U-04000000 - U-7FFFFFFF. (1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, hay 31 x, por lo tanto, podría codificar hasta 31 bits).
    • 31 bits por 140 caracteres es igual a 4340 bits. Divida eso entre 8 para obtener 524.5 y redondee a 542 bytes .
    • (Si nos limitamos a utf16, solo podríamos almacenar 2 bytes por carácter, lo que equivaldría a 280 bytes).
  2. Comprime la imagen hacia abajo usando compresión jpg estándar.
    • Cambie el tamaño de la imagen para que sea aproximadamente 50x50px, luego intente comprimirla a varios niveles de compresión hasta que tenga una imagen lo más cercana posible a 542 bytes sin pasar por encima.
    • Este es un ejemplo de la mona lisa comprimida a 536 bytes.
  3. Codifique los bits en bruto de la imagen comprimida en caracteres utf-8.
    • Reemplace cada x en los siguientes bytes: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx, con los bits de la imagen.
    • Esta parte probablemente sea la parte en la que se deba escribir la mayoría del código, ya que no hay nada que exista actualmente que haga esto.

Sé que estabas pidiendo un código, pero realmente no quiero perder el tiempo para codificar esto. Pensé que un diseño eficiente podría al menos inspirar a alguien más para que lo codifique.

Creo que el mayor beneficio de mi solución propuesta es que está reutilizando la mayor tecnología posible. Puede ser divertido tratar de escribir un buen algoritmo de compresión, pero está garantizado que existe un mejor algoritmo, probablemente escrito por personas que tienen un título en matemáticas superiores.

Sin embargo, otra nota importante es que si se decide que utf16 es la codificación preferida, entonces esta solución fracasa. jpegs realmente no funcionan cuando se comprimen hasta 280 bytes. Aunque, quizás haya un algoritmo de compresión mejor que jpg para esta declaración de problema específico.

La publicación de una imagen monocromática o en escala de grises debería mejorar el tamaño de la imagen que se puede codificar en ese espacio, ya que no le importa el color.

Es posible que aumente el desafío de cargar tres imágenes que cuando se combinan le dan una imagen a todo color y al mismo tiempo mantienen una versión monocromática en cada imagen por separado.

Agrega algo de compresión a lo anterior y podría comenzar a parecer viable ...

¡¡¡Bonito!!!Ahora ustedes han despertado mi interés. No se trabajará durante el resto del día ...

Con respecto a la parte de codificación / decodificación de este desafío. base16b.org es mi intento de especificar un método estándar para codificar datos binarios de forma segura y eficiente en los planos Unicode superiores.

Algunas caracteristicas :

  • Utiliza solo las áreas de usuario privadas de Unicode
  • Codifica hasta 17 bits por carácter; Casi tres veces más eficiente que Base64
  • Se proporciona una implementación de Javascript de referencia de codificar / decodificar
  • Se incluyen algunas codificaciones de muestra, incluidas Twitter y Wordpress.

Lo sentimos, esta respuesta llega demasiado tarde para la competencia original. Comencé el proyecto independientemente de esta publicación, que descubrí a mitad de camino.

En el desafío original, el límite de tamaño se define como lo que Twitter aún te permite enviar si pegas el texto en su cuadro de texto y presionas "actualizar". Como algunas personas notaron correctamente, esto es diferente de lo que podría enviar como un mensaje de texto SMS desde su teléfono móvil.

Lo que no se menciona explícitamente (pero lo que era mi regla personal) es que debería poder seleccionar el mensaje twitteado en su navegador, copiarlo al portapapeles y pegarlo en un campo de entrada de texto de su decodificador para que pueda mostrarlo. Por supuesto, también puede guardar el mensaje como un archivo de texto y volver a leerlo o escribir una herramienta que acceda a la API de Twitter y filtre cualquier mensaje que se parezca a un código de imagen (¿marcadores especiales para todos? Guiño guiño ). Pero la regla es que el mensaje debe haber pasado por Twitter antes de que puedas decodificarlo.

Buena suerte con los 350 bytes. Dudo que puedas usarlos.

Este algoritmo genético que escribió Roger Alsing tiene una buena relación de compresión, a costa de largos tiempos de compresión. El vector resultante de vértices podría comprimirse aún más usando un algoritmo con pérdida o sin pérdida.

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

Sería un programa interesante para implementar, pero no lo haré.

Idea estúpida, pero sha1(my_image)daría como resultado una representación "perfecta" de cualquier imagen (ignorando colisiones). El problema obvio es que el proceso de decodificación requiere cantidades desmedidas de fuerza bruta.

El monocromo de 1 bit sería un poco más fácil. Cada píxel se convierte en 1 o 0, por lo que tendría 1000 bits de datos para una imagen de 100 x 100 píxeles. Dado que el hash SHA1 es de 41 caracteres, podemos encajar tres en un solo mensaje, solo tenemos que utilizar la fuerza bruta 2 conjuntos de 3333 bits y un conjunto de 3334 (aunque incluso eso es probablemente desordenado)

No es exactamente práctico. Incluso con la imagen de 1 bit de 100 * 100 px de longitud fija hay ..., asumiendo que no estoy calculando mal, 49995000 combinaciones, o 16661667 cuando se divide en tres.

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

Idea: ¿Podrías usar una fuente como paleta? Intente romper una imagen en una serie de vectores tratando de describirlos con una combinación de conjuntos de vectores (cada carácter es esencialmente un conjunto de vectores). Esto está utilizando la fuente como un diccionario. Podría, por ejemplo, utilizar al para una línea vertical y a - para una línea horizontal? Solo una idea.

La idea de almacenar un montón de imágenes de referencia es interesante. ¿Sería tan incorrecto almacenar, por ejemplo, 25 Mb de imágenes de muestra, y hacer que el codificador intente componer una imagen utilizando bits de esas? Con una tubería tan minúscula, la maquinaria en cada extremo será necesariamente mucho mayor que el volumen de datos que pasan, así que ¿cuál es la diferencia entre 25Mb de código y 1Mb de código y 24Mb de datos de imagen?

(tenga en cuenta que las pautas originales descartadas restringen la entrada a las imágenes que ya están en la biblioteca; no lo sugiero).

Lo siguiente no es un envío formal, ya que mi software no se ha adaptado de ninguna manera para la tarea indicada. DLI se puede describir como un códec de imagen con pérdida de propósito general de optimización. Es el soporte de registro de PSNR y MS-SSIM para la compresión de imágenes, y pensé que sería interesante ver cómo se desempeña para esta tarea en particular. Usé la imagen de referencia proporcionada por Mona Lisa y la reducí a 100x150, luego usé DLI para comprimirla a 344 bytes.

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

Para comparar con las muestras comprimidas JPEG e IMG2TWIT, usé DLI para comprimir la imagen a 534 bytes también. El JPEG es de 536 bytes e IMG2TWIT es de 534 bytes. Las imágenes se han ampliado hasta aproximadamente el mismo tamaño para facilitar la comparación. JPEG es la imagen de la izquierda, IMG2TWIT es el centro y DLI es la imagen de la derecha.

Comparación http://i42.tinypic.com/302yjdg.png

La imagen DLI logra preservar algunas de las características faciales, especialmente la famosa sonrisa :).