2008-12-17 21 views
6

estamos manteniendo una base de datos de medios de imágenes en una aplicación de Internet a gran escala. Los jpgs de alta resolución son grandes (> 15MB) y no deben estar disponibles para su descarga de ninguna manera. Ahora necesitamos proporcionar acceso a los detalles (cultivos) de las imágenes a los clientes (como una función de acercamiento). El cliente debería ver una versión reducida de la imagen y poder seleccionar un área para verla en el modo de escala completa (100%).Protección de medios de imagen en una aplicación web

¿Cómo podría esto implementarse de la manera más eficiente (tráfico y capacidad de la CPU)? Estamos abiertos a cualquier solución siempre que el archivo de imagen de alta resolución permanezca protegido. La aplicación está desarrollada en C# y .net framework 3.5.

¿Alguna idea? ¡Gracias por adelantado!

+0

http://en.wiktionary.org/wiki/performant –

Respuesta

1

Lo primero que tendrá que hacer es comprimir y marcar con agua las imágenes antes de cargarlas en el servidor. A continuación, presentarlos al usuario. Esto tomará menos recursos de CPU ya que las imágenes serán estáticas.

Personalmente recortaría las imágenes para las versiones de tamaño completo y las colocaría junto a las comprimidas. De esta forma, el cliente puede tener una vista de la imagen completa (aunque comprimida y con marca de agua) junto con una pequeña muestra de la versión de alta resolución completa.

Es probable que desee evitar la manipulación de imágenes sobre la marcha a menos que tenga un bajo número de clientes y un servidor muy fornido.

+0

Sí, las imágenes se comprimen antes de mostrarse al usuario. En cuanto a los cultivos: El problema es que nos gustaría permitir que el cliente elija el área de la imagen que desea ver. Si la imagen es grande, significaría que se guardan muchos cultivos pregenerados en el servidor. – Mats

+0

Creo que necesitas un servidor muy rápido o mucho espacio web.Permitir al usuario acercarse a un rango (casi) arbitrario debería funcionar cuando recortes tu imagen en porciones lo suficientemente pequeñas (estoy pensando en algo similar a los mapas de Google). –

+0

(continuación) No creo que haya demasiada sobrecarga en relación con el espacio en disco cuando pregenera estas divisiones. –

-2

Yo utilizaría S3 para el almacenamiento. Cree dos cubos (públicos protegidos), proporcione url a las imágenes del cucharón protegido una vez que haya autorizado al usuario a descargarlos. S3 Las URL se pueden restaurar con una fecha de vencimiento.

Con imágenes de 15Mb probablemente se dará cuenta de que necesita pregenerar la versión a escala/recortada con anticipación.

Usaría una marca de agua de algún tipo en todo menos en el archivo original. (Como los mapas de Google)

[Editar: Agregado Deep Zoom para acercar]

Salida Silverlight Deep Zoom para la gestión de la croping y zoom (Demo). Incluso tienen un utility para generar todas las imágenes recortadas.

+0

Gracias por su respuesta. El almacenamiento no es el problema en cuestión. Más bien, la cuestión de cuándo/cómo/cuánto etc recortar versiones para pregenerar o si hay un enfoque totalmente diferente de la misma (por ejemplo, una solución basada en flash?). – Mats

0

Serviría una versión de baja resolución de la imagen en el navegador y tendría un ui de recorte del lado del cliente que luego enviaría una solicitud al servidor que recortaría la selección y la enviaría nuevamente a alta resolución.

+0

El recorte en tiempo real de una imagen de 15Mb en un servidor web realmente matará el rendimiento/escalabilidad –

+0

Pero ¿de qué otro modo cumple los requisitos? "Los jpgs de alta resolución ... no deben estar disponibles para su descarga de ninguna manera". y "El cliente debería ver una versión downskaled de la imagen y poder seleccionar un área para verla en el modo de escala completa (100%)". ? – PEZ

+0

Exactamente esa es la pregunta difícil aquí;) – Mats

0

Como le digo a mi padre (que no entiende cómo funciona internet), si puede verlo en una página web, puede guardarlo, solo se trata de cómo hacerlo.

+0

Ser capaz de guardar una parte de ella con una marca de agua, está bien en este escenario. –

0

Hay una versión de Deep Zoom ajax que te pueden gustar - Ver Dragón:

http://livelabs.com/seadragon-ajax/gallery/

El usuario se le presenta una versión de baja resolución de la imagen; ellos pueden hacer zoom sobre cualquier parte que les guste.

-1

no debe estar disponible para descargar de ninguna manera.

está en desacuerdo con:

El cliente debe ver una versión downskaled de la imagen y poder seleccionar un área de la misma para ser visto en el modo de escala completa (100%)

... en el punto en que permite que todas las áreas de la imagen se visualicen a máxima resolución, toda la imagen se puede unir. por lo que de manera efectiva (aunque muy inconveniente) está disponible la imagen de tamaño completo.

nada de esto te ayuda a lograr el objetivo.

la forma en que lo haría sería proporcionar una copia de marca de agua de 72 ppp para usar en la selección del área de la imagen para descargar. podría escalar esto a un% del original si el problema de la pantalla era un problema. haga que el usuario elija las coordenadas superior izquierda e inferior derecha. luego use algo como imagemagick para copiar esta área fuera del original para ser servida al usuario.

si necesita conservar recursos, puede hacer que los usuarios descarguen de una cuadrícula predefinida, por lo que la primera vez que se coordina la grilla 14:11, se escribe image_1411_crop.jpg en el sistema de archivos, y la próxima vez que se coord está seleccionado, el archivo ya existe.

edición: leer algunos de sus comentarios en otras respuestas ...

no importa qué manera de ir sobre la generación y almacenamiento en caché serverside, usted va a utilizar la misma cantidad de ancho de banda y el tráfico. un jpeg de 300 ppp es un jpeg de 300 ppp, no importa si se acaba de generar o está en el sistema de archivos.

tiene que averiguar si necesita conservar la CPU o el espacio en disco. si tienes un millón de gigs de imágenes y solo cuarenta usuarios, puedes pagar el golpe de la CPU. si tienes cuarenta gigas de imágenes y un millón de usuarios, ve por la HDD.

+0

No se trata de ancho de banda y tráfico, se trata de cargar una imagen de> 15Mb en la memoria y de intentar cambiar el tamaño a pedido. En el mejor de los casos será lento. –

+0

había mucho más en mi respuesta que el punto de que el ancho de banda y el tráfico no se verían afectados sin importar la solución: p – nailitdown

+0

En lugar de simplemente votar negativamente, tal vez debería proporcionar algo útil en los comentarios. Como la razón por la cual En este caso, sería "porque votaste mi respuesta" –

0

En primer lugar, preprocesaría las versiones con marcas de agua de todas las imágenes de tamaño completo, guardándolas en un formato de archivo comprimido, así como las versiones de baja resolución previamente renderizadas.

Serviría las imágenes de baja resolución para navegar. Luego, la imagen de alta resolución con marca de agua para que el usuario configure su recorte.

En el momento de la confirmación, tendría un segundo servidor de procesamiento de imágenes dedicado que recortara la imagen sin marca de agua, pasara la imagen recortada al servidor web que la envió al cliente.

Dicho esto, aún sería posible crear una secuencia de comandos del lado del cliente que cultivara las partes recortadas y las uniera para crear una copia de tamaño completo de la imagen sin marca de agua.

Cuestiones relacionadas