MAGIC_SWAP und andere Geheimnisse im Image-Header



  • Ich versuche, das Problem zu zeigen, ohne seitenweise Code präsentieren. Also: Um Texturen u.a. Dinge zu laden, habe ich provisorisch einen Code von www.koders.com eingesetzt. Der funktioniert ganz gut, aber nur mit RGB-Grafiken. Nun bin ich dabei, das Ganze für PNG-Grafiken umzuändern (mit SDL_image). Dabei gibt es noch einige Fragen.

    Zunächst die relevanten Teile des Originalcodes. Das Ganze spielt sich in der folgenden Struktur ab:

    typedef struct  
    {
        unsigned short imagic;
        unsigned short type;
        unsigned short dim;
        unsigned short sizeX, sizeY, sizeZ;
        unsigned long min, max;
        unsigned long wasteBytes;
        char name[80];
        unsigned long colorMap;
        FILE *file;
        unsigned char *tmp[5];
        unsigned long rleEnd;
        unsigned int *rowStart;
        unsigned int *rowSize;
    } image_t;
    t_image image;
    

    Mich interessieren nun die ersten 3 Parameter, deren Bedeutung ich beim besten Willen nicht aus dem Code herauslesen kann (die anderen Parameter sind klar oder für meine Zwecke unwichtig).

    #define IMAGIC      0x01da
    #define IMAGIC_SWAP 0xda01
    
    #define SWAP_SHORT_BYTES(x) ((((x) & 0xff) << 8) | (((x) & 0xff00) >> 8))
    
    fread (image, 1, 12, image->file);
    
    if (image->imagic == IMAGIC_SWAP) 
    {
        image->type  = SWAP_SHORT_BYTES(image->type);
        image->dim   = SWAP_SHORT_BYTES(image->dim);
        image->sizeX = SWAP_SHORT_BYTES(image->sizeX);
        image->sizeY = SWAP_SHORT_BYTES(image->sizeY);
        image->sizeZ = SWAP_SHORT_BYTES(image->sizeZ);
    ...
    

    Es geht also weniger darum, wie die Parameter zurechtgebastelt werden (versteh' ich sowieso nur halb), sondern was in ihnen drinsteckt. Was heißt "imagic", was ist unter "type" und "dim" zu verstehen? Muss ich auch bei PNG-Grafiken versuchen, an diese Daten heranzukommen?

    Reinhard


  • Mod

    1. wohl ein endian check
    2. der typ des bildes wahrscheinlich, eventuell rgba, palettiert, rgb oder 16bit oder..
    3. vermutlich die aufloesung.



  • imagic: da muss 0x01da drin stehen. wenn 0xda01 gelesen wurde werden die bytes von allen shorts vertauscht, damit das ganze mit little endian und big endian funktioniert. ist etwas eigenwillig, aber ok.

    type: keine Ahnung. Was steht denn drinnen (Wert)?

    dim: wahrscheinlich die Anzahl der Dimensionen des "Bildes", also 1-3 (gibt ja nur sizeX, sizeY und sizeZ in der Struktur - daher macht > 3 wohl keinen Sinn, und ich hätte z.B. auch noch nie von 4D Texturen gehört). Für Texturen verwendet man ja auch oft mal 1 oder 3 Dimensionale "Bilder".



  • imagic: Da ich nur noch mit einem einheitlichen Format (PNG) arbeiten will, dürfte die Abfrage wohl keine Rolle spielen, denn ich kann mich ja fest auf den "endian" einstellen, oder?

    type: liefert bei einer RGB-Textur den Wert 257.

    dim: da kommt 3 heraus.

    Ich denke nun aber, dass ich diese Parameter gar nicht gebrauche, wenn ich das Lesen der PNG-Grafiken SDL-image überlasse. SizeX und sizeY lassen sich aus surface->w /h ablesen, und surface->format->BytesPerPixel liefert sizeZ. Vermutlich ist die Library so angelegt, dass sie mit verschiedenen Formaten, also nicht nur RGB, zurechtkommt.

    Das ist immer so'ne Sache mit Fremdcode. Was da abläuft, kann man mit etwas Mühe entziffern, aber wozu dieses oder jenes gemacht wird, müsste eigentlich präzise kommentiert werden.

    Danke


  • Mod

    erin schrieb:

    imagic: Da ich nur noch mit einem einheitlichen Format (PNG) arbeiten will, dürfte die Abfrage wohl keine Rolle spielen, denn ich kann mich ja fest auf den "endian" einstellen, oder?

    nein, du hast beim endian nichts zu bestimmen ➡ informier dich was endian ueberhaupt ist wenn du davon abhaengst.

    Das ist immer so'ne Sache mit Fremdcode. Was da abläuft, kann man mit etwas Mühe entziffern, aber wozu dieses oder jenes gemacht wird, müsste eigentlich präzise kommentiert werden.

    mueste eigentlich praezise in der formatdoku stehen.


Log in to reply