html5 - para - mostrar imagen en html

Procesamiento de imagen del lado del cliente (14)

¿Has consultado el editor de Pixlr.com ?
Eche un vistazo a su API también ..

Estamos construyendo una aplicación basada en la web que requiere un procesamiento de imágenes pesado. Queremos que esta carga de procesamiento esté en el cliente tanto como sea posible y nos gustaría apoyar tantas plataformas (incluso móviles) tanto como sea posible.

Sí, lo sé, una ilusión

Aquí está la información:

El procesamiento de imágenes es rasterización a partir de algunos datos. Piensa como crear una imagen PNG a partir de un archivo PDF.
No tenemos mucha potencia de servidor. Por lo tanto, el procesamiento del lado del cliente es un deber.

Entonces, estamos considerando:

Flash: más generalizado, pero por lo que he leído tiene herramientas de desarrollo deslucidas. (y no hay soporte para iPhone / iPad por ahora).
Silverlight: nos permite utilizar .NET CLR, por lo que un gran ++ (hay un montón de código en .NET). Pero no es compatible con la mayoría de los teléfonos móviles (se rumorea el soporte de Android en el futuro)
HTML5 + Javascript: probablemente sea la opción más "portátil". El problema es tener que reescribir todo ese código de procesamiento de imágenes en Javascript.

¿Algún pensamiento o arquitectura que pueda ayudar? Aclaración: no necesito más ideas sobre qué bibliotecas están disponibles para Silverlight y Javascript. Mi dilema es

elegir Silverlight significa que no hay soporte para la mayoría de los móviles
elegir Flash significa que tenemos que volver a desarrollar la mayor parte de nuestro código Y no hay compatibilidad con iPhone / iPad
HTML5 + Javascript tenemos que volver a desarrollar la mayor parte de nuestro código y aún no es totalmente compatible en todos los navegadores
elegir dos (Silverlight + Flash) será demasiado costoso

¿Alguna idea / alternativa lista para usar o brillante que pueda estar perdiendo?

¿Por qué no mencionar Java Applet?

Los buenos lados son:

casi todo el soporte del navegador? ¿Necesito instalar JRE? todo el soporte de SO Java proporciona kits de imagen avanzada de Java, pero si se puede llamar a c ++ dll, es lo mejor (JNI puede llamar a c ++ dll)

Además de otras respuestas, otra opción puede ser una solución híbrida. Por ejemplo, use Flash / Silverlight para la mayoría de su público objetivo y use el procesamiento del lado del servidor para aquellos que no lo admitan (o podría crear una aplicación nativa para iP [hone | ad])

Puede que tengas que hacer algo como esto de todos modos, ya que los móviles a los que apuntas pueden tener una potencia de procesamiento insuficiente dependiendo de lo complejo que sea el procesamiento de tu imagen.

Por supuesto, usted todavía tiene la opción de actualizar su servidor que, aunque actualmente ha descontado, probablemente sea mucho más económico que pasar el tiempo de desarrollo creando / implementando / probando una solución del lado del cliente.

Algo de ayuda para la parte de Silverlight:

Hay un editor de imágenes de Silverlight llamado Thumba . Y Nokola recientemente creó uno llamado EasyPainter y también proporcionará el código fuente en el furure.

Para la conversión de imágenes recomendaría la biblioteca de código abierto ImageTools que también incluye algunos efectos básicos. Silverlight tiene una clase para la manipulación de mapas de bits llamada WriteableBitmap. La biblioteca de código abierto WriteableBitmapEx es una colección de métodos de extensión para WriteableBitmap de Silverlight. La API de WriteableBitmap es muy minimalista y solo existe la matriz de píxeles en bruto para tales operaciones. La biblioteca WriteableBitmapEx intenta compensar eso con métodos de extensiones que son fáciles de usar como métodos integrados. Pixel Shaders también se puede usar para crear efectos rápidos y avanzados. Aunque están limitados por Shader Model 2, los sombreadores se pueden usar para difuminar rápidamente, teñir y cosas por el estilo.

DESCARGO DE RESPONSABILIDAD: me considero un defensor de la plataforma Flash. Admiro el gran potencial de Silverlights como una tecnología para desplegar casi cualquier contenido .NET a través del navegador, pero tiene baja penetración, es horriblemente comercializado y -aunque muchos lo perciben como tal (principalmente personas que no conocen ni Flash ni Silverlight) - no es un competidor de Flash, tanto como Flash no es un competidor de Sliverlight. Al idealista en mí le encanta la idea de hacer todo en HTML + JS usando un estándar, en lugar de depender del software propietario de terceros. Pero la verdad es que JS es lento y la API es limitada, y las implementaciones de JS, HTML y CSS son terriblemente inconsistentes entre los navegadores.

Si realmente quieres mantenerte en .NET y estás tan interesado en seleccionar el iPhone y sus hermanos, entonces tal vez quieras probar MonoTouch .

Aún así, aunque esto pueda sorprenderlo, le diré que use Flash. :)

¿Por qué? El bit de procesamiento de imagen es la parte más pequeña de su aplicación. Lo que sea que estés escribiendo, estoy muy seguro de eso. No sé sobre Silverlight, pero en Flash los filtros utilizados por "Thumba" y "EasyPainter" se pueden crear en un día, la mayoría de ellos simplemente usando ConvolutionFilter , ColorMatrixFilter , DisplacementMapFilter y BitmapData::paletteMap o incluso simplemente aplicando uno de los otros filtros que Flash ofrece de fábrica . Cualquier cosa adicional se puede crear usando PixelBender, que fue señalado por George. El lenguaje kernel es un subconjunto de C, por lo que portar filtros clásicos no debería consumir demasiado tiempo. También la alchemy (un backend de LLVM dirigido a Flash Player 10) sería una opción que vale la pena investigar, aunque todavía no es muy estable.

La parte más importante de su aplicación será mucho diseño de GUI, implementación de GUI, lógica de negocios, etc. Flash es realmente genial cuando se trata de manipulación de imágenes simple, pero bastante rápida y con el marco de Flex y MXML usted tiene una poderosa herramienta para productivamente cree la GUI de su aplicación, que puede interoperar muy bien con una multitud de soluciones de servidor para prácticamente cualquier plataforma.

Además, Flash tiene una gran comunidad activa que ofrece toneladas de tutoriales, fragmentos de código, bibliotecas y marcos, y un gran ecosistema, con herramientas de compilación cruzada para entregar contenido flash a otras plataformas (incluida la próxima Flash CS5 , o la mencionada Elips). ) No entiendo, donde tuvo la impresión, que la plataforma Flash carece de herramientas de desarrollo. La diferencia con el paquete .NET es que son proporcionados por una multitud de proveedores. El próximo Flash Player 10.1 ya fue señalado por George, pero no obstante, quería recalcar que esto hace que muchas de las consideraciones de plataformas cruzadas sean obsoletas.

Por último, pero no menos importante, me gustaría señalar que es grave . Permite compilar en SWF, pero también en C ++, utilizando la misma API proporcionada por NME , para apuntar al iPhone . También hay trabajo en progreso en un backend de Android. Si no estás jugando para lanzar dentro de los próximos 4-5 meses, esta es definitivamente una opción.

Depende del tipo de procesamiento de imágenes y de la experiencia del usuario final al que se dirige.

Como busca enfocarse en los teléfonos móviles, su procesamiento de imágenes deberá tener en cuenta el tipo de dispositivo que tiene el usuario o el destinatario (si envía mensajes a través de SMS / MMS), ya que los diferentes teléfonos tienen pantallas de resolución diferentes y manejan diferentes formatos de imagen para imágenes y miniaturas

Sugeriría que considere una arquitectura de nube híbrida como se mencionó en las notas clave de Microsoft PDC este año. Esto le permitiría tener sus propios servidores para respaldar su aplicación, pero si necesita capacidad adicional debido a que escala a la nube usando AppFabric.

Además, para maximizar la disponibilidad de su producto en el mercado, llevar el procesamiento de imágenes a una infraestructura reutilizable común le permite apuntar a diferentes plataformas, aprovechando los aspectos positivos en cada una de ellas.

He trabajado en una solución que hospedaba el lado del servidor de la infraestructura de entrega y procesamiento de imágenes y luego construí diferentes ofertas de UI que permitían las ventas a través de escritorios, MNO y AppStores. Puede funcionar y desde una perspectiva comercial puede ofrecer beneficios de economías de escala.

Este es el tipo de problema que los arquitectos de software se enfrentan todo el tiempo. Como de costumbre, no hay una solución ideal. Debe seleccionar qué compromiso es más aceptable para su negocio.

Para resumir su problema, la mayoría del software de procesamiento de imágenes está escrito en .NET. Le gustaría ejecutarlo desde el lado del cliente en los dispositivos móviles, pero la penetración de .NET es limitada en los dispositivos móviles. Las alternativas con mayor penetración (por ej., Flash) requerirían que reescribas tu código, lo cual no puedes permitirte. Además, estas alternativas no son compatibles con el iPhone / iPad.

Lo que idealmente quieres es una forma de ejecutar todo tu código .NET en la mayoría de las plataformas existentes, incluido iPhone / iPad. Puedo decir con cierta confianza que actualmente no existe una solución de este tipo: no hay una respuesta "milagrosa" que haya pasado por alto.

Entonces, ¿qué vas a necesitar comprometer? Me parece que incluso si desarrollas nuevamente en flash, todavía te perderás un mercado importante (iPhone). Y volver a desarrollar el software es extremadamente costoso de todos modos.

Esta es la mejor solución para su problema: debe comprometerse en su restricción de "ejecución del lado del cliente". Si ejecuta el lado del servidor, puede conservar su código existente y también implementarlo en casi todos los clientes móviles, incluido el iPhone.

Dijiste que la potencia de tu servidor es limitada, pero la potencia de procesamiento del servidor es barata en comparación con los costos de desarrollo de software. De hecho, no es tan caro subcontratar el componente de su servidor y simplemente pagar por lo que usa. Lo más probable es que su aplicación tenga una penetración baja para empezar. A medida que crezca la empresa, podrá permitirse actualizar su capacidad de servidor.

Creo que esta es la mejor solución para su problema.

Estoy seguro de que habrá personas de Silverlight y JS publicando ejemplos. Aquí hay algunos editores de imágenes escritos en actionscript:

Hay una biblioteca de ImageProcessing para comenzar. Además, PixelBender está disponible en Flash Player 10, es rápido, se ejecuta en un hilo separado y la people hace cosas bastante alocadas con él.

HTH

La mejor solución es usar Silverlight (para que ya tenga el código listo). Si el cliente no puede ejecutarlo (teléfonos móviles, etc.) luego procesarlo en el lado del servidor.

Es el mejor compromiso.

Organice el procesamiento de imágenes en Amazon E2C, Azure o Google. IIRC E2C tiene muchos problemas comunes de procesamiento de imágenes empaquetados y todo listo para funcionar.

Azure probablemente más terreno familiar en términos de compartir código como un servicio web

Usted solo paga por los ciclos de CPU y transferencias / almacenamiento, etc.

Puede usar Silverlight para todos los clientes habilitados para Silverlight y para los clientes que no sean Silverlight, para el lado del servidor de procesamiento de imágenes. Como el código de Silverlight es C #, puede compilarlo dos veces para hacer que (en su mayoría) el mismo código funcione como Silverlight y no Silverlight (es decir, el servidor). Esto te da lo mejor de ambos mundos.

Su problema es un objetivo perfecto para el lenguaje de programación haXe . haXe está escrito para la web y puede compilarse para JavaScript, Flash y Objective-C (posiblemente Java / .NET pronto). Por lo tanto, no eliges en qué plataforma vas a invertir, sino en qué idioma. HaXe es fácilmente adoptable para un programador de AcitonScript.

No tiene sentido ejecutar sus algoritmos de procesamiento de imágenes en un entorno limitado de JavaScript cuando Flash está disponible porque será mucho más rápido. Tampoco tiene sentido ejecutar algoritmos pesados de procesamiento de imágenes en un dispositivo móvil como el iPhone con JavaScript. Solo admitiría JavaScript como la peor solución alternativa.

Si no te gusta usar haXe, yo iría con Flash. También puede implementar su aplicación Flash para el iPhone si ese es su problema. Esto también es muy bueno porque obtienes código ARM nativo. En realidad, hay excelentes herramientas para el desarrollo de Flash profesional disponible. FDT e IntelliJ IDEA son dos de ellos. El mejor IDE de haxe es probablemente FlashDevelop en el momento de la escritura.

Así que definitivamente no usaría JavaScript como la única solución. HaXe es perfecto para lo que trata de lograr. Si no confía o no quiere invertir en haXe, puede usar Flash debido a la exportación de iPhone / iPad .

Dependiendo de su caso de uso, también lo alentaría a buscar alojamiento en la nube, como Amazon EC2 y Google AppEngine, por ejemplo. Los costos de alojamiento son baratos y el escalado será fácil para su tarea. La experiencia será mucho mejor cuando se trata de operaciones complejas que pueden llevar incluso mucho tiempo en un sistema de escritorio.

Tal como lo veo, no hay una solución que satisfaga todas sus necesidades. Su mejor opción, imo, es ir con Flash y esperar que Adobe establezca un acuerdo con Apple para obtener Flash en el iPhone / iPad. La desventaja principal, por supuesto, es que tendrá que reescribir gran parte de su código.

Si el sector móvil no es absolutamente crítico, entonces elija la opción Silverlight por las razones que ya mencionó. También puede usar Silverlight en un modo fuera del navegador para funcionar como una aplicación de escritorio.

Usted no dice en qué idioma se encuentra "todo ese código" que tendría que reescribir. ¿Sería posible una traducción semiautomática a Javascript?

Quizás podría comenzar desde el lado del servidor, como sugiere CraigS, y luego mover las funciones al cliente a lo largo del tiempo en lugar de reescribirlas todas a la vez.