C - libpng unter Windows verwenden

[Max M. (maxmicr)]

Ich entwickle gerade ein kleines Grafikprogramm in C mit CLion unter 
Windows. Dieses soll später auf einen Controller portiert werden.
Da der Hauptaufwand allerdings die Software selber und nicht den 
Controller betrifft, wollte ich sie vorab auf dem PC schreiben um 
komfortabel debuggen zu können.

Zur Bildausgabe soll später ein LCD-Display dienen, jetzt soll das Bild 
aber erstmal in ein übliches Format wie z.B. png oder jpeg geschrieben 
werden. Dafür sammle ich in einem Buffer

const int buffer[W * H * 3 + 1]

alle Farbinformationen (RGB) für jeden Pixel. Nachdem das mit C 
anscheinend alles andere als trivial ist, bin ich durch googlen auf 
libpng gestoßen, dessen Sourcecode ich mir hier heruntergeladen habe: 
https://sourceforge.net/projects/libpng/files/libpng16/1.6.34/ 
(lpng1634.zip)

.zip-Datei entpackt und den Ordner in CLion als "Project Source" 
markiert. Da die Verwendung auch alles andere als trivial (für mich) 
ist, bin ich durch erneutes Googlen auf diesen Beispielcode gestoßen:

https://dev.w3.org/Amaya/libpng/example.c

Ich bin nur an der letzten Funktion write_png interessiert. Die hab 
ich mir in mein Projekt kopiert, allerdings werden selbst nach

#include "libpng/png.h"
#include "libpng/pnglibconf.h"

noch nicht alle Strukturen erkannt. Die pnglibconf hab ich im 
Unterordner scripts/pnglibconf.h.prebuilt entdeckt und hab sie prompt in 
*pnglibconf.h* umbenannt, damit sind einige Structs mehr erkannt worden.

Trotzdem kommt z.B. bei

png_set_IHDR(png_ptr, info_ptr, W, H, 8, PNG_COLOR_TYPE_RGB, PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);

die Fehlermeldung, dass W und H (sind Integer) nicht mit png_uint_32 
kompatibel wären, aber woher bekomme ich diesen typedef? Das selbe bei

FILE *fp = fopen(file_name, "wb");
png_init_io(png_ptr, fp);

hier ist png_FILE_p nicht mit FILE* kompatibel. Aber woher bekomme ich 
png_FILE_p?

Jetzt frag ich mich - woran liegt das? In dem Beispiel wurde nichts 
anderes außer eben *png.h* importiert. Es wird sich ja wohl in den 
letzten Monaten bzw. Jahren nicht so viel grundlegendes geändert haben, 
immerhin existiert diese Lib bereits seit über 20 Jahren.

Hat jemand Erfahrung mit libpng? Für jeden Tipp wäre ich dankbar.

Grüße

[Nop (Gast)]

Max M. schrieb:

> die Fehlermeldung, dass W und H (sind Integer) nicht mit png_uint_32
> kompatibel wären, aber woher bekomme ich diesen typedef?

Aus pngconf.h, Zeile 510?

#if UINT_MAX > 4294967294U
   typedef unsigned int png_uint_32;
#elif ULONG_MAX > 4294967294U
   typedef unsigned long int png_uint_32;
#else
#  error "libpng requires an unsigned 32-bit (or more) type"
#endif

> Aber woher bekomme ich png_FILE_p?

Aus pngconf.h, Zeile 595?

#ifdef PNG_STDIO_SUPPORTED
typedef FILE            * png_FILE_p;
#endif

Das erschließt sich einem übrigens, wenn man z.B. mit Notepad++ einfach 
mal alle *.h-Dateien nach den fraglichen Typen durchsucht. Linuxer 
bekämen das auch mit grep hin.

[Max M. (maxmicr)]

Danke dir, das hat schon sehr geholfen. Leider hab ich immer noch ein 
paar Fragezeichen offen.

1. Ich verstehe diesen Codeabschnitt nicht:

    png_uint_32 k, height, width;
    png_byte image[height][width];
    png_bytep row_pointers[height];
    for (k = 0; k < height; k++)
        row_pointers[k] = image + k*width;

Was genau soll bei der Addition eines 2D-Arrays mit einem Integer-Wert 
herauskommen? Noch dazu sagt mir CLion:

Incompatible pointer types png_bytep and png_byte[height][width]

2. Auch im nächsten Abschnitt verstehe ich nicht, wie ich hier meinen 
"Bildbuffer" unterbringe, wo schreibe ich konkret meine R, G und B 
Werte?

    /* write out the image data by one or more scanlines */
    /* The number of passes is either 1 for non-interlaced images,
     * or 7 for interlaced images.
     */
    for (pass = 0; pass < number_passes; pass++)
    {
        /* Write a few rows at a time. */
        png_write_rows(png_ptr, &row_pointers[first_row], number_of_rows);

        /* If you are only writing one row at a time, this works */
        for (y = 0; y < height; y++)
        {
            png_write_rows(png_ptr, &row_pointers[y], 1);
        }
    }

[Rufus Τ. F. (rufus)]

Max M. schrieb:
> Was genau soll bei der Addition eines 2D-Arrays mit einem Integer-Wert
> herauskommen?

Das ist elementares C.

row_pointers[k] = image + k*width;

In diesem Kontext ist "image" gleichbedeutend mit einem Pointer auf das 
erste Arrayelement.

Addiert man einen Integer zu diesem Pointer, bekommt man einen Pointer 
auf das dem Integerwert entsprechende Arrayelement, bei 4 also das 
fünfte Arrayelement.

[Nop (Gast)]

Max M. schrieb:

> Was genau soll bei der Addition eines 2D-Arrays mit einem Integer-Wert
> herauskommen?

Dazu müßtest Du Dich ein wenig mit Pointerarithmetik in C befassen, mit 
Arrays vs. Pointern und mit 2D-Arrays. Das ist durchaus tricky.

> 2. Auch im nächsten Abschnitt verstehe ich nicht, wie ich hier meinen
> "Bildbuffer" unterbringe

Dazu müßtest Du Dir die Beschreibung der API-Funktionen mal durchlesen. 
Das README-File ist da wohl der beste Einstieg.

[Max M. (maxmicr)]

Ich versteh den Sinn nicht, warum man bereits vorhandene Datentypen 
nochmal neu anlegt, nur um ein png im Namen zu haben?

Das zwingt mich doch dazu, mein gesamtes Programm auf die Datentypen von 
libpng umzuschreiben, und die Lib verwende ich später auf dem Controller 
nicht.

Gibt es vielleicht eine einfachere Möglichkeit, ein Bild auf dem PC mit 
C zu erzeugen? Ehrlich gesagt übersteigt die Bibliothek meine 
C-Fähigkeiten und es scheint mir, als wäre ein großes Maß an Verständnis 
für die Zusammenhänge bzw. über die generelle Struktur einer PNG-Datei 
notwendig.

Vor 7 Stunden dachte ich naiver Weise, dass das Thema in einer halben 
Stunde gegessen ist...

[Nop (Gast)]

Naja einfach ist das nicht. Da wirst Du Dir erstmal Tutorials durchlesen 
müssen, beispielsweise hier:

http://www.labbookpages.co.uk/software/imgProc/libPNG.html
http://zarb.org/~gc/html/libpng.html

Worüber ich mich wundere: wenn Du später auf einem Controller mit PNGs 
arbeiten willst, wie willst Du das eigentlich auf dem Controller 
erreichen, ohne libPNG dort auch zu haben? PNG ist mit den Optionen zur 
Komprimierung usw. nicht trivial.

[Nop (Gast)]

Max M. schrieb:

> Gibt es vielleicht eine einfachere Möglichkeit, ein Bild auf dem PC mit
> C zu erzeugen?

Ja, natürlich, indem Du nicht PNG als Format verwendest, sondern z.B. 
BMP. Das hat keine Komprimierung und ist daher viel simpler zu 
handhaben. Logischerweise sind die Bilddateien dann bei selbem 
Bildinhalt viel größer.

[Nop (Gast)]

Guck Dir mal das hier an:

http://ricardolovelace.com/creating-bitmap-images-with-c-on-windows.html

Das sieht recht simpel aus. Man sollte nur die Datentypen mal 
geradeziehen, also statt

unsigned int size_header;  // 4 bytes

lieber

uint32_t     size_header;  // 4 bytes

verwenden.

[Max M. (maxmicr)]

Nop schrieb:
> Worüber ich mich wundere: wenn Du später auf einem Controller mit PNGs
> arbeiten willst, wie willst Du das eigentlich auf dem Controller
> erreichen, ohne libPNG dort auch zu haben? PNG ist mit den Optionen zur
> Komprimierung usw. nicht trivial.

Wie ich im ersten Beitrag geschrieben habe, erfolgt die Ausgabe auf dem 
Controller über ein LCD Display.

Nop schrieb:
> Ja, natürlich, indem Du nicht PNG als Format verwendest, sondern z.B.
> BMP. Das hat keine Komprimierung und ist daher viel simpler zu
> handhaben. Logischerweise sind die Bilddateien dann bei selbem
> Bildinhalt viel größer.

Danke, das werde ich mir mal ansehen.

Nop schrieb:
> Guck Dir mal das hier an:

[Rufus Τ. F. (rufus)]

Nop schrieb:
> a, natürlich, indem Du nicht PNG als Format verwendest, sondern z.B.
> BMP.

BMP ist ein Containerformat und kann sowohl unkomprimierte als auch 
komprimierte Daten enthalten.

Einfacher zu handhaben ist GIF, da sind mittlerweile auch die letzten 
Patente ausgelaufen, und wenn man mit der 256-Farben-Beschränkung leben 
kann, ist das eine deutlich simplere Alternative zu PNG.

[Rolf M. (rmagnus)]

Max M. schrieb:
> Nop schrieb:
>> Worüber ich mich wundere: wenn Du später auf einem Controller mit PNGs
>> arbeiten willst, wie willst Du das eigentlich auf dem Controller
>> erreichen, ohne libPNG dort auch zu haben? PNG ist mit den Optionen zur
>> Komprimierung usw. nicht trivial.
>
> Wie ich im ersten Beitrag geschrieben habe, erfolgt die Ausgabe auf dem
> Controller über ein LCD Display.

Und das Display kann direkt mit PNG-Dateien umgehen? Die Frage war doch, 
wie du auf dem µC die PNG-Dateien handhaben willst, wo du vermutlich 
keine libpng zur Verfügung hast.

> Nop schrieb:
>> Ja, natürlich, indem Du nicht PNG als Format verwendest, sondern z.B.
>> BMP. Das hat keine Komprimierung und ist daher viel simpler zu
>> handhaben. Logischerweise sind die Bilddateien dann bei selbem
>> Bildinhalt viel größer.
>
> Danke, das werde ich mir mal ansehen.

Alternativ könnte noch XPM interessant sein. Das besteht schon aus 
C-Code, den man direkt in sein Programm einbinden kann.
https://de.wikipedia.org/wiki/X_PixMap

[Max M. (maxmicr)]

Rolf M. schrieb:
> Und das Display kann direkt mit PNG-Dateien umgehen? Die Frage war doch,
> wie du auf dem µC die PNG-Dateien handhaben willst, wo du vermutlich
> keine libpng zur Verfügung hast.

Ganz einfach, ich habe keine PNG-Dateien auf dem µC. Das ist ein 
SPI-Display, also schreibe ich die Pixeldaten über den SPI Bus in den 
Puffer des Displays. Da war ich wohl etwas ungenau in der Beschreibung.

Das hier funktioniert nun:

#include <stdio.h>
#include <mem.h>
#include "image.h"

void save_bitmap(const char *file_name, const unsigned int width, const unsigned int height, const unsigned int dpi, const int *buffer,
                 int samples) {
// create a file object that we will use to write our image
    FILE *image;
// we want to know how many pixels to reserve
    unsigned int image_size = width * height;
// a byte is 4 bits but we are creating a 24 bit image so we can represent a pixel with 3
// our final file size of our image is the width * height * 4 + size of bitmap header
    unsigned int file_size = 54 + 4 * image_size;
// pixels per meter https://www.wikiwand.com/en/Dots_per_inch
    unsigned int ppm = (unsigned int)(dpi * 39.375);

    struct bitmap_file_header {
        unsigned char   bitmap_type[2];     // 2 bytes
        int             file_size;          // 4 bytes
        short           reserved1;          // 2 bytes
        short           reserved2;          // 2 bytes
        unsigned int    offset_bits;        // 4 bytes
    } bfh;

// bitmap image header (40 bytes)
    struct bitmap_image_header {
        unsigned int    size_header;        // 4 bytes
        unsigned int    width;              // 4 bytes
        unsigned int    height;             // 4 bytes
        short int       planes;             // 2 bytes
        short int       bit_count;          // 2 bytes
        unsigned int    compression;        // 4 bytes
        unsigned int    image_size;         // 4 bytes
        unsigned int    ppm_x;              // 4 bytes
        unsigned int    ppm_y;              // 4 bytes
        unsigned int    clr_used;           // 4 bytes
        unsigned int    clr_important;      // 4 bytes
    } bih;

// if you are on Windows you can include <windows.h>
// and make use of the BITMAPFILEHEADER and BITMAPINFOHEADER structs

    memcpy(&bfh.bitmap_type, "BM", 2);
    bfh.file_size       = file_size;
    bfh.reserved1       = 0;
    bfh.reserved2       = 0;
    bfh.offset_bits     = 0;

    bih.size_header     = sizeof(bih);
    bih.width           = width;
    bih.height          = height;
    bih.planes          = 1;
    bih.bit_count       = 24;
    bih.compression     = 0;
    bih.image_size      = file_size;
    bih.ppm_x           = ppm;
    bih.ppm_y           = ppm;
    bih.clr_used        = 0;
    bih.clr_important   = 0;

    image = fopen(file_name, "wb");

// compiler woes so we will just use the constant 14 we know we have
    fwrite(&bfh, 1, 14, image);
    fwrite(&bih, 1, sizeof(bih), image);

// write out pixel data, one last important this to know is the ordering is backwards
// we have to go BGR as opposed to RGB
    int i = 0;
    for(unsigned y = 0; y < height; y++)
        for(unsigned x = 0; x < width; x++) {
            char r = (char)(buffer[i * 3 + 0] / samples);
            char g = (char)(buffer[i * 3 + 1] / samples);
            char b = (char)(buffer[i * 3 + 2] / samples);

            char color[] = {b,g,r};

            fwrite(color, 1, sizeof(color), image);
            i++;
        }

    fclose(image);
}

[Rolf M. (rmagnus)]

Max M. schrieb:
> Rolf M. schrieb:
>> Und das Display kann direkt mit PNG-Dateien umgehen? Die Frage war doch,
>> wie du auf dem µC die PNG-Dateien handhaben willst, wo du vermutlich
>> keine libpng zur Verfügung hast.
>
> Ganz einfach, ich habe keine PNG-Dateien auf dem µC. Das ist ein
> SPI-Display, also schreibe ich die Pixeldaten über den SPI Bus in den
> Puffer des Displays. Da war ich wohl etwas ungenau in der Beschreibung.

Das geht aber immer noch an der Frage vorbei, denn wo kommen die 
Pixeldaten denn her?

Max M. schrieb:
> struct bitmap_file_header {
>         unsigned char   bitmap_type[2];     // 2 bytes
>         int             file_size;          // 4 bytes
>         short           reserved1;          // 2 bytes
>         short           reserved2;          // 2 bytes
>         unsigned int    offset_bits;        // 4 bytes
>     } bfh;

Ich würde hier die Standard-Typedef aus stdint.h empfehlen. Außerdem 
kann es zu Alignment-Problemen kommen, da offset_bits nicht an einer 
4-Byte-Grenze ausgerichtet ist. Dazu kommt dann noch ggf. das Thema 
Endianness.

[Nop (Gast)]

Rufus Τ. F. schrieb:

> BMP ist ein Containerformat und kann sowohl unkomprimierte als auch
> komprimierte Daten enthalten.

Im simpelsten Fall hat man unkomprimierte Daten mit je 8 bit R, G und B 
pro Pixel. Das dürfte einfacher sein, als sich mit Paletten und 
Paletenindizes herumzuschlagen.

Besonders, wo der OP später mit einem Display wohl auch einfach nur 
Bildbufferdaten übertragen wird, da ist unkomprimiertes BMP schon sehr 
nahe dran. Es ging schließlich für den PC jetzt nur darum, möglichst 
einfach einen Buffer in C manipulieren zu können und den als Bild 
wegzuschreiben.


Rolf M. schrieb:
> Ich würde hier die Standard-Typedef aus stdint.h empfehlen.

Ja, das hatte ich auch schon angemerkt, als ich das Codebeispiel 
berlinkt hatte.

> Außerdem kann es zu Alignment-Problemen kommen, da offset_bits nicht
> an einer 4-Byte-Grenze ausgerichtet ist.

Guter Punkt. Zumindest sollte das struct auf dem PC besser "packed" 
sein, sonst wird da u.U. Unsinn weggeschrieben auch bei der Dateigröße.

> Dazu kommt dann noch ggf. das Thema Endianness.

Auf dem PC sollte das kein Problem sein, und das wird ja als Dateiformat 
offenbar auch nur auf dem PC gebraucht.

[Max M. (maxmicr)]

Nop schrieb:
> sonst wird da u.U. Unsinn weggeschrieben

Ich hab das Beispiel ausprobiert: 
https://stackoverflow.com/questions/2654480/writing-bmp-image-in-pure-c-c-without-other-libraries 
und bei mir sieht es genauso aus, heißt das nun, dass alles 
funktioniert?

Nop schrieb:
> Es ging schließlich für den PC jetzt nur darum

Exakt.

Rolf M. schrieb:
> Das geht aber immer noch an der Frage vorbei, denn wo kommen die
> Pixeldaten denn her?

Die erzeugt das Programm.

[Rolf M. (rmagnus)]

Max M. schrieb:
> olf M. schrieb:
>> Das geht aber immer noch an der Frage vorbei, denn wo kommen die
>> Pixeldaten denn her?
>
> Die erzeugt das Programm.

Ja und dann!?
Das erinnert mich irgendwie an die Formel zum Profit von den "underpants 
gnomes" aus South Park:

1. Unterhosen einsammeln
2. ?
3. Profit

Also, wir haben:

1. Ein PC-Programm erzeugt eine Bilddatei
2. ?
3. Die Pixel der Bilddatei gehen per SPI ans Display

Also die Frage nochmal anders gestellt: Wie kommt die Datei zum µC, so 
dass er sie per SPI senden kann?

[Max M. (maxmicr)]

Rolf M. schrieb:
> Wie kommt die Datei zum µC, so
> dass er sie per SPI senden kann?

Die Pixeldaten werden im Controller erzeugt und auf einem Display, dass 
per SPI angesteuert wird, angezeigt. Es gibt keine Datei im µC, die 
Datei will ich lediglich auf dem PC haben, um zu testen, ob mein 
Programm korrekt funktioniert.
PC-Programm und Controller sind in keiner Weise verbunden oder gehören 
zusammen. Am PC teste ich die Software und später läuft sie auf dem 
Controller (deswegen tue ich mir C auf dem PC auch an).

[Rolf M. (rmagnus)]

Max M. schrieb:
> Rolf M. schrieb:
>> Wie kommt die Datei zum µC, so
>> dass er sie per SPI senden kann?
>
> Die Pixeldaten werden im Controller erzeugt und auf einem Display, dass
> per SPI angesteuert wird, angezeigt. Es gibt keine Datei im µC, die
> Datei will ich lediglich auf dem PC haben, um zu testen, ob mein
> Programm korrekt funktioniert.

Ach so. Ok, ich dachte, das PC-Programm soll die Datei erzeugen, und der 
µC soll sie dann ans Display schicken.

> PC-Programm und Controller sind in keiner Weise verbunden oder gehören
> zusammen. Am PC teste ich die Software und später läuft sie auf dem
> Controller (deswegen tue ich mir C auf dem PC auch an).

Ah, jetzt verstehe ich. Dann dürfte ein RGB-BMP tatsächlich das 
einfachste für dich sein.

[Nop (Gast)]

Max M. schrieb:

> Ich hab das Beispiel ausprobiert:
> https://stackoverflow.com/questions/2654480/writin...
> und bei mir sieht es genauso aus, heißt das nun, dass alles
> funktioniert?

Wenn Du eines der Beispiele gewählt hast, wo diese Header vom Typ 
unsigned char sind, und wo z.B. Filesize dann geshiftet und stückweise 
reingepackt wird, dann sollte das gut sein.

Ein wichtiger Tip war da noch, daß die Zeilenlänge in Bytes durch vier 
teilbar sein muß. Das ist in den Antworten, wo mit der Variable 
"extrabytes" gearbeitet wird, aber auch schon bedacht.

[Rufus Τ. F. (rufus)]

Max M. schrieb:
> Die Pixeldaten werden im Controller erzeugt und auf einem Display, dass
> per SPI angesteuert wird, angezeigt.

(das, nicht "dass")

Warum aber müssen die Pixeldaten dann im PNG-Format vorliegen? Das musst 
Du ja erst mal mit libpng erzeugen ... und dann gleich wieder 
decodieren, um es ans Display senden zu können.

[Nop (Gast)]

Rufus Τ. F. schrieb:

> Warum aber müssen die Pixeldaten dann im PNG-Format vorliegen?

Gar nicht. Der OP wollte einfach nur auf dem PC einen Bildbuffer im RAM 
haben, den mit ein paar C-Routinen manipulieren (was er auch auf dem 
Controller dann tun wird) und auf dem PC in irgendeinem Bildformat 
ausgeben, mit dem er sich das Ergebnis der Buffer-Manipulationen auf dem 
PC schonmal angucken kann.

PNG nur deswegen, weil es einfach ein verbreitetes Format ist und dem OP 
daher als Möglichkeit eingefallen ist, und weil es libpng zum 
Wegschreiben gibt - nur daß das dann wesentlich komplizierter war als 
gedacht.

[Max M. (maxmicr)]

Danke Nop, anscheinend hast du das als Einziger verstanden :)

Ich dachte, ich hätte es verständlich erklärt.

[Rolf M. (rmagnus)]

Max M. schrieb:
> Danke Nop, anscheinend hast du das als Einziger verstanden :)

Einspruch: Ich hab's inzwischen auch verstanden. ;-)