SoloCodigo

Gracias enko.

Si convierten esta a bmp tambien les puede fallar.

Ya encontré la solucion.


Como el intercambio de info en el thread está permitido,
Posteo en Ingles, ya que no soy buen traductor. Eso es lo único que hace falta ademas de saber como es la cabecera.

Few things to remember
1) Unfortunately, BMP data is not written from left to right -> left to right etc (like we read a book), insted it is written from right to left -> right to left etc from Bottom to Top. That means writing of pixel data starts from Bottom Right and ends in Top Left. In our example the problem will not reflect, since all the 100 (10 x 10) pixels are same pale magenta!

2) The number of bytes of the Picture Data in one each row should be a multiple of 4. We have to padd extra zeroes to kame it a multiple of 4. In our case, the picture's width is 10 pixels. So find the remainder of the division 10 / 4. The remainder is 2. So TWO zero bytes should be padded with each row's data.

Con el heditor exadecimal me había dado cuenta que se agregaban 00 demás, pero pensé que solo era al final del archivo y no entendía el sentido.

Yo tenía esto:

Ok, me apuro, voy a reescribir la función de carga de info del mapa de bits, voy a intentar con wxWidgets y lo que tenía me da muchos errores por los tipos de datos .

Ahorita mismo hice unas pruebas para convertir un wxString a char* y me está dando muchos dolores de cabeza, por eso voy a reescribir las funciones para que reciban como parámetros tipos de wxWidgets.

saludos,
JJ (Geo).

oK , LA INFROMACION ESTA DEVUELTA.

Mi solucion, si mal no estoy es:

Código: Text

1. ancho= (BMPwith * bytesPerPixel);
2. ...
3.  
4. ancho+= ancho%4;
5. bitsize = ancho * alto_imagen;
6.  

Hola!!

La verdad es que creo que esta mal. La solucion seria:


Por lo que no vale tu forma es por que si tengo una imagen de 5x5, ancho es 15, y ancho = 15 + 15%4 = 15 + 3 = 18, que sigue sin ser multiplo de 4.

La otra forma que postearon antes tambien era valida (es la que yo use en mi solucion). Lo que te hace es ahorrarte la comprobacion y calcular el modulo, es decir dos divisiones... La verdad que no es gran cosa por que esta operacion solo deberia de hacerse una vez en todo el codigo, pero menos es nada

Un saludo!!

Código: Text

1. while (bytesLineaRelleno % 4 != 0)
2.    bytesLineaRelleno++;
3.  

Ahora que veo estas lineas de geo, se me hacen muy familiares, no descartaria que asi fuera como yo lo tenia.

Citar

padWidth := FWidth mod 4;
    for j:=FHeight downto 1 do
    begin
      for i:=1 to FWidth do
      begin
        BlockRead(F, Pixel, sizeOf(Pixel), Transfer);
        if Transfer=0 then Break;
        Pixels[i,j] := Pixel;
      end;
      Seek(F, FilePos(F)+padWidth);
    end;

Basicamente los que hace es:
Leer completamente la Fila y luego se saltea en el archivo los Bytes agregados (pueden ser 1,2 o 3).
FilePos, es la posicion actual en el fichero, padWidth, son los bytes necesarios para que sea multiplo de 4 el ancho.

PD:
Leer pixel por pixel es lento. Se puede usar de seguro un MemCopy para leer toda la fila (por eso es multiplo de 4).

Asi es enko.

En efecto alguna vez lei que se dejode 24 bit porque es mucho mas rapido manejar los movimientos con un entero de 32 que con un short de 16 y un byte de 8.

La transferencia del bloque completo es la mejor y mas rapida, y fue la que use en mi caso aunque no hice paso por fila sino paso directo de todo ( en la parte del dibujo).

Estoy en el módulo Dibujo y tengo algunas dudas con la información del cabezal del archivo bmp:
No entiendo la diferencia entre ncolours e importantcolours. Hice un programita de prueba que despliega en pantalla todos los datos del bmp y me sale todo coherente (al menos para mi) hasta:

xresolution=0;
yresolution=0;
ncolours=0;
importantcolours=0;

  ¿eso está bien?... yo pensaba que ncolours almacenaba la cantidad de colores que tiene  el bmp, pero como me sale 0 parecería que es otra cosa.

... ¿y que son los importantcolours?... ¿colores importantes?... ¿está bien que sea 0?

Análoga duda con xresolution e yresolution  

No entiendo la diferencia entre ncolours e importantcolours. Hice un programita de prueba que despliega en pantalla todos los datos del bmp y me sale todo coherente (al menos para mi) hasta:

xresolution=0;
yresolution=0;
ncolours=0;
importantcolours=0;

  ¿eso está bien?... yo pensaba que ncolours almacenaba la cantidad de colores que tiene  el bmp, pero como me sale 0 parecería que es otra cosa.

... ¿y que son los importantcolours?... ¿colores importantes?... ¿está bien que sea 0?

Análoga duda con xresolution e yresolution  

El primero da el número de colores presentes en el mapa de bits cuando este es de menos de 24 bits, y, para el tipo de mapa de bits que estamos manejando efectivamente es 0.

El otro indica el número de colores (o el númeor de índices de colores) que son importantes para mostrar el mapa de bits, cuando todos son importantes este campo vale 0.

JuanK, también me gustaría que me comentaran al respecto sobre ese código .

Saludos,
JJ (Geo).

Citar

ancho = (ancho + 3) & ~3;

Citar

ancho := (ancho + 3) and not 3;

Esto devuelve un numero multiplo de 4 menor a X. Es decir:
Multiplo de 4 < X

Código: Text

1.  
2. result := X and not 3;
3.  
4.  

Por eso es ancho + 3, para que al devolver el menor, sea en realidad el acho + los bytes  extra.

es como sacar el resto pero m'as rapido.
aunque todavia no logro entender los de AND NOT, tendria que ser como + -, es decir, al final el numero de entrada ser'ia el mismo que el de la salida.

Hasta ahi creo que hemos entendido todos... pero aun queda la gran duda de:

como demonios    se deduce eso    

Hola!!

Código: Text

1.  
2. ancho = (ancho + 3) & ~3; */ alineado en 4 bytes*/
3.  

La deduccion no es tan sencilla...

Para verlo, trabajando en base 10 es mas facil.

Digamos que quieres hacer que un numero sea multiplo de 100. Tienes tres opciones para redondearlo:

a ) Por defecto: Lo que se haria es forzar los dos ultimos digitos a cero.
b ) Al mas proximo: Sumas la mitad de la precision que quieres dar, y fuerzas los dos ultimos digitos a cero. En este caso, se sumaria 50. Sabes que para los menores de 49 se te queda en la centena anterior (por que subes como mucho a 99), y el resto se te pasan a la siguiente centena. Esto se suele usar mucho en aritmetica de coma flotante...
c ) Por exceso: El usado aqui. Es similar al anterior, solo que en lugar de sumar 50 se sumarian 99. Asi haces que todos suban a la centena superior salvo en el caso de que ya sea multiplo de 100.

Pues lo mismo, pero en base 2 y buscando multiplos de 4. Sumas tres, y con el AND fuerzas que los dos ultimos bytes sean cero (not 3 == 0xFFFFFFFC).

Espero haberme explicado... Yo por lo menos fue asi como lo vi.

Saludos!!

Citar

como demonios devil.gif se deduce eso scream.gif question.gif

Creo que ahí estamos hablando sobre un hiptético programador ideal, omniciente, omnipotente y perfecto que nos deja estos tips, y pasan de codigo a código.

jejeje tienes razon.

b ) Al mas proximo: Sumas la mitad de la precision que quieres dar, y fuerzas los dos ultimos digitos a cero. En este caso, se sumaria 50. Sabes que para los menores de 49 se te queda en la centena anterior (por que subes como mucho a 99), y el resto se te pasan a la siguiente centena. Esto se suele usar mucho en aritmetica de coma flotante...
c ) Por exceso: El usado aqui. Es similar al anterior, solo que en lugar de sumar 50 se sumarian 99. Asi haces que todos suban a la centena superior salvo en el caso de que ya sea multiplo de 100.

Con estos dos ya he visto un poco la luz yme parecen unos puntos clave.

Uhm... Creo que lo suyo es que se comente al final, cuando todos hayamos acabado el reto... Si no le quita un poco la gracia  

De todas formas JuanK, si hay algo que te guste comentar de mi programa en particular, ya sabes que es de sobra bienvenido. Yo veo esto como una forma de que otros que saben mas que yo vean mi codigo y me ayuden a mejorar.  

Un saludo!