Consulta para los Cracks - Formato FPG

[proteo]

Buenas, como va? no se si este es el lugar indicado para hacer este tipo de consultas, pero estoy tratando de descifrar la organizacion de un archivo FPG para abrirlo desde Java. Revisando el codigo fuente de Bennu extraje lo siguiente y necesitaria si me pueden corregir si algo esta mal o falta algo


Posisiones de Bytes

1..8 Header (longitud: 8 )

Este dice que tipo de FPG es para determinar los bits por pixel.

9..12 regSize (longitud: 4)

Supongo que es la longitud del registro pero no se usa.

13..44 name (longitud: 32)

un nombre.

45..56 fpname (longitud: 12)

otro nombre.

57..60 ancho de la imagen (longitud: 4)

61..64 alto de la imagen (longitud: 4)

65..68 flags (longitud: 4)

flags

luego empieza a tomar tantos trosos de 4, 2 o 1 byte por pixel segun lo que se haya obtenido en el header como indique el ancho de la imagen y esta operacion la realiza tantas veces como el alto de la imagen.

Todos estos pixeles van a para a un bitmap en memoria.

por ultimo pasa al siguiente y asi suscesivamente hasta terminar el archivo.

Esto es lo que pude recolectar hasta ahora, estoy tratando de levantar este archivo con Java, pero tengo la duda de si en C los int son de 2 o 4 bytes (en Java fija que son de 4), lo que esto repercutiria en lo que estos levantando del archivo porque me desplazaria toda la lectura dos Bytes. El otro problema es como Java organiza estos bytes, si littleendian o bigendian(Byte bajo primero, byte alto despues o al revez) ya que estoy utilizando la clase FileInputStream y DataInputStream que me permiten hacer lecturas por tipo, pero obvien esto ultimo. Nada mas necesito validar la organizacion del archivo FPG y preguntar si existe alguna documentacion al respecto mas que el fuente.

Desde ya muchas gracias.
Saludos.

[proteo]

LO HE LOGRADOOOOO, jajajajajaja, por fin, encontré como estan codificados los pixeles en los FPG de 32, cada pixel, compuesto por 4 bytes, esta guardado en BGRA, por lo que despues de invertir los bytes (Gracias a SplinterGU por decirme que el Alpha es el primer dato y teniendo en cuenta que los datos estan invertidos en el archivo) y realizar unos ajustes a nivel bit con desplazamientos, and y or quedo listo el pollo

Code Select Expand


// El pixel biene codificado en 4 bytes (BGRA)
// Invierto los Bytes para que quede en (ARGB)
int pixel = Integer.reverseBytes(entrada.readInt());
// Separo el alpha
int a = (pixel & 0xff000000);
// lo llevo al byte menos significativo
a = (a >> 24) & 0x000000ff;
// desplazo un byte hacia la izquierda para que queden RGB en los 3 primeros bytes y luego agrego el alpha en el
// byte menos significativo
int p = (pixel << 8) | a;


En "p" queda el pixel en formato RGBA que es como lo necesito.

Ahora puedo continuar con mi proyecto, en breve tendrán novedades.

[SplinterGU]

no, no, no esta en BGRA, esta en RGBA, el orden de los bytes es ese... una cosa es memoria (que depende de la arquitectura) y otra cosa es el orden dentro de la palabra de 32bits... originalmente RGB, luego se le agrego la A...

pero RGBA es

0x000000ff es BLUE
0x0000ff00 es GREEN
0x00ff0000 es RED
0xff000000 es ALPHA

es un poco raro de entender, pero ese es RGBA

mas detalles http://en.wikipedia.org/wiki/RGBA_color_space

[proteo]

no, no, no esta en BGRA, esta en RGBA, el orden de los bytes es ese... una cosa es memoria (que depende de la arquitectura) y otra cosa es el orden dentro de la palabra de 32bits... originalmente RGB, luego se le agrego la A...

pero RGBA es

0x000000ff es BLUE
0x0000ff00 es GREEN
0x00ff0000 es RED
0xff000000 es ALPHA

es un poco raro de entender, pero ese es RGBA

mas detalles http://en.wikipedia.org/wiki/RGBA_color_space

Si, puede ser que al hacer un readInt en java, termina acomodando los bytes de otra forma. Igual ya los pude acomodar ,  al principio pensaba que era RGBA, osea, mandaba al bitmap los pixeles como los levantaba del archivo, pero resulta que estaban desordenados. Ya esta funcionando.

Muchas gracias por tu tiempo.

Abrazo.