Hola.
Cita:
|
Empezado por jachguate
Sin embargo, si de todas formas te interesa la "composición", creo que te valdria investigar sobre la clase TCanvas, en especial su método Draw, con lo que podes generar un mapa de bits con la composición, y luego asignarlo a un TJPEGImage (o el formato que te interese) para almacenarlo en el blob.
|
Aunque funcionaría perfectamente, pero me parece que consumiría mucha CPU y memória (tienes que construir un bitmap enorme que desprués habrá que cambiar de formato para que no ocupe tanto en la BBDD).
Yo simplemente almacenaría una imagen detrás de otra en el campo (es decir no sería una imagen compuesta, sino un flujo de bytes con el contenido de los archivos de imagen), almacenando también en una matriz de 40 enteros la posición de inicio de cada imagen. (Mediante un Stream al que vas alimentando con los archivos de las 40 imagenes).
Para recuperar la imagen deseada, solo tienes que crear un Stream sobre el campo, posicionarte en el inicio de la imagen, y leer los bytes correspondientes hasta el inicio de la siguiente imagen.
Aunque creo que estamos todos de acuerdo, que no hay ninguna razón que justifique esta implementación. Puesto que el inconvieniente de tener que bajar el contenido de 40 imagenes, para acceder a una sola, no parece que quede compensado con la pequeña ganancia de espacio en el archivo de la base de datos (debido a la menor fragmentación interna).
Una estimación de espacio ganado seria : (utilizando un tamaño de página de 4 kb., bastante habitual, que se puede aumentar si las imagenes són muy grandes, para acelerar la lectura de los campos blob)
- Registros de imagenes independientes
40 registros de imagenes -> 40 * 4 kb = 160 kb. (asumo que cada registro de datos, ocupa como mínimo una página, cosa de la que no estoy muy seguro, pero vayamos a lo peor).
fragmentación interna de 40 campos blob -> 40 * 4 Kb / 2 = 80 Kb. (asumo que la ultima página de datos del campo blob estará medio vacía).
- Registros con 40 imagenes compuestas
1 registro de datos -> 4 kb.
1/2 página de fragmentación interna del único blob -> 2 kb.
Asi pues cada 40 imagenes, ocuparán 236 Kb. más si las almacenamos como registros independientes. O sea, 5.9 Kb. más por imagen. Si las imagenes són de, supongamos un tamaño pequeño de 60 kb., estamos hablando de un 10% que podemos ahorrar en menos registros y menos fragmentación interna.
Gracias al tamaño actual de los discos duros, un ganancia del 10% de tamaño en la base de datos, no me parece que compense el multiplicar por 40 el tráfico de red.
Saludos.