Inoffizielle Standardklassen/Pseudostandards



  • Ja, richtig. Ein int-Array ist der gemeinsame Nenner eine jeden Bildklasse, aber auch da gibt es schon wieder mehrere Möglichkeiten das repräsentieren. Nehme ich ein eindimensionales Array und speicher zusätzlich Höhe oder Breite ab? Oder gleich ein zweidimensionales? Vielleicht kann das Array sogar größer als Bild sein, damit ich nach beschneiden kein neues Array erzeugen muß (wird zum Beispiel in Java so gemacht). Deswegen ja auch die Frage, ob es sowas wie Standards gibt, dann wäre das genau definiert.

    Warum libs nutzen? Weils produktiv ist! Ich sehe keinen Grund etwas was es schon gibt und lizenzrechtlich in Frage kommt nicht zu nutzen. Darin enthaltene Bugs sind nicht mein Problem, bzw. bei freien Bibliotheken nicht ausschließlich mein Problem. Ich spare Entwicklungskosten, evtl Speicherplatz beim Anwender (zumindest unter Linux wo externe Bibliotheken systemweit sind). Ich finde es äußerst vorteilhaft. Ein Jpeg kriegt man durchaus noch in angemessener Zeit decodiert, aber will man das? Was ist, wenn ich plötzlich ein Video abspielen will? Einen hochkomprimierten Videostream zu decodieren ist nicht gerade ne Aufgabe die man mal eben in der Mittagspause implementiert.



  • Ein zweidimensionales Array bringt dir nur Nachteile.
    Selbstverständlich kann das Array auch größer sein als für das aktuelle Bild notwendig wäre.



  • Toddy69 schrieb:

    Ein int-Array ist der gemeinsame Nenner eine jeden Bildklasse

    Äh, nö. Eher nen unsigned char (0 to 256).

    Toddy69 schrieb:

    ehme ich ein eindimensionales Array und speicher zusätzlich Höhe oder Breite ab? Oder gleich ein zweidimensionales?

    o0
    Im Prinzip tut's schon diese Struktur, um zwischen den verschiedenen (gekapselten!) Klassen zu kommunizieren: (Vorsicht, ungetestet!)

    struct ImageData
    {
    	ImageData(const unsigned int Width,
    		      const unsigned int Height,
    			  const unsigned char BPP,
    			  const std::vector<unsigned char> PixelBuffer) :
    		ImageWidth(Width),
    		ImageHeight(Height),
    		ImageBPP(BPP),
    		ImagePixelBuffer(PixelBuffer) { }
    
    	const unsigned int ImageWidth;
    	const unsigned int ImageHeight;
    	const unsigned char ImageBPP;
    	std::vector<unsigned char> ImagePixelBuffer;
    };
    

    Toddy69 schrieb:

    Warum libs nutzen?

    Um Erfahrung zu sammeln und damit du solche Fragen nicht mehr stellen musst.



  • Kóyaánasqatsi schrieb:

    Im Prinzip tut's schon diese Struktur, um zwischen den verschiedenen (gekapselten!) Klassen zu kommunizieren

    Genau sowas hab ich auch geschrieben, außer dass ich einen Array aus sizeof(int) Color structs hatte und es nicht nur für Bilder nutze.

    Ich finde die Idee von standardisierten Klassen oder Interfaces gar nicht schlecht, ich glaube nur dass wir noch nicht soweit sind. Bestimmte Lösungen und auch Implementationen müssen wohl x mal programmiert werden bis sich eine gewisse Struktur herauskristallisiert, auf die man sich einigen kann.



  • Ich verstehe die Diskussion nicht...
    Z.B. bietet Qt in seinem Image-Klassen (QImage, QPixmap,...) die Möglichkeit, direkt auf das array zuzugreifen, um es zu bearbeiten. QImage ist für solche Bearbeitungen optimiert.
    Es gibt für die Standard-Bildformate die einem so über den Weg laufen, qimage-plugins, die Laden und Speichern Implementieren.
    Du musst also gar nichts mehr machen!

    Ich bin mir sicher dass das bei wxWidgets ähnlich ist.



  • Toddy69! Schau dir mal die Bibliothek-Sammlung http://stlab.adobe.com/ von Adobe an. Die haben darunter eine speziell für Bildbearbeitung, die sich Generic Image Library nennt. Diese ist mittlerweile in der Boost Sammlung enthalten:
    http://www.boost.org/doc/libs/1_41_0/libs/gil/doc/index.html

    Was sie allerdings nicht kann, ist Bilder anzeigen. Dafür brauchst du schon eine GUI Bibliothek.



  • unsigned char wohl kaum. RGB und Alpha mit jeweils 8 Bit machen 32 Bit also insigned int. Aber darum gehts nicht. Ich bin durchaus in der Lage eine Klasse zu entwerfen die Bilder implementiert. Genau das ist ja das Problem, diese Klassenvielfalt die im Grunde alle dem selben Zweck dienen sind den Bibliotheken nicht bekannt. Deine Klasse wäre eben zu diesem Zweck geeignet, nur wird sie eine Bibliothek natürlich nicht kennen.

    Gegenbeispiel wäre der String. Wenn ich irgendwo einen String übergeben kann, werde ich in der Regel einen std::string übergeben können (oder char-Array natürlich), und nicht ein StringImplementierungDieTausendste-Objekt. Das ist eine Implementierung die idR jeder benutzt und die problemlos von verschiedenen Komponenten benutzt werden kann.



  • Toddy69 schrieb:

    unsigned char wohl kaum. RGB und Alpha mit jeweils 8 Bit machen 32 Bit also insigned int.

    Moooooment:

    const unsigned char RGBA[4][0xff] = { 0xff, 0xff, 0xff, 1 };
    //					                 R     G     B    A
    


  • Das macht Farbvergleiche -- welche sicher häufiger als Komponentenvegleiche sind -- aber sehr unpraktisch. Trotzdem: Es geht mir nicht um Bilder! Es geht mir um das Konzept von standardisierten Klassen.

    @Artchi: Die Generic Image Library scheint in der Tat ein Kandidat für diesen Zweck zu sein, zumal sie mit Boost gut verfügbar sind. Aber werden sie auch wirklich überall genutzt? Eher nicht, also zumindest noch kein Standard. Und das wären bis jetzt auch erst Bilder, andere häufige Typen wären damit auch noch nicht erschlagen.

    Sieht also eher so aus, als gibt es das in der Form tatsächlich nicht, und einzig Collections und strings folgen einem Standard.



  • @Kóyaánasqatsi:

    bis auf PNG und JPEG ist eigentlich jeweils jeder Parser in ein paar Stunden geproggt

    Das zeigt wieder mal deutlich dass du keine Ahnung hast. Einen BMP-Reader der ausschliesslich 24 Bit Bilder laden kann hat man in ein paar Stunden, ja. Alle anderen interessanten Formate (GIF, TIFF, TGA, Photoshop etc.) sind aufwendiger. Wesentlich aufwendiger.

    @Toddy69:
    Nimm doch einfach eine fertige Library, die alle benötigten Bildformate lesen und schreiben kann. Kandidaten wären die DevIL bzw. die FreeImage.
    Falls die Library von Adobe auch viele Formate lesen/schreiben kann, wäre die natürlich auch geeignet.

    @Artchi:
    Weisst du welche Formate die Adobe Library lesen/schreiben kann?



  • Toddy69 schrieb:

    @Artchi: Die Generic Image Library scheint in der Tat ein Kandidat für diesen Zweck zu sein, zumal sie mit Boost gut verfügbar sind. Aber werden sie auch wirklich überall genutzt? Eher nicht, also zumindest noch kein Standard.

    Die Generic Image Library ist im Moment ganz weit weg davon "Standard" zu sein.

    Der Quasi-Standard ist im Moment (leiter!) die DevIL.
    Irgendwie verwendet sogut wie jedes Projekt, welches nicht libpgn/libjpeg direkt verwendet, die DevIL. Obwohl sie was das Interface angeht eine Katastrophe ist.



  • Warum sollte TGA aufwendiger sein? Mit den anderen Formaten habe ich mich noch nicht befasst.


Anmelden zum Antworten