Jpg Bilder einlesen und skalieren

volkard

Enno schrieb:

Was ich mich grade frage ob es schlau ist das über die Lauflänge zu machen oder so wie ihr mir das jetzt grade gezeigt habt?
Bei der Lauflänge hätte ich ja nicht alle gesamt aber könnte trotzdem ja ein Huffman Baum mit Knoten draus bauen. Weiß nicht, was haltet ihr für besser?

RLE bringt nur was, wenn Du lange Zeilen lang unveränderte Werte hast. Wie bei Screenshots wenn keine Farbverläufe oder Bilder beteiligt sind. Aber wenn RLE mal paßt, dann komprimiert es gewaltig stark.

Huffman bring nur was, wenn Du nicht gleichverteilte Daten hast (also fast immer). Aber Huffman komprimiert nie gewaltig stark.

Deswegen kombiniert man gerne beide. Erst RLE, dann Huffman.

Skym0sh0

Jain, RLE komprimiert mit zunehmender Länge besser.
Also am wenn der zu komprimierende Wert nur 1 lang ist dann erhöht sich der Speicher sogar noch. Aber je länger die sich wiederholende Buchstabenkette wird, desto effizienter ist es.

volkard

nichtkenner der chars schrieb:

ich weiss nicht, wie groß ein char ist. aber dank c++ gibt es dafür den sizeof operator, der es mir sagt, ohne dass ich detailwissen aus dem standard oder der implementierung benötige

Skym0sh0 sollte es aber inzwischen drin haben.

Enno

Skym0sh0 schrieb:

Jain, RLE komprimiert mit zunehmender Länge besser.
Also am wenn der zu komprimierende Wert nur 1 lang ist dann erhöht sich der Speicher sogar noch. Aber je länger die sich wiederholende Buchstabenkette wird, desto effizienter ist es.

Na gut das mag sein aber bei mir ist nun mal klar das es nicht nur eine Länge von 1 hat. Also denke ich das RLE schon angebracht ist.
Edit:
Oder meintest du bei sowas:
12211222211
Die erste 1 steht ja alleine udn hätte nur eine länge von 1?

Skym0sh0

1

Quelle:

5.3.3.1 schrieb:

sizeof(char), sizeof(signed char) and
sizeof(unsigned char) are 1.

Wieso sollte ich mittlerweile? oO

volkard

Enno schrieb:

Oder meintest du bei sowas:
12211222211
Die erste 1 steht ja alleine udn hätte nur eine länge von 1?

Noch ein Grund, RLE und Huffman nacheinanderzuschalten. Man hat kostenlose Escape-Zeichen.

12211222211
wäre in ASCII
49 50 50 49 49 50 50 50 50 49 49
und nach RLE vielleicht (256 als Zeichen; Jetzt kommt ein Byte=Anzahl und dann ein Byte für das sich wiederholende Zeichen)
49 50 50 49 49 256 4 50 49 49
und Huffman hat dann keinerlei Schmerzen, einen 257 großen Zeichenvorrat zu schreiben.

volkard

Skym0sh0 schrieb:

1

Quelle:

5.3.3.1 schrieb:

sizeof(char), sizeof(signed char) and
sizeof(unsigned char) are 1.

Wieso sollte ich mittlerweile? oO

Weil Du mittlerweile ein Alter Hase in C++ bist und so ein Rauschen wie sizeof(char) nicht mehr in den Code stecken musst.

Swordfish

...

Skym0sh0

Ich und Alter Hase???
Herr Henkel, ich bin um den Divisor 2 bis 3 mal jünger als Sie, ich habe nicht annähernd die Erfahrung wie die Großen hier im Forum, selbst die tiefergehenden Sprachkonzepte durchblicke oder kann ich nicht. Die meisten Features aus dem neuen Standard verstehe ich nichtmals. TMP ist ein Fremdwort für mich (und für meinen Compiler auch ;D)

Und ich bin eine alter Hase?

Swordfish

...

volkard

Bei einem Problem machst Du Klickediklack, und schaust im Standard nach. Ist das nix?

Skym0sh0

Ja, ok, groß bin ich, das stimmt. Aber das hat nix mit meinen Programmierkenntnissen zu tun.

Enno

Müsst ihr das hier diskutieren?

Skym0sh0

Nein, müssen wir nicht. Aber es bietet sich halt an

Enno

Ich komm irgendwie nicht weiter, wie ich die "Frequenzen" oder "Wahrscheinlichkeiten" von den einzelnen Chars bekomme.
D.h. bei einer Eingabe von:

04 a3 23 3a 4d 31 49 4d 47 0d 0a 45 45 43 54 49

Was jetzt nur ein kurzer Teil ist. Ich hab mir da jetzt extrem viele Beispiele angeschaut im netz aber die verwirren meist nur. Vielleicht kann mir hier ja noch mal jemand einen Tipp geben wie ich sowas anstellen könnte.

Ethon

So einfach wie möglich:

std::vector<std::uint8_t> bytes = readJpegBytes(); // Das darfst du implementieren!

std::array<std::size_t, std::numeric_limits<std::uint8_t>::max()> counter;
for(std::uint8_t cur : bytes)
    ++counter[cur];

for(std::size_t i = 0; i < counter.size(); ++i)
    std::cout << std::hex << i << "\tkommt " << counter[i] << "x vor\n";

Ethon schrieb:

std::vector<std::uint8_t> bytes = readJpegBytes(); // Das darfst du implementieren!

std::array<std::size_t, std::numeric_limits<std::uint8_t>::max()> counter;
for(std::uint8_t cur : bytes)
    ++counter[cur];

for(std::size_t i = 0; i < counter.size(); ++i)
    std::cout << std::hex << i << "\tkommt " << counter[i] << "x vor\n";

Leider nicht korrekt.

Ethon

Was?

Furble Wurble schrieb:

Leider nicht korrekt.

Da wird der Standardbibliothek eine an sich überflüssige Klasse spendiert und das Commitee hat es nicht fertig gebracht, sie so zu designen, dass sie der Durchschnittsnutzer korrekt verwendet.

Immerhin (und das ist ungemein wichtiger) scheint die Richtlinie, die Uniform Initialization unter allen Umständen zu vermeiden durchgedrungen zu sein.

Good Job, C++11.

Ethon schrieb:

Was?

Zu kurz.
Das std::array ist zu kurz.