Inoffizielle Standardklassen/Pseudostandards

Athar

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.

Kóyaánasqatsi

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.

Kontrasubjekt

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.

l'abra d'or

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.

Artchi

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.

Toddy69

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.

Kóyaánasqatsi

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

Toddy69

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.

hustbaer

@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?

hustbaer

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.

Kóyaánasqatsi

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