TODOPIC
Lenguajes de programación para PC => C, C#, C++ => Mensaje iniciado por: migsantiago en 06 de Abril de 2008, 15:11:37
-
Hola
He buscado en internet pero no sé ni cómo buscar lo siguiente. Tengo un archivo llamado picture.s el cual contiene el siguiente código...
.rodata
.balign 32
.globl piclength
.globl picdata
piclength: .long picdataend - picdata
picdata:
.incbin "../source/test.jpg"
picdataend:
Hasta donde entiendo, lo que hace es convertir un archivo y lo incluye en el código compilado de un programa. El programa al que se incluye el archivo es el siguiente...
/*** External Picture ***/
//these come from picture.s
extern char picdata[];
extern int piclength;
El valor de picdata es un arreglo llenado con los bytes del archivo jpeg y piclength es la longitud de picdata.
Lo que me gustaría saber es en dónde puedo estudiar cómo hacer un archivo s, que creo que se llama asm stub, entender lo de rodata o balign. ¿Alguien me puede ayudar? :5}
Gracias :mrgreen:
-
Estuve leyendo un poquito aquí y allá sobre el formato que mencionas y no vi nada en concreto.
Lo que sí alcanzo a interpretar es que en realidad el archivo .s es un archivo en assembly para el micro/plataforma que estas usando.
Es decir que no hay una forma de generar un 'asm stub' en realidad lo que creo que es , es código assembly el cual es llamado desde tu código C.
Siguiendo con mis intrepretaciones, lo que debieras hacer es aprender como es el ensamblador que estas/estan usando :)
-
Normalmente deberia existir una aplicación que te haga la comversión automática, es decir partir de un archivo JPG convertirlo a un assembler "especial", yo la buscaria en todos los ejecutables del entorno, tambien lo que dijo Maunix es posta, deberias estudiar el assembler de esa arquitectura. Aunque no la conozco trato de aplicar el sentido comun.
.rodata
.balign 32
.globl piclength
.globl picdata
piclength: .long picdataend - picdata
picdata:
.incbin "../source/test.jpg"
picdataend:
.RODATA especifica que las declaraciones sgtes se alocaran en ROM o segmentos de código.
.BALING 32 especificara una alineación a byte con gaps de 32 bytes, es decir si vos alocas dos word empezando en la posición 0x100, el segundo lo aloca en la posicion 0x120 ( esto es normalmente cuando los micros son mas rapidos en tomar direcciones pares que impares, pasa tb en el 68000 )
.globl piclength son variables que tienen alcanze global
piclength: .long una declaracion de un long
.incbin incluir en forma binaria un file
Mirando esto me parece que no es necesario una herramienta auxiliar, solo metiendo esto y algunas directivas mas lo tenes cocinado.
Saludos !
-
Puff, estudiar la arquitectura de un procesador PowerPC de 128 bits me da miedo :D :shock:
Pero con tu explicación me queda más claro el porqué del archivo. Lo que hasta ahora sabía es que el archivo es "compilado" junto con mi código en main.c e "inyecta" el archivo jpeg al archivo ejecutable de salida, claro... lo inyecta en una variable global.
Lo que no entiendo es lo de picdataend. Luego pone piclength que es igual a picdatalength menos picdata, pero parece que que picdataend está incompleto, se queda en
picdataend:
pero no dice nada después de los dos puntos :shock:
-
Hola, aparentemente es una manera de poder calcular el largo de los datos binarios del archivo jpg, en verdad son dos offset,
Entonces al conocer el fin del archivo pude resolver esto:
piclength: .long picdataend - picdata
Saludos !
-
Ah, siendo offsets entonces miden la distancia en bytes de lo contenido entre ellos, ¿no?
Gracias :mrgreen:
-
Lo que yo veo es que incluyen "binariamente" de plano el archivo .jpg
Luego se declara un "puntero" hacia dicho contenido en memoria de programa y por último se conoce el largo del mismo.
De lo que no te salvas es de que el código C deba interpretar/descomprimir ese archivo jpg. No se podría mandar así de un solo paso a una pantalla por ejemplo.
El jpg o cualquier formato comprimido permiten almacenar la información en poco lugar pero a la hora de mostrarlo en una pantalla no te queda otra que regenerar el mapa de bits de la imagen.
-
Coincido con Maunix, seguramente la plataforma debe incluir el SDK correspondiente para displayar un archivo de imagenes.
Saludos !
-
jeje claro que lo descomprime después... les paso el programa completo para no dejar cosas a la imaginación :D
/****************************************************************************
* libogc - libjpeg test
****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <gccore.h> /*** Wrapper to include common libogc headers ***/
#include <ogcsys.h> /*** Needed for console support ***/
#include <string.h>
#include <jpeg/jpgogc.h>
//Extract jpeg6bogc.7z (jpeg library) to powerpc-gekko folder,
//including lib and bin folders
//if that doesn't work, try recompiling the src files
//makefile should say:
//LIBS := -logc -ljpeg
/*** External Picture ***/
//these come from picture.s
extern char picdata[];
extern int piclength;
/*** 2D Video Globals ***/
GXRModeObj *vmode; /*** Graphics Mode Object ***/
u32 *xfb[2] = { NULL, NULL };
/*** Framebuffers ***/
int whichfb = 0; /*** Frame buffer toggle ***/
/****************************************************************************
* Initialise Video
*
* Before doing anything in libogc, it's recommended to configure a video
* output.
****************************************************************************/
static void
Initialise(void)
{
VIDEO_Init(); /*** ALWAYS CALL FIRST IN ANY LIBOGC PROJECT!
Not only does it initialise the video
subsystem, but also sets up the ogc os
***/
PAD_Init(); /*** Initialise pads for input ***/
/*** Try to match the current video display mode
using the higher resolution interlaced.
So NTSC/MPAL gives a display area of 640x480
PAL display area is 640x528
***/
switch (VIDEO_GetCurrentTvMode()) {
case VI_NTSC:
vmode = &TVNtsc480IntDf;
break;
case VI_PAL:
vmode = &TVPal528IntDf;
break;
case VI_MPAL:
vmode = &TVMpal480IntDf;
break;
default:
vmode = &TVNtsc480IntDf;
break;
}
/*** Let libogc configure the mode ***/
VIDEO_Configure(vmode);
/*** Now configure the framebuffer.
Really a framebuffer is just a chunk of memory
to hold the display line by line.
***/
xfb[0] = (u32 *) MEM_K0_TO_K1(SYS_AllocateFramebuffer(vmode));
/*** I prefer also to have a second buffer for double-buffering.
This is not needed for the console demo.
***/
xfb[1] = (u32 *) MEM_K0_TO_K1(SYS_AllocateFramebuffer(vmode));
/*** Define a console ***/
console_init(xfb[0], 20, 64, vmode->fbWidth, vmode->xfbHeight,
vmode->fbWidth * 2);
/*** Clear framebuffer to black ***/
VIDEO_ClearFrameBuffer(vmode, xfb[0], COLOR_BLACK);
VIDEO_ClearFrameBuffer(vmode, xfb[1], COLOR_BLACK);
/*** Set the framebuffer to be displayed at next VBlank ***/
VIDEO_SetNextFramebuffer(xfb[0]);
/*** Get the PAD status updated by libogc ***/
VIDEO_SetPostRetraceCallback(PAD_ScanPads);
VIDEO_SetBlack(0);
/*** Update the video for next vblank ***/
VIDEO_Flush();
VIDEO_WaitVSync(); /*** Wait for VBL ***/
if (vmode->viTVMode & VI_NON_INTERLACE)
VIDEO_WaitVSync();
}
/****************************************************************************
* Main
*
* jpeg.c - Demo for libjpeg wrapper function
****************************************************************************/
int
main(int argc, char **argv)
{
JPEGIMG jpeg;
int row,
col,
pix,
offset;
unsigned int *jpegout;
memset(&jpeg, 0, sizeof(JPEGIMG));
Initialise(); /*** Setup video ***/
printf("\n\nlibjpeg 6b demo\n");
/*** Set the Mandatory values ***/
jpeg.inbuffer = picdata;
jpeg.inbufferlength = piclength;
/*** Call decompressor ***/
JPEG_Decompress(&jpeg);
printf("Press A to show image\n");
while (!(PAD_ButtonsDown(0) & PAD_BUTTON_A));
while (PAD_ButtonsDown(0) & PAD_BUTTON_A);
whichfb ^= 1;
pix = 0;
jpegout = (unsigned int *) jpeg.outbuffer;
offset = 0;
for (row = 0; row < jpeg.height; row++) {
for (col = 0; col < (jpeg.width >> 1); col++)
xfb[whichfb][offset + col] = jpegout[pix++];
offset += 320;
}
/*** IMPORTANT - RELEASE THE MEMORY BUFFER ***/
free(jpeg.outbuffer);
/*** And show the image ***/
VIDEO_SetNextFramebuffer(xfb[whichfb]);
VIDEO_Flush();
VIDEO_WaitVSync();
while (1);
return 0; /*** Keep gcc happy ***/
}
Una persona compiló la librería libjpeg6 y la adaptó al procesador del cubo, lo único que hago es instalar la librería y usar su estrucutra, y después depositar el jpeg en un buffer, y por último decirle... "descomprímelo" y ya :mrgreen:
Luego se vuelca el contenido de la imagen en un buffer de video y se refresca la pantalla y listo, imagen en pantalla.
Lo curioso es que el buffer de video del cubo es de 320x480 porque con un entero de 32 bits se expresa el contenido de 2 pixeles usando un formato llamado Y1CbY2Cr, diferente al estándar RGB. En un futuro voy a tener que aprender a "extrapolar" imágenes mayores a 640x480 para hacerlas entrar a la pantalla de una tv NTSC, pronto les estaré pidiendo ayuda :-)
-
jeje claro que lo descomprime después... les paso el programa completo para no dejar cosas a la imaginación :D
Una persona compiló la librería libjpeg6 y la adaptó al procesador del cubo, lo único que hago es instalar la librería y usar su estrucutra, y después depositar el jpeg en un buffer, y por último decirle... "descomprímelo" y ya :mrgreen:
Luego se vuelca el contenido de la imagen en un buffer de video y se refresca la pantalla y listo, imagen en pantalla.
Buenisimo y practiquisimo :)
Lo curioso es que el buffer de video del cubo es de 320x480 porque con un entero de 32 bits se expresa el contenido de 2 pixeles usando un formato llamado Y1CbY2Cr, diferente al estándar RGB. En un futuro voy a tener que aprender a "extrapolar" imágenes mayores a 640x480 para hacerlas entrar a la pantalla de una tv NTSC, pronto les estaré pidiendo ayuda :-)
Jeje, mientras pueda te daré una mano... algunas cosas son aplicar sentido común a la sintaxis que uno ya conoce (como fue en este caso) pero en algunas otras oportunidades en ejemplos/casos muy específicos realmente hay que tener experiencia de campo para poder sugerir algo coherente. Así que si te tiras un tema 'mortal' espero poder ayudarte jiji.
-
Jeje, mientras pueda te daré una mano... algunas cosas son aplicar sentido común a la sintaxis que uno ya conoce (como fue en este caso) pero en algunas otras oportunidades en ejemplos/casos muy específicos realmente hay que tener experiencia de campo para poder sugerir algo coherente. Así que si te tiras un tema 'mortal' espero poder ayudarte jiji.
Agradeceré mucho su apoyo Sr. Mauricio, a.k.a. "El Changuito Asustado". :D
Es un tema interesante el de extrapolar ya que hay que retirar pixeles, pero el chiste es saber cuáles. Otra opción no es retirarlos, sino revolver sus colores con los pixeles contiguos y sacar un pixel nuevo... ¿pero en qué cantidad se deberán revolver? Les aviso cuando tenga lista la pregunta. :mrgreen:
-
Agradeceré mucho su apoyo Sr. Mauricio, a.k.a. "El Changuito Asustado". :D
:mrgreen: :mrgreen:
¿pero en qué cantidad se deberán revolver? Les aviso cuando tenga lista la pregunta. :mrgreen:
O cuando tengas lista la respuesta :D :D :D
-
¿pero en qué cantidad se deberán revolver? Les aviso cuando tenga lista la pregunta. :mrgreen:
O cuando tengas lista la respuesta :D :D :D
Podría ir al laboratorio de reconocimiento de patrones de mi escuela y pedirles el algoritmo, pero mejor lo investigo solo y así sorprendo a mi maestro de programación. Acá en el foro lo voy a resolver con ustedes.
-
Hola
Ya encontré una guía básica de cómo escalar una imagen, hacerla grande o pequeña.
http://www.4shared.com/file/43967855/d2ce5bb1/Image_Scaling.html
Ahora mi problema no. 1 es el mezclado de los colores para reducir una imagen. Parecería simple si el formato del buffer de video del cubo estuviera en RGB, solo promediaría el valor RGB de cada pixel, pero como está en un formato alienígena Y1CbY2Cr, tengo trabajo para rato. Los mantendré informados :mrgreen:
Por ahora ya pedí auxilio en el foro de programación homebrew, pero parece que nadie me ha escuchado :D
http://www.tehskeen.com/forums/showthread.php?p=28980#post28980
-
Varias fórmulas de conversión entre diferentes espacios de color las puedes encontrar en Wikipedia, sobre los algoritmos, busca si se pueden expresar en el espacio que estás manejando (YCbCr), ya que la conversión a RGB y de vuelta aumenta tiempo al procesamiento, si no encuentras en la web busca en libros de procesamiento de imágenes.
Suerte.
-
Gracias Geo
Wikipedia no es clara en su página porque confunde YUV con YCbCr y luego dicen que no es lo mismo.
Voy a trabajar con Ycbcr sin pasar por RGB, lo complicado ahora es el tomar los pixeles de una matriz :? Como tú dices, es mucho procesamiento el andar pasando de formato a formato.
-
Yo he localizado este documento donde se explica como pasar de RGB a YCbCr:
http://cpdsi-fich.wikidot.com/local--files/tpsaplicacion/2005_Ramello-Piel.pdf
Y otra página interesante:
http://campusvirtual.uma.es/tdi/www_netscape/TEMAS/Tdi_16/index4.php
Un saludo
-
Uy muy interesantes, gracias Jesús. :mrgreen:
-
Hola!
Después de estudiar y batallar y ver mil y una pantallas de code dump en mi gamecube, logré compilar un programa que abre jpeg's y las muestra en pantalla, escalándolas a 640x480 si es necesario.
Ya me volví un experto en el formato y1cby2cr, pero lo malo es que solo el gc o el wii lo utilizan :D
Les presumo mi hazaña 8)
-
Felicitaciones por tus logros :-)
-
Gracias Richi, ya estaba preocupándome porque lo tengo que presentar como proyecto escolar para dentro de 2 semanas, y las ventanas de error y bugs no se dejaban domar :mrgreen:
-
Miguel te felicito! ¡¡¡se ven buenisimas las imágenes!!!!
-
Gracias Mauricio, hasta ahora la imagen más grande que la librería libjpeg puede descomprimir es de 1600x1200 pixeles más o menos; después de eso, la librería manda mensaje de error y termina el programa :(
También la librería libsdcard tiene sus bugs, hay archivos que al pedir el descriptor de archivo, no los encuentra :x
Pero la parte de mi proyecto que es reducir las imágenes usando el formato y1cby2cr, ya funciona, que es lo importante.
Pienso agregarle música al programa para acompañar las fotos, pero ya será después porque ahora tengo otros proyectos de la escuela pendientes :mrgreen:
-
He estado algo ausente por razones laborales pero quería comentarte que sí , es común encontrar bugs en librerías hechas por otros .
En ocasiones no son bugs propiamente dichos sino que las librerías están mal documentadas y a veces requieren ciertos límites parámetros los cuales no están implícitos en la documentación y por ello surgen luego los errores
Ojalá puedas seguir haciendo cosas como esta porque realmente así se aprende muchisimo!
-
A ver si ahora que ya entre en vacaciones de la escuela me pongo a rediseñar esa librería jpeg para ver si ya no limita las imágenes. Espero entenderle porque ahora he aprendido mucho de lenguaje c.
El problema de la librería es que la persona que la migró, diseñó funciones que sacan los pixeles ya digeridos en formato ycbycr para gamecube y eso dificulta su uso para escalar imágenes.
A ver qué se me ocurre.
-
A ver si ahora que ya entre en vacaciones de la escuela me pongo a rediseñar esa librería jpeg para ver si ya no limita las imágenes. Espero entenderle porque ahora he aprendido mucho de lenguaje c.
El problema de la librería es que la persona que la migró, diseñó funciones que sacan los pixeles ya digeridos en formato ycbycr para gamecube y eso dificulta su uso para escalar imágenes.
A ver qué se me ocurre.
Sí, el tratamiento de imágenes es toda una ciencia en sí. Se han escrito libros enteros y lo último en esas cuestiones sigue siendo propiedad de algunas empresas líderes del sector.
De todas formas cuestiones como ampliar una imagen, estirarla y buscar cómo calcular los pixeles intermedios (usando algún degradé entre los colores del costado, etc) debe estar bastante documentado así que yo que tu empiezo por leer de esas cuestiones antes de meter una sola línea de código :mrgreen: