Daten in QVector rotieren

[QTNeuer]

Hallo zusammen,

es wäre nett wenn mir einer bei folgendem Problem helfen könnte.

Ich habe einen QVector<short>
Jeder Eintrag repräsentiert einen Bildpunkt in einem Image.
Später wird der QVector<short> in ein uchar geschrieben und das Bild dann über QImage object und QPixmap dargestellt.

Wenn ich die Daten so wie sie sind direkt als image darstelle, dann ist das Bild um 180 Grad gedreht.
Man kann zwar das QImage object relativ einfach drehen, aber das löst mein Problem nicht da ich die Daten auch noch abspeichern möchte
nach dem sie edreht wurden. Und QImage unterstützt nur 8 Bit ich möchte sie aber orginal abspeichern (14 Bit)

Im Moment Löse ich das Problem relativ umständlich mit mehreren Schleifen. Das ist aber leider sehr langsam und dauert lange.

Kennt jemand eine schnelle Lösung wie ich die Daten direkt im QVector so umsortieren kann, dass das spätere Bild um 180 Grad gedreht ist.
Gibt es schon Bibliotheken die das machen?

QT selbst kennt nur Matrix3x3 bzw Matrix4x4. Ich bräuchte aber so etwas wie MatrixNxN

Bin über jeden Tipp dankbar!

[RHBaum]

Im Moment Löse ich das Problem relativ umständlich mit mehreren Schleifen.

Um ne schleife kommst wahrscheinlich nicht drumherum, aber warum man mehrere schleifen braucht ... kommt mir grad gar ned in den Sinn.
Vielleicht ist grade auch das dein Problem ...

1. Ansatz waere, neuen Vector mit voller groesse erstellen und mit einer Schleife rueber-transformieren. Zeit messen .....

2. Optimierung waere, die sache umschreiben das es statt den 2.ten Vector nur nen kleineren buffer braucht, die werte dann aber in den ursprungsvector direkt zurueckschreibt (ohne das daten verlorengehen, das ist die kunst ^^)
würde länger brauchen, aber weniger (haupt)speicher erfordern ...

Und QImage unterstützt nur 8 Bit ich möchte sie aber orginal abspeichern (14 Bit)

14 Bit ? wasn das fuern Format ? ^^
aber QImage kann mehr, laut Doku:

int QImage::depth () const
Returns the depth of the image.
The image depth is the number of bits used to store a single pixel, also called bits per pixel (bpp).
The supported depths are 1, 8, 16, 24 and 32.

beachte:

uchar * QImage::bits ()
const uchar * QImage::bits () const

Returns a pointer to the first pixel data.

gibt nur den Zeiger auf das erste Byte vom Pixel, es koennen mehr sein !

um an die farbinfo des Bildes naiver/einfacher zu kommen, helfen vielleicht:

QRgb QImage::pixel ( const QPoint & position ) const
QRgb QImage::pixel ( int x, int y ) const

Sehe somit keinen Grund, nicht QImage und Transformation zu verwenden ....

Ciao ....

[Christian81]

@RHBaum: 14Bit pro Farbwert kann QImage nicht.

[saar]

Der schnellste Weg ist m.E., einen Hilfsvektor anzulegen und die Rotation dorthinein abzuspeichern (wie von RHBaum schon vorgeschlagen). Falls das aufgrund von Speicheranforderungen nicht möglich sein sollte, muss die ganze Sache in-place gelöst werden.

Die Drehung des Bildes kann als eine Permutation des Vektors aufgefasst werden. Da um 180° gedreht werden soll, ist diese Permutation zu sich selbst invers (2* drehen gibt wieder das Original). Im Paper "Permuting In Place" http://www.cs.toronto.edu/~faith/permuting.ps werden mehrere Algorithmen für diese Aufgabe beschrieben. Wenn man die Permutation und ihre Inverse kennt, kann man einen recht einfachen Algorithmus verwenden (siehe Figure 4 im Paper). Laufzeit des Algorithmus ist O(n*log(n)). Zusätzlicher Speicher wird nicht benötigt (vorausgesetzt man kennt die Permutation und ihre Inverse).

Achtung: Die Hilfsfunktion Rotate() in Figure 3 enthält einen kleinen Fehler. Hier ist eine korrigierte Version (perm() ist eine Funktion, die die Permutation definiert, A der Vektor, auf den die Permuation anzuwenden ist. Alle sonstigen Variable sind Indizes.):

Code: Alles auswählen

procedure Rotate(leader)
i := perm(leader)
j:= leader
while i != leader do
    interchange the values in A[j] and A[i]
    j:= i
    i:= perm(i)
od

Vielleicht hilft's weiter.

[RHBaum]

@RHBaum: 14Bit pro Farbwert kann QImage nicht.

14 bpp ist auch kein handelsuebliches format oder ?
wenn ers anzeigen will wird ers konvetieren muessen ....

Da ich nicht denke, das das format von ner alten DEC 7 bit Maschine kommt (2x7 = 14bit, hatten die ueberhaupt schon grafik-ausgabe ??? ) vermut ich, das die Pixel schon an bytes ausgerichtet sind.
also wird das nen uebliches 16 bit Format sein, wo nur 2 bits nicht verwendet werden ^^
wahrscheinlich braucht ers nichtmal konvertieren sondern kanns 1:1 als 16 bit bitmap anzeigen lassen, der unterscheid wuerd wahrscheinlich ned mal auffallen
Wahrscheinlich bekommt ers sogar 16 bit kodiert, nur eben mit nur 14bit farbtiefe ...

ich möchte sie aber orginal abspeichern (14 Bit)

Ich kenn kein format, was 14 bit pixel alignment hat ...

Ich vermute das die pixelinformationen aus keinem vorhanden dateiformat kommen, sondern von irgend einem Wandler-Messaufnehmer ...
exotische Kamera, irgend sowas ^^ kommen

Dann wird er sie sowieso notfalls "konvertieren" muessen damit sie anzeigbar und als normales bild speicherbar werden ...
Also wird er sowas wie nen 14 bit monochrom Format
oder nen RGB444 oder RGB565 nehmen ... oder wenn ihm der speicherplatz egal ist, kann er auch nen natives 32bit Bitmap draus machen, muss nur geschickt hochkonvertieren ...

Das kann aber nur der Threadersteller wissen / entscheiden ...

Ciao ...