Compatibilidad de imagenes en campos Blob

[ElMug]

Empezado por Casimiro Notevi

No, amigo ElMug, creo que no te enteras o no te explicas. ¿Realmente has leído lo que hemos escrito?.

Olvidalo, Casimiro.

Aqui les dejo el codigo que les menciono en el mensaje anterior.

Con este procedimiento, se pueden leer imagenes archivadas en columna tipo Blob, que puedan ser BitMap, o JPEG y SIN LA NECESIDAD de tener otra columna donde se almacena el tipo de imagen, como he visto que lo hacen aqui.

Tampoco es necesario descifrar el dato Blob para escudriñar bits o bytes y ver si es bitmap o JPEG.

El desarollo es, pues, novedoso, lo desarrolle hace un par de dias, y aqui se los comparto:

// var
//  BlobField: TField;
//  BS: TStream;

  with SQLQuery1 do
    begin
       BlobField := FieldByName('Pic'); {'Pic' is name of column with photo}
       BS := CreateBlobStream(BlobField,bmRead);
       Image1.Picture.Graphic:= TJpegImage.Create; {assume is Jpeg}
    Try
       Image1.Picture.Graphic.LoadFromStream(BS); {error if not Jpeg}
      Except {repeat steps for BitMap}
         BS.Free;
         Image1.Picture.Graphic:= nil; {empty}
         BlobField := FieldByName('Pic'); {'Pic' is name of column with photo}
         BS := CreateBlobStream(BlobField,bmRead);
         Image1.Picture.Graphic:= TBitMap.Create; {bitmap}
         Image1.Picture.Graphic.LoadFromStream(BS);
      end; {Try}
      BS.Free;
    end; {with SQLQuery}

Ojala lo encuentres util.

[Casimiro Notevi]

Amigo, realmente veo que ni has leído lo que te hemos comentado, ni has hecho una búsqueda para encontrar código similar, ni tiene eso nada que ver con lo que preguntas, ni... nada de nada.


En cuanto a lo "novedoso" del código, en fin, para qué te voy a decir nada, si no lo vas a leer

[[Delphius]]

ElMug, justamente el código es parte de lo que yo he dicho: cargar el stream leído del BLOB. Vuelve a leer mis palabras.
Tu haces una prueba y asume que se trata de un JPEG y si falla entonces asume BMP. De cualquier forma se debe emplear el tipo de TGraphic apropiado y diseñado para cada formato de imagen para poder visualizar.
Si metes PNG u otro formato más el programa se te cae a pedacitos. ¿Porqué te crees que se debe disponer de un campo extra para tener el tipo? Porque es mucho más cómodo y te hace más fácil la vida. ¿O es que te vas a ir probando por cada formato hasta encontrar lo que buscas?
Es mejor tener ese campo. Luego en tu aplicación se resume en un simple case tipo of para crear el TGraphic correspondiente para hacer el streaming.

Con todo respeto, leíste pero no entendiste.

EDITO Y AGREGO:
Además no es que en el BLOB se guarda la información cifrada (de hecho NO HACE NINGUN CIFRADO). Simplemente es el contenido binario tal cual... al BLOB ni le interesa (ni sabe) que es en realidad esa información. Es RESPONSABILIDAD del cliente en interpretar adecuadamente ese dato. Cuando creas el TGraphic apropiado es que lees esa información binaria y es capaz de generar la imagen a mostrar. OBVIAMENTE es que se necesita de que exista "algo" que pueda interpretarlo.
No puedes pretender leer la información de un BLOB así como si nada, esperando que por arte de magia se pueda interpretar lo que hay en el; necesitas de ese "algo". ¡Entérate!

Saludos,

[ElMug]

Delphius,

Nada se "cae en pedacitos" ni mi desarrollo es para nada lo que tu recomiendas que "debe uno de hacer".

Con el sistema convencional del Try, se genera dialogo, precisamente para que nada "se caiga en pedacitos".

Ademas, si insistes en proponer el uso de otra columna (muy tu camino), yo te recomendaria, en base al criterio de la informatica, que mejor de una vez guardes EL NOMBRE del archivo que cargaste, incluyendo el .bmp o el .jpeg, pues de esa manera no solo tienes guardado el tipo de archivo, sino el NOMBRE (sin la ubicacion original del archivo).

Nadie se debe de dogmatizar en base de lo que leen. Si quieren otra columna, pues aprovechenla y tengan MAS informacion. Y aparte que el nombre del archivo, usando el load picture dialog, YA tienen el nobre de el, y lo cargarian automaticamente!

Y con el simple codigo de checar que la columna con el NOMBRE del archivo contenga los caracteres ".bmp", o ".jp", seria suficiente para saber que tipo de archivo guardaron. No necesitan checar si es "jpeg" o "jpg".

No se conformen con solo saber que es ".bmp", o "jpeg". De una vez sepan el nombre de la imagen, con un minimo de pensarle, y con unos cuantos caracteres mas que se almacenarian en la columna, tienen mucha mas informacion util. Por ejemplo, que alguien va la imagen y leyendo la mucho mas util columna "NombreDeArchivo", diga: "ESE no es Juan Perez".

O me van a salir conque guardar ".bmp" o "jpg" en la columna extra sirve para algo mas?

Hasta luego.

[[Delphius]]

Empezado por ElMug

Delphius,

Nada se "cae en pedacitos" ni mi desarrollo es para nada lo que tu recomiendas que "debe uno de hacer".

Con el sistema convencional del Try, se genera dialogo, precisamente para que nada "se caiga en pedacitos".

Si se va cayendo de a pedacitos... Cada vez que requieras darles unos toques al sistema (que los abrá). En esta parte el sistema tiene unos puntos flojos. El punto flojo es haber atacado demasiado la lógica de la aplicación y muy dependiente a los formatos que utilizas y posteriormente desees incorporar.
Por cada formato que introduzcas, o necesites, te verás condicionado a introducir más código (¡y hasta redundante!) lo que hará de dicho método más complejo innecesariamente.... cada nuevo formato implica incrementar la complejidad V(G) en 2. Para dos formatos tienes V(G) = 4, con 2 más, se va a V(G) = 8 y ya es para alarmarse. Semejante valor para la poca cosa.

Además, si ese método se ha ejecutarse cientos de veces, y con más razón, si está atado a los vaivenes de un componente data-ware como un DBGrid ni que decir... porque se estará ejecutando cada vez que se mueva el cursor.
En lo posible hay que evitar estar mostrando contenido BLOB; en el caso de consultas SELECT por ejemplo no extraer dicho campo a menos que sea (y cuando sea) necesario.

Empezado por ElMug

Ademas, si insistes en proponer el uso de otra columna (muy tu camino), yo te recomendaria, en base al criterio de la informatica, que mejor de una vez guardes EL NOMBRE del archivo que cargaste, incluyendo el .bmp o el .jpeg, pues de esa manera no solo tienes guardado el tipo de archivo, sino el NOMBRE (sin la ubicacion original del archivo).

Para tal caso entonces me evito guardar la imagen en la base de datos (que ya de paso me ahorro una buena cantidad de espacio y no queda tan pesada) y las dispongo en un directorio y cargo via LoadFromFile().
Si tu guardas en un BLOB es por algún motivo que suponemos que ya haz evaluado y consideraste que podría ser lo más óptimo y viable a tu caso.
Hay varios hilos sobre este debate, con buscar te enterarás más.
En ningún momento dije de almacenar todo el nombre, sólo me limité a exponer que se requiere de un campo adicional que sirva para identificar el formato adecuado. Puede ser un CHAR, o un INTEGER, eso lo dejo a elección y necesidades de cada quien.
Y vuelvo a explicar: gracias a ese campo las cosas son más sencillas. Ya no necesitas ir metiendo tanto try, finally y tener un código en base a pruebas. Estoy completamente seguro que si preguntas a la mayoría del foro te van a decir que pongas ese campo. Es que es muy directo, se lee dicho campo e inmediatamente ya sabes que TGraphic emplear.
Ganas tiempo y recursos.

Empezado por ElMug

Si quieren otra columna, pues aprovechenla y tengan MAS informacion. Y aparte que el nombre del archivo, usando el load picture dialog, YA tienen el nobre de el, y lo cargarian automaticamente!

Lee lo que dije antes, si así fuera el caso justamente lo cargo y no tendría que estar almacenando la imagen en la base de datos.
Repito: si tu consideraste el BLOB será por algo. Pero en este hilo lo que ha quedado en claro es que no has sabido apreciar las "contras" que ello implica, y te viste atascado en un problema por tu desconocimiento de lo que es un BLOB y asumiste que así como lo metes lo puedes recuperar sin requerir de "algo" que lo interprete. Todo se resume a una ignorancia de tu parte sobre BLOB.

No te recomiendo el campo por el hecho de poner más información, sino por una combinación de NECESIDAD OPERATIVA y una mejor propuesta que equilibra mejor la tercia {codigo,logica,tiempo}. Añadir UN campo más no supone un desperdicio. Distinto fuera si te digo que agregues 50... Pasa por una una combinación de Necesito (Requisito/Restricción) vs Facilidad (Factibilidad Técnica) vs Operatoria (Factibilidad Operativa).

Empezado por ElMug

Y con el simple codigo de checar que la columna con el NOMBRE del archivo contenga los caracteres ".bmp", o ".jp", seria suficiente para saber que tipo de archivo guardaron. No necesitan checar si es "jpeg" o "jpg".

Definitivamente no entras en razón ni entiendes nada.

Empezado por ElMug

No se conformen con solo saber que es ".bmp", o "jpeg". De una vez sepan el nombre de la imagen, con un minimo de pensarle, y con unos cuantos caracteres mas que se almacenarian en la columna, tienen mucha mas informacion util. Por ejemplo, que alguien va la imagen y leyendo la mucho mas util columna "NombreDeArchivo", diga: "ESE no es Juan Perez".

O me van a salir conque guardar ".bmp" o "jpg" en la columna extra sirve para algo mas?

Hasta luego.

Pues si consideras que te van a ser útil pues ¡métele!
Lo que veo es que no has sabido apreciar un enfoque que te podría ser mucho más sano, no sólo ahora, sino en el futuro cuando te toque ver de nuevo ese código y veas tanto try finally para hacer algo que se puede hacer de forma más directa.

Y ahora finalizo dando una mejora a mi propuesta. Debido a que disponer de un case of también implica disponer de la misma creciente V(G) y de retoques en el código para añadir más formatos (aunque es más limpio) aprovechando el campo Tipo/Formato y considerando que se trata de crear una serie de objetos que responden a una fnecesidad poliformica, y como buen defensor de los patrones de diseño propongo: tener una fábrica de TGraphic, esta fábrica recibe como parámetro el tipo indicado y regresa el TGraphic adecuado, de este modo el cliente sólo hace uso de la llamada polimórfica que dispone éste.

Es decir algo simple como:

Código Delphi [-]
Image1.Picture.Graphic := Factoria.CreateGraphic(SQLQuery.FieldByName('Pic'));
Image1.Picture.Graphic.LoadFromStram(BM);

Fíjate en como tu haces doble trabajo, tienes código redundante como por ejemplo:

Código Delphi [-]
BlobField := FieldByName('Pic'); {'Pic' is name of column with photo}
BS := CreateBlobStream(BlobField,bmRead);

Elimina esa redundancia, y gracias a la Fábrica te despreocupas de estar complicándote más.

Lo que resta es registrar a cada TGraphic en la Fábrica. Con esto se separa la lógica entre creación y uso de cada TGraphic. La creación de cada tipo se centra y pasa a estar controlado por una fábrica, ofreciendo una clara abstracción frente a los cambios para quien haga uso de los TGraphic. El cliente, el Image1, ni se entera de si un TBitmap, o algún otra clase descendiente de TGraphic simplemente para él es un TGraphic más y le delega el trabajo ya que el mismo sabe que hacer.
Si se ha de añadir un nuevo TGraphic sólo hay que agregar una línea de código, algo como:

Código Delphi [-]
Fabrica.Register(ElNuevoGraphic, Tipo);

Puede centrarse todas las registraciones en una única unidad, o incluso de un RegisterAllTGrahic() que asuma todo el control y no hay que tocar el código en donde se usan a estos TGraphic y adaptar el código.

Recomiendo una lectura sobre el patrón Fábrica (también llamado Factoría). Aquí mismo en el foro se ha discutido sobre el patrón. La fábrica es uno de los patrones más limpios que hay (bueno, en realidad todos los patrones buscan la limpieza y equilibrio entre acoplamiento/cohesión a sus formas) y justamente su potencial está en separar el potencial crecimiento y dependencia de nuevos objetos a crear de sus clientes ofreciendo un alto grado de reutilización (tan alto como se diseñe la fábrica y esté definido el polimorfismo que ofresca las clases Productos).

Saludos,

[Casimiro Notevi]

Hace unos meses hice algo similar a lo que explicas de la 'fábrica'. Básicamente se almacenaba en un blob una imagen y su tipo en otro campo: 1.bmp, 2.jpg, 3.png, 4.gif, etc. y a la hora de mostrarlo en un timage, en tiempo de ejecución, se convertía de formato a bmp (si no era bmp), por lo que la parte de presentación era muy simple, tal y como comentas, no había que estar repitiendo código para un formato u otro.

[ElMug]

Delphius,

Criticas que mi metodo solo se aboque a BitMap y a JPG?

Valgame, la decepcion de los argumentos comparandolo con el metodo (que no es tuyo) de usar una segunda columna para archivar el tipo de imagen.

Y digo decepcion, pues mustra que olvidas o ignoras que Delphi solo tiene un solo descendiente de la clase TGraphic originalmente y es el BitMap que usa para guardar cualquier tipo de imagen. Fijate bien como los almacenamientos usan el BitMap, sea JPEG o Bitmap.

Esto se te escapa en tus vanos argumentos. Por ejemplo, si archivas un tipo targa, y pones en tu columna "tga" o lo que desees, ni sueñes que ya con eso lo vas a poder mostrar en una caja de TImage, pues no tendrias el metodo para mostrarlo. Asi que tus argumentos sobre "vas y vas complicando" si quieres usar mas tipos de imagenes lo traes montado en la esplada del metodo que advocas.

Para poder leer mas tipos de imagenes, tendrias que conseguir las rutinas para cada imagen extra, ya sea de fuentes libres o comprandolas, ya sean para .png, TIF, Gif, etc., y ni creas que las vas a encontrar facilmente, y ni a costo, pues esos formatos, aparte, tienen tambien algunas variantes en su formato que complican lo que en vano promueves con ahinco.

Los tipos de imagen para lo discutido, que basicamente apoya Delphi, y precisamente en eso se basa mi metodo, son el JPEG y el BitMap. Dos unicamente!

Si lees bien lo que escribi originalmente, dije "si quieres agregar algun otro tipo", no "todo lo que se te antoje", implicando que si tienes el metodo para formar el stream, ya las puedas poner en la caja TImage, con mi metodo...Y es porque de todas maneras Delphi la va a almacenar como BitMap crudo. Y si se le cargan headers, pues se complica conque solo tu aplicacion las leeria.

Y es por eso que mi recomendacion es usar solo el bitmap y el JPEG, que SI apoyan Delphi y Lazarus, y usar convertidores de imagenes, siendo eso la manera mas practica de trabajarlas.

Aparte te repito, que NADA se hace pedacitos, pues mi metodo se basa en que las imagenes YA ESTAN GUARDADAS, y o es BitMap o es JPEG y con esas dos Try's es SUFICIENTE para resolver el problema. Ya informe que mi metodo ahorra UNA columna, y ahorra el descifrar el Blob. Que haya o no otros metodos es irrelevante, especialmente si no ahorran una columna, y te forzan a descifrar. Que trabajen y se usen, eso nadie lo puede negar.

Mi aplicacion esta trabajando perfacta y robustamente. Le he cargado ya mucha diversidad de imagenes de los dos formatos. Automaticamente se muestran la imagen en tamaño estampilla en una caja TImage, y tengo codigo para que con Double-Click en ella, se abra un Image-Viewer que le integre, en que se puede ver la imagen en su dimension plena.

Lo que te puedo añadir, es que Embarcadero, en sus sistemas mas recientes SI tiene tecnologias nuevas que hacen lo aqui discutido verse retrograda. Pero, como sabras, esas tecnologias no estan disponibles a gran parte del usuario que ha basado sus desarrollos en los Delphis anteriores, o en Lazarus.

Y es por eso, que el metodo que les comparto, considero, le puede ser bastante util al que desee tratarlo, por su simpleza, eficacia, y robustidad.

Discutir todas tus criticas y alegatas hipoteticas y nada pausibles, en realidad las considero inutiles. Lo siento, pero es la situacion.

Por lo demas, agradezco tu interes, que creo sincero, aunque errado, en analizarlo como lo haz hecho.

Si llegases a descubrir que no sirve, ahi SI, se te agradeceria lo reportaras, siempre y cuando se aplique como es la intencion.

Hasta luego.