Compatibilidad de imagenes en campos Blob

[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.

[Casimiro Notevi]

Caso hipotético: llega tu jefe y por algún motivo (le han 'comido' el coco, le van a pagar una buena cantidad por ello, lo han abducido los extraterrestres, ...) te dice:
"hace falta que el programa visualice estos tipos de imágenes, ten la lista, lo necesito para ayer".
Echas un vistazo a la lista y te encuentras con esto:
+------------------------------------------------+
| Formatos de imágenes que debe leer el programa |
+------------------------------------------------+
art, bmp, cin, cpt, dpx, exr, fpx, gif, iff, ilbm,
lbm, jpeg, jpg, jpg2, jp2, mng, pbm, pcd, pcx,
pgm, png, ppm, psd, psp, tgam tpic, tiff, tif,
wbmp, xbm, xcf, xpm, eps, pic, pct, ai, cdr
+------------------------------------------------+

¿Cómo lo resolverías?

[[Delphius]]

Empezado por 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.

¿A que viene si el método que propuse es mio o de alguien más? No sabía que eso tiene dueño.
Y la verdad es que desconozco quien es el autor original, e inicial, del patrón Fábrica pero le agradezco que los haya publicado y dado a conocer para que el resto de la gente lo utilice.

Empezado por ElMug

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.

Grave error, un jpeg es un jpeg; un bmp es un bmp como así también un png es un png. Lo que se almacene es justo eso: una estructura diseñada específicamente para su formato.
Lo que hace Delphi, y cualquier otro IDE/lenguaje que trabaje con estos y otros más formatos es generar en tiempo de ejecución una representación visual de los formatos a nivel de mapa de bits. Más físicamente, almacenados en disco cada formato tiene su propio sistema. El único que almacena la imagen como es, a mapa de bits, es el Bitmap. Los otros formatos no almacenan los mapa de bits de forma cruda, más bien utilizan algoritmos de compresión.
Para mostrar una imagen, que no sea bmp, se ha de hacer una conversión adecuada ya que todo se resume a un mapa de bits. Gracias al poder de codecs es que se le dota a los equipos soportar formatos y éstos hacen el trabajo tras bambalinas.

Cuando tu mandas el contenido al BLOB este recibe lo que venga... si le pasas un bmp será la información binaria del bmp, si le pasas un jpg será la información binaria de éste... nunca una conversión.
Delphi cuenta con la clase base TGraphic justamente para que luego cada descendiente de ella implemente los métodos polifórmicos especificamente diseñados a cada formato al que abstrae. El JPEGImage es un descendiente de este TGraphic, como así también lo es TIcon, y otras.
Esto le permite que se le puedan diseñar más clases específicas a nuevos formatos.

Empezado por ElMug

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.

Es cierto que el TImage de las versiones viejas no tiene demasiado soporte a nuevos formatos, pero de que existen alternativas (tanto pagas como libres) más completas es un hecho. Y sea la alternativa que sea lo que hace es extender el principio de TGraphic pues es que para eso está esta clase base. Asi que se sigue utilizando el poder de TGraphic y el polimorfismo. Estas bibliotecas ofrecen un TImageEx (como para darle un nombre hipotético) que reconoce los formatos iniciales de Delphi más otros y ofrecen el juego de las clases TGraphic para cada uno... estas clases no son más que una abstracción para el codec, que como dije antes es quien hace el trabajo tras bambalinas.

Con lo cual todo el esfuerzo que te cuesta es simplemente reemplazar el TImage por el extendido y algunos posibles ajustes menores que no te van a hacer temblar el resto del código ni atarse a la lógica de tu programa.

Empezado por ElMug

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.

No... lo que tu has dicho y dejado en claro es que inicialmente estás con bmp y jpg pero que vas a poner más.
Vuelvo a aclarar, Delphi no almacena bitmap crudo. Si tu cargas en el TImage un jpeg sigue siendo físicamente un jpg. Es a efectos de visualización que todo formato es llevado hacia un mapa de bits, excepto el bitmap claro está porque así es la única forma en como es posible mostrar una imagen...
Una imagen es justamente eso: un conjunto (mapa) de pixeles. Lo que hace cada formato es aplicar algún algoritmo de reducción/compresión (con y/o sin pérdida).

Por ello es que por ejemplo si vas a Gimp y editas una imagen png, visualmente ves a nivel de pixeles. Luego el programa hace el paso inverso y genera un archivo respetando la estructura del formato png. Y así es con todos los formatos... estructura <-> mapa de bits.

Pero que quede claro: el TImage no almacena ni convierte físicamente un jpg en bitmap.... ni hace eso en las nuevas versiones con los nuevos formatos que soporta.

Empezado por ElMug

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.

Bueno, entiendo tu intención de limitarte a emplear JPG/JPEG y BMP. Pero es que tu mismo dijiste: "inicialmente", ergo: ¡vás por más! Y en la forma has redactado el hilo justamente das a entender que no te limitarás a estos 2 formatos sino que lo has tomado como puntapié para luego dar soporte a más.
Es a vista de eso que te sugiero de que cambies el enfoque porque de ese modo se te hará más fácil en el futuro.

Empezado por ElMug

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.

¡Que en el BLOB no se guarda nada cifrado! Lo que hay en el es lo que hay. ¡Por Dios! No sigas diciendo que hay cifrado donde no lo hay.
Bien por ti si ahora es JPEG o un BMP. Pero entonces, ¿Porqué dijiste entonces que se trata de una etapa inicial si en realidad no vas a ir por más? ¿Porqué tanto lío entonces para tratar de poner código INDEPEDIENTE de formatos como lo has señalado al comienzo?
La verdad es que te contradices, porque dejaste en claro que querías un sistema que pueda ser capaz de no verse atado a un único formato pero ahora dices que sólo quieres dos.

Empezado por ElMug

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.

Lo que yo veo es que no te agradó la idea de que se añade UN campo que poco y nada hace a tu sistema. Que te ofrece más cosas de las que tu crees. La verdad es que tu para trabajar con dos formatos te haz complicado demasiado la vida.

Y ya que tu crees que todo se resumen a guardar en bmp dime entonces, ¿porque has tenido que disponer el TJPGEImage? ¿Que no es que todo es bitmap? si en verdad lo que más buscas es que se resuma a bmp entonces hazte más fácil la vida: ¡guarda y trabaja únicamente con bmp! Al momento de guardar el contenido al BLOB convierte el formato del que sea a bmp (que como dices, hay rutinas que hacen eso... ha... y que no son tuyas) y de ese modo al momento de leer el BLOB ya te evitas todo problema y lees siempre un TBitmap. De paso ya no necesitas hacer nada de try finally y como no te gusta tener un campito más ¡te lo evitas!
Y otro plus, como ya es un TBitmap puedes realizar sobre éste operaciones de tratamiento de imagen como filtrado, etc.

Saludos,

[[Delphius]]

Por cierto, desde hace un tiempo que se viene diciendo y aconsejando que se deje de emplear jpg/jpeg y se pase a png; no sólo por una cuestión de licencias y derechos de autor sino también a que png es mucho mejor ante las pérdidas de calidad (e incluso pesa menos).
PNG ya es bastante habitué.

Saludos,

[[Al González]]

Empezado por ElMug

[...] Que haya o no otros metodos es irrelevante, especialmente si no ahorran una columna, y te forzan a descifrar [...] el metodo que les comparto, considero, le puede ser bastante util al que desee tratarlo, por su simpleza, eficacia, y robustidad.

Antes que nada, gracias por compartir tu código, ese digno y ejemplar acto es algo de lo más apreciado en cualquier foro de programación.

Ahora viene la crítica, con lo cual espero edificar algo sobre esta pequeña Damasco en que se ha convertido el hilo.

Forzar es precisamente lo que hace tu código: Le pides a un objeto TJPEGImage que intente asimilar cierto flujo de bytes, el cual puede o no puede ser una imagen de ese formato, por tanto se corre el riesgo (controlado) de que se le atragante la tostada y eleve una excepción.

En cuanto a que es simple (guardando las subjetividades a las que se presta esa palabra), por lo menos habría que eliminar sus partes innecesarias (asignación de Nil a Image1.Picture.Graphic) o repetidas ("BlobField := ...", y "BS := ..."), ya que ahorrar código es mucho más importante para la CPU que ahorrar campos para una base de datos. No tiene sentido volver a asignar el mismo valor a la variable BlobField, ni volver a llamar al método CreateBlobStream (en todo caso sólo reposicionar el flujo BS en su primer byte).

eficaz .- Que tiene eficacia. eficacia .- Capacidad de lograr el efecto que se desea o se espera.

Sí es eficaz, aunque con el desafortunado precio de nunca destruir los objetos TJPEGImage y TBitMap que asignas (copias) a Image1.Picture.Graphic. Con cada ejecución de ese código, tu programa estará ocupando más y más memoria; mira lo que hace TPicture:

Código Delphi [-]
procedure TPicture.SetGraphic(Value: TGraphic);
var
  NewGraphic: TGraphic;
begin
  NewGraphic := nil;
  if Value <> nil then
  begin
    NewGraphic := TGraphicClass(Value.ClassType).Create;
    NewGraphic.Assign(Value);
    NewGraphic.OnChange := Changed;
    NewGraphic.OnProgress := Progress;
  end;
  try
    FGraphic.Free;
    FGraphic := NewGraphic;
    Changed(Self);
  except
    NewGraphic.Free;
    raise;
  end;
end;

En cuanto a la robustidad, que en informática se considera libre de defectos o fallas de funcionamiento, hay que decir que ese código no es del todo robusto. Algunas de las razones son:

1. Asumes que "Image1.Picture.Graphic:= TJpegImage.Create" no va a causar ningún problema, por lo que BS podría quedar sin destruirse nunca.

2. Asumes que si falla el primer LoadFromStream, es definitivamente por no tratarse de una imagen JPEG. ¿Será la única razón por la cual pueda elevarse una excepción al ejecutar esa sentencia?

3. No hay ninguna garantía de que el objeto BS sea destruido si falla el segundo LoadFromStream. OK, todos hacemos pequeñas asunciones en nuestro código de cuando en cuando, ¿pero qué tal si aun siendo una imagen BMP, LoadFromStream tuviera dificultades para leerla?

4. La no liberación de los objetos TGraphic que creas.

Es lo que se puede notar en tu solución a simple vista. Es una mala práctica emplear "excepciones controladas" para determinar el flujo del programa; para tomar decisiones están los Ifs no los Excepts. ¿Que te ahorras campos? Muy bien, PERO siempre que no dejes tu aplicación llena de pequeñas trampas.

En cuanto al empleo de objetos auxiliares dentro de las rutinas, ya sabes la regla:

1. Apertura (creación)

Try
  2. Uso
Finally
  3. Cierre (destrucción)

Reitero, que bueno que has compartido tu código. Si tienes a bien hacerle las correcciones y mejoras pertinentes, de igual manera muchos te estaremos agradecidos por publicar la nueva versión.

Saludos a todos.

[roman]

Empezado por Al González

mira lo que hace TPicture

Pues justamente, se asegura de destruir el objeto Graphic que hubiera antes, o ¿a qué te refieres? En el resto de observaciones estoy de acuerdo.

// Saludos

[[Al González]]

Hola Román.

Empezado por Al González

[...] con el desafortunado precio de nunca destruir los objetos TJPEGImage y TBitMap que asignas (copias) a Image1.Picture.Graphic [...]

Código Delphi [-]
procedure TPicture.SetGraphic(Value: TGraphic);
var
  NewGraphic: TGraphic;
begin
  NewGraphic := nil;
  if Value <> nil then
  begin
    NewGraphic := TGraphicClass(Value.ClassType).Create;
    NewGraphic.Assign(Value);
    ...

Es que, como puedes ver, SetGraphic es el método de escritura de la propiedad Graphic. El objeto asignado a dicha propiedad es copiado (con el método Assign que ahí se ve) a NewGraphic / FGraphic (otro objeto).

En el código de ElMug:

Código Delphi [-]
      
      Image1.Picture.Graphic:= TJpegImage.Create; {assume is Jpeg}
      ...
        Image1.Picture.Graphic:= TBitMap.Create; {bitmap}

se crean dos objetos "al vuelo" que luego no son destruidos. Se quedan en la memoria esas instancias TJPEGImage y TBitMap.

Seguro es que no te iba a resultar nada difícil dar con ello, pero creo que no estuvo de más aclararlo.

Cambiando de tema, que bueno que regresaste. ¿Ya podemos irnos de vacaciones el resto de los milenarios? Mira que fue bastante arduo intentar cubrirte estas semanas.

Un abrazo.

Al.

[roman]

Sí. Tienes razón.

// Saludos

[ElMug]

Estimado Al Gonzalez,

Gracias por el interes y comentar.

Estas son mis observaciones a ellos:

1. Asumes que "Image1.Picture.Graphic:= TJpegImage.Create" no va a causar ningún problema, por lo que BS podría quedar sin destruirse nunca.
...............................
No. No causa problemas, porque "Image1.Picture.Graphic:= TJpegImage.Create" solo crea una INSTANCIA, prepara memoria, e inicializa propiedades. Es uso trivial, ver documentacion.

2. Asumes que si falla el primer LoadFromStream, es definitivamente por no tratarse de una imagen JPEG. ¿Será la única razón por la cual pueda elevarse una excepción al ejecutar esa sentencia?
...............................
En este comentario, no serias tu el que asume que asumo, pues de antemano es sabido que los Try detectan cualquier tipo de factor que le cause falla? A tu pregunta "Sera la unica razon?" la respuesta es obvia. NO. No se piensa que sea la unica razon. Pero LA RAZON de interes es que va a fallar si en el Blob no esta guardado un JPEG. Y lo mismo cuando se hace Try para Bitmap.


3. No hay ninguna garantía de que el objeto BS sea destruido si falla el segundo LoadFromStream. OK, todos hacemos pequeñas asunciones en nuestro código de cuando en cuando, ¿pero qué tal si aun siendo una imagen BMP, LoadFromStream tuviera dificultades para leerla?
....................
Si hay otra dificultad, el Try se encarga de marcar error. Eso es elemental. En el caso de un archivo defectuoso, el Try al final levanta un dialogo. El programador conocedor del uso del Try le puede agregar mas codigo, inclusive para que no levante dialogo, y el haga sus codigo con determinaciones especificas.

4. La no liberación de los objetos TGraphic que creas.
.....................
El codigo que muestro no se liberan objetos porque hay usos particulares que podrian requerir seguir usando el objeto. La destruccion de objetos creados la considero cuestion particular de la aplicacion. La creacion, que SI es necesaria, es lo que muestro.


Es lo que se puede notar en tu solución a simple vista. Es una mala práctica emplear "excepciones controladas" para determinar el flujo del programa; para tomar decisiones están los Ifs no los Excepts. ¿Que te ahorras campos? Muy bien, PERO siempre que no dejes tu aplicación llena de pequeñas trampas.
...................
No. Todo uso de recurso que facilite la plataforma de desarrollo no es ninguna trampa. Cuando funciona y no se puede demostrar que no funciona, lo que no es apropiado es juzgar en base en ataduras dogmaticas al pasado o a lo "convencional". Ademas, como seguramente sabes, los "ifs" no detectan errores de este tipo. Los "ifs" se usarian si el metodo es escudriñando el Blob en sus bits o bytes. Pero precisamente, porqe mi procedimiento no lo escudriña, los "ifs" NO se pueden usar y NO se usan. De hecho, base del procedimiento ES el uso de los Try's, y el uso de Try's no es ninguna trampa. Que a algunos les parezca "trampa" no creo poder evitarlo.

En cuanto al empleo de objetos auxiliares dentro de las rutinas, ya sabes la regla:
Código:

1. Apertura (creación)
Try
2. Uso
Finally
3. Cierre (destrucción)
...............
Esto es elemental. No se muestra destruccion de objetos creados. La aplicacion puede darle mas uso al objeto creado, y si no lo requiere, se encargue de destruirlo. En otras palabras, el procedimiento trabaja sin destruirlos. La creacion de esos objetos es necesaria, y se muestra. Destruirlos es opcional y en X caso aplicado, es particular, y funcion del programador.

Espero que esto module tus concernimientos y veas que lo compartido si puede ser de utilidad, si no a algunos, a otros si.

[roman]

A lo que Al se refiere en el punto 1 es a que la mera asignación:

Código Delphi [-]
Image1.Picture.Graphic:= TJpegImage.Create;

podría causar una excepción, por ejemplo, por falta de memoria o alguna otra razón imprevisible, como son las excepciones. Si ese fuera el caso, dado que tal excepción no está protegida por un bloque try-except, el código donde liberas a BS (creado anteriormente) no llegaría a ejecutarse y tendrías una fuga de memoria.

Por otra parte, estoy de acuerdo en que un objeto no necesariamente debe destruirse en el mismo contexto en donde se creó ya que posteriormente puede usarse. Sin embargo, en el caso particular que muestras, dicha liberación jamás podría darse ya que pierdes toda referencia al objeto creado, que es lo que explica Al. Cuando asignas:

Código Delphi [-]
Image1.Picture.Graphic := TJpegImage.Create;

la parte derecha de la asignación crea un objeto que se pasa como parámetro al método TPicture.SetGraphic que citó Al. Pero este objeto no es el mismo que finalmente se guarda en el campo privado FGraphic de TPicture ya que Assign hará una copia del objeto. Como el parámetro se pierde después de la llamada, no tienes ninguna variable que apunte al objeto y por tanto no podrás hacer invocar al método Free.

Si realmente se piensa usar posteriormente el objeto creado, tendrías que usar asignar el resultado de Create a una variable y ésta asignarla a TPictureGraphic:

Código Delphi [-]
Graphic := TJpegImage.Create;
Image1.Picture.Graphic := Graphic;

Por otra parte, me da la impresión que nos hemos alejado de tu pregunta inicial. ¿Sigues teniendo el mismo problema que mencionas en el comentariio original?

// Saludos

[ElMug]

Empezado por roman

A lo que Al se refiere en el punto 1 es a que la mera asignación:

Código Delphi [-]Image1.Picture.Graphic:= TJpegImage.Create;


podría causar una excepción, por ejemplo, por falta de memoria o alguna otra razón imprevisible, como son las excepciones. Si ese fuera el caso, dado que tal excepción no está protegida por un bloque try-except, el código donde liberas a BS (creado anteriormente) no llegaría a ejecutarse y tendrías una fuga de memoria.

Por otra parte, estoy de acuerdo en que un objeto no necesariamente debe destruirse en el mismo contexto en donde se creó ya que posteriormente puede usarse. Sin embargo, en el caso particular que muestras, dicha liberación jamás podría darse ya que pierdes toda referencia al objeto creado, que es lo que explica Al. Cuando asignas:

Código Delphi [-]Image1.Picture.Graphic := TJpegImage.Create;


la parte derecha de la asignación crea un objeto que se pasa como parámetro al método TPicture.SetGraphic que citó Al. Pero este objeto no es el mismo que finalmente se guarda en el campo privado FGraphic de TPicture ya que Assign hará una copia del objeto. Como el parámetro se pierde después de la llamada, no tienes ninguna variable que apunte al objeto y por tanto no podrás hacer invocar al método Free.

Si realmente se piensa usar posteriormente el objeto creado, tendrías que usar asignar el resultado de Create a una variable y ésta asignarla a TPictureGraphic:

Código Delphi [-]Graphic := TJpegImage.Create; Image1.Picture.Graphic := Graphic;


Por otra parte, me da la impresión que nos hemos alejado de tu pregunta inicial. ¿Sigues teniendo el mismo problema que mencionas en el comentariio original?

// Saludos

Hola Roman,

Esta linea
Image1.Picture.Graphic:= TJpegImage.Create; NO causa excepcion (Lo verifique desde el inicio de mi desarrollo).

Ahora que si la computadora tenga falla de hardware, pues yo creo que primero fallarian otras cosas, no crees? Por que quererle echar ese chango en la espalda a este leve desarrollo que les deseo compartir?

Yo no veo nada practico en programar este procedimiento considerando que pueda fallar la memoria o el CPU, o alguna otra cosa de hardware.

Ademas, acuerdate que mi procedimiento se basa en que la imagen YA ESTA GUARDADA en el archivo, independientemente de mi proceso, lo cual demuestra que seria dificil que hubiera problema para manejar esa imagen.

Ahora, que si hay guardados en el Blob archivos defectuosos, o invalidos, eso pues no lo causa mi procedimiento, aunque SI los atrapa como error y los rechaza.

Ahora, si puede alguien mostrarme ejemplos, manuales, o documentacion donde alguien use el Try para CREATE, pues favor de hacerlo.

Yo si les puedo mostrar esta pagina de expertos donde NO usan Try en ningun CREATE, pues como les digo anteriormente, CREATE no levanta EXEPTion.

Y lo pueden ver aqui, donde el titulo del tema es :
How to correctly write Try..Finally..Except statements?

Bueno, hasta luego, y gracias por los comentarios.
.......................

P.S. El problema del mensaje original, es que no me entendieron la pregunta. No es un problema que "tenga". Ya recibi aclaracion en el foro de Lazarus. Pero parece ser que no hay respuesta definitiva.

[Casimiro Notevi]

Empezado por ElMug

Yo si les puedo mostrar esta pagina de expertos...

Eso me ha hecho gracia

[ElMug]

Empezado por Casimiro Notevi

Eso me ha hecho gracia

Quien quiere ver circo en todo, pues muy su parecer.

[roman]

Empezado por ElMug

P.S. El problema del mensaje original, es que no me entendieron la pregunta. No es un problema que "tenga". Ya recibi aclaracion en el foro de Lazarus. Pero parece ser que no hay respuesta definitiva.

Yo sí entendí la pregunta: quieres saber si el formato con que se guarda una imagen en un campo blob es independiente de la aplicación con que se guarde o lea. También sé la respuesta: sí es independiente (creo que Delphius también lo mencionó). Si no puedes leer en una aplicación la imagen guardada en otra aplicación entonces hay un problema en la forma de leer la imagen.

// Saludos

[ElMug]

Empezado por roman

Yo sí entendí la pregunta: quieres saber si el formato con que se guarda una imagen en un campo blob es independiente de la aplicación con que se guarde o lea. También sé la respuesta: sí es independiente (creo que Delphius también lo mencionó). Si no puedes leer en una aplicación la imagen guardada en otra aplicación entonces hay un problema en la forma de leer la imagen.

// Saludos

Hola Roman,

Es un poco mas alla el asunto de "independiente de la aplicacion".

Creo que lo diria asi "independiente de los diversos generadores de aplicaciones", mi cuestion, y aun me interesa saber de otras personas al respecto, porque el asunto se aboca a la centralizacion de bases de datos, en las que diversas aplicaciones clientes accedan al dato Blob.

Si digo "un poco mas alla", es porque aunque se llene el viejo criterio de C. F. Codd en el significado de "la data debe de ser independiente de la aplicacion", pues si lo llena en si, cada plataforma generadora de aplicaciones. Eso ya es rutina en bases de datos actuales.

Pero, por ejemplo, si centralizamos una base de datos y generamos, por decir un .exe de acceso con Lazarus, y uno con Delphi, usando practicamente el mismo codigo, DEBERIA de leer las imagenes que guarde uno, el otro, y viceversa. Pero no estoy seguro que eso pase con los campos Blob, asi como se puden leer los textos y numericos con plena compatibilidad.

Se me ha informado que Lazarus (indebidamente segun mi punto de vista) le AGREGA unos bytes al archivo Blob, lo cual haria la data dependiente de la aplicacion que genere el generador de aplicaciones Lazarus. Y tambien se me ha informado que Delphi no le agrega nada.

Pero es un poco mas complicado de concluir, porque en Lazarus, puede uno utilizar otros componentes que no sean los "default" de Lazarus.

Mi plan es, ya indagando un poco mas, usar los componentes que mas sea compatibles en eso con los demas generadores de aplicaciones.

Averiguar todo esto, debido a que hay bastantes plataformas generadoras de aplicaciones, que usan diversas tecnologias como Java, C++, etc., no es tan facil para uno encarar todo eso, pues tendria uno que instalar varias plataformas y generar sus aplicaciones para ello.

Pero, si el detalle es solo con Lazarus, y todos las demas plataformas guardan el Blob igual, tal como lo extraen del archivo de la grafica, pues es mas simple de resolver.

Asi que el problema no es de "leer" sino de como se "guarda" o almacena el archivo segun las diversas plataformas de programacion, o los componentes que se usen.

Y si este tema ya se vio antes, y hay respuestas y conclusiones, y asesoria al respecto, pues mucho les agradeceria saber de ello, pues de mi parte no encuentro aun nada conclusivo.

Lo que si, es que ya verifique que hay deferencia entre como guarda Lazarus y como guarda el SQLite Administrator.

Aclaro tambien que esto no debe de tener nada que ver con cual database se use.

Tambien aclaro que me inclino a pensar que tal vez el problema sea solo con los componentes default de Lazarus, pero no puedo concluir eso aun, en definitiva.

Tampoco descarto que haya algo que no he considerado.

Gracias por el interes en ayudar a resolver esto.