JPEG CompressionQuality ermitteln

[Schwedenbitter]

Ich habe das - etwas unorthodox - für mich selbst jetzt so gelöst:

Delphi-Quellcode:

Function CalcCompressionQuality(Const JPG: TJPEGImage;
   Const MustFit: Boolean = False): TJPEGQualityRange;
Var
   aMS            : TMemoryStream;
   aBMP            : TBitmap;
   aJPG            : TJPEGImage;
   aSize            : Int64;
   lQ, hQ         : Integer;
   Piv, oldPiv      : Integer;                        // Ausgangswert = 0
Begin
   aMS:=  TMemoryStream.Create;                     // TMemoryStream erzeugen
   aBMP:= TBitmap.Create;                           // TBitmap erzeugen
   aJPG:= TJPEGImage.Create;                        // TJPEGImage erzeugen
   Try
      JPG.SaveToStream(aMS);                        // in Stream ablegen
      aSize:= aMS.Size;                              // Originalgröße ermitteln
      aBMP.Assign(JPG);                              // Bild ins TBitmap kopieren
      lQ:=    Low(Result);                           // untere Grenze
      hQ:=    High(Result);                        // obere Grenze
      Piv:= (hQ - lQ) Div 2;                        // in der Mitte anfangen
      Repeat
         aMS.Clear;                                 // Stream leeren
         aJPG.CompressionQuality:= Piv;            // Kompressionsrate setzen
         aJPG.Assign(aBMP);                        // Bitmap kopieren/komprimieren
         aJPG.SaveToStream(aMS);                     // JPG in Stream kopieren
         oldPiv:= Piv;                              // altes Pivot-Element merken
         If (aMS.Size > aSize) Then                  // Ergebnis ist zu groß
         Begin
            hQ:= Piv;                              // obere Grenze = aktueller Wert
            Piv:= Piv - ((hQ -  lQ) Div 2);         // neuen Wert berechnen
         End
         Else Begin                                 // Ergebnis kleiner oder gleich
            lQ:= Piv;                              // untere Grenze = aktueller Wert
            Piv:= Piv + ((hQ - lQ) Div 2);         // neuen Wert berechnen
         End;
      Until (Piv = oldPiv);                        // noch näher geht es nicht

      If (MustFit) And                              // auf keinen Fall größer !!!
         (aMS.Size > aSize) Then                     // immer noch zu groß
            Result:= Pred(Piv)                     //   => eine Nummer kleiner
      Else   Result:= Piv;            // aMS.Size = aSize => exakten Wert übergeben
   Finally
      aMS.Free;                                    // TMemoryStream freigeben
      aBMP.Free;                                    // TBitmap freigeben
      aJPG.Free;                                    // TJPEGImage freigeben
   End;
End;

Vermutlich lässt sich das sogar noch optimieren. Vielleicht findet über die Zeit jemand eine saubere(re) Lösung.

[mensch72]

Die Kompressionsrate eines JPG errechnet sich doch mathematisch rückwärts ganz simpel aus der JPG-Dateigröße im Verhältnis zum Speicherbedarf des RGB-PixelArrays:
x = (JPGfileSize*100%) / (Width*Height*3)

Wer es auf die meist 32Bit(ARGB) Speichergröße von Bitmaps im PC beziehen will rechnet eben mit "x4"
x = (JPGfileSize*100%) / (Width*Height*4)

JPGheader und JPGmetadaten sind genau wie "BitmapInfoHeader" hier zu vernachlässigen, weil es rückwärts eh stets nur eine Näherung ist.

[Medium]

CompressionQuality <> Kompressionsrate

[Schwedenbitter]

Zitat von Medium:

CompressionQuality <> Kompressionsrate

Danke. Ich glaube, mensch72 und ich reden aneinander vorbei.
Mich interessiert nicht die Kompressionsrate der Datei(größe).

[mensch72]

würdest du mir bitte deine "CompressionQuality" definieren?

Für mich bestimmt sich nunmal die "CompressionQuality" aus dem relativen Größenerhältnis von max. unkomprimierten Bilddaten und der Größe der komprimierten Bilddaten.

Wenn du Richtung Bildqualität bzw. Informationsverlust denkst, dann entscheidet da mehr die Kompressionssoftware und deren Algos&Vorfilter.
Ein AdobePhotoshop kann Bilder ohne groß auffälligen & fürs menschliche Auge sichtbaren Qualitätsverlust viel "kleiner" packen.

Wenn man ein 1GB Bild mit Delphi und Photoshop mit welchem "Kompressions-Wert" auch immer auf eine vergleichbare Dateigröße von 100MB also "1:10" komprimiert, wird warum auch immer die optische/gefühlte Bildqualität im durch Photoshop erzeugtem Bild höher sein... das rückwärts ohne org. Daten aus der Jpeg Datei zu bestimmen, also die bessere "CompressionQuality" im Sinne resultierend besserer Bildqualität zu ermitteln ist aus meiner Sicht nicht möglich. Nach meiner Methode des "relativen Größenvergleichs" wären beide Dateien gleich gut komprimiert und hätten für meine Software die selbe "CompressionQuality".

[nahpets]

CompressionQuality besagt, wie verlustbehaftet die Komprimierung ist. Bei 100% wird ohne Verlust komprimiert, bei kleineren Werten steigt der Verlust, d. h. die Bildqualität nimmt ab oder anders ausgedrückt: Das dekomprimierte Bild stimmt nicht mit dem Bild vor der Komprimierung überein. (Auch wenn die Bilder für das menschliche Auge gleich aussehen.)

https://de.wikipedia.org/wiki/JPEG

[Schwedenbitter]

Zitat von nahpets:

CompressionQuality besagt, wie verlustbehaftet die Komprimierung ist. Bei 100% wird ohne Verlust komprimiert, bei kleineren Werten steigt der Verlust, d. h. die Bildqualität nimmt ab oder anders ausgedrückt: Das dekomprimierte Bild stimmt nicht mit dem Bild vor der Komprimierung überein. (Auch wenn die Bilder für das menschliche Auge gleich aussehen.)

https://de.wikipedia.org/wiki/JPEG

Dem ist nichts hinzuzufügen.
CompressionQuality ist nicht irgend ein Wert, sondern gemeint ist der von Vcl.Imaging.jpeg.TJPEGImage.CompressionQuality , was dem geneigten Leser aber klar wird. Und da ich das Thema nicht erstellt habe, kann ich dessen Titel nicht beeinflussen.
[EDIT]Bedeutet 100 wirklich, dass es ohne Verlust komprimiert wird? Ich denke, dass zumindest die JPEG-Version von Delphi immer verlustbehaftet ist. Ich probiere das zur Not auch aus.[/EDIT]

Zitat von mensch72:

... Nach meiner Methode des "relativen Größenvergleichs" wären beide Dateien gleich gut komprimiert und hätten für meine Software die selbe "CompressionQuality".

Und genau das macht mein Code: er probiert aus, bei welcher CompressionQuality die gepackten Daten genauso groß wie in der Quelldatei sind
Ab jetzt befasse ich mich damit, wie man das ganze noch mit GDI+ realisiert. Damit tue ich mich im Moment noch schwer, weil es im Internet nur extrem wenige Quellen zu Delphi und GDI+ gibt...

[TiGü]

Zitat von Schwedenbitter:

Ab jetzt befasse ich mich damit, wie man das ganze noch mit GDI+ realisiert. Damit tue ich mich im Moment noch schwer, weil es im Internet nur extrem wenige Quellen zu Delphi und GDI+ gibt...

Guck dir mal die Unit Winapi.GDIOBJ (und Winapi.GDIPUTIL) an.
Mithilfe der ersten Unit wird ein hilfreicher Wrapper (Klassen basiert) über die flachen GDI+-Funktionen gestülpt.
Alle Methoden sind protected oder public, so dass man auch selber den Wrapper erweitern und mit hilfreichen Ableitungen arbeiten kann.
Er ähnelt der Klassen basierten C++ API und von daher ist die MSDN ein guter Anlaufpunkt für Informationen.
Auch als Delpi-Programmierer sollte man andere native Sprachen zumindest lesen können.
Der C++-Beispielcode ist in der Regel gut zu verstehen.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[Medium]

Zitat von Schwedenbitter:

[EDIT]Bedeutet 100 wirklich, dass es ohne Verlust komprimiert wird? Ich denke, dass zumindest die JPEG-Version von Delphi immer verlustbehaftet ist. Ich probiere das zur Not auch aus.[/EDIT]

Es wird im Normalfall NICHT verlustfrei komprimiert, auch bei einer Qualität von 100. Der Wert ist nicht als Prozent zu verstehen, sondern ist in der Regel entweder ein Faktor für die Quantisierungsmatrizen, oder eine diskrete Auswahl für die gewünschte Qualität optimierte Matrizen. Aber Quantisiert wird immer, und das ist der Schritt über den der Großteil an "Fehler" ins Bild kommt. Und da bei der Verarbeitung (besonders bei der DCT) ohnehin zwangsweise Rundungsfehler auftreten, würde man selbst komplett ohne Quantisierung nicht bei 1:1 Bildern landen.

Und selbst ohne diese: JPEG betreibt sog. 4:2:2 Color Subsampling. Das heisst, das Bild wird zunächst von RGB zu YCrCb umgewandelt, und die C-Komponenten nachher in Breite und Höhe halbiert. (Das geht ganz gut, da das Menschliche Auge Farbunterschiede eh nicht so gut auflösen kann wie Helligkeitsunterschiede.) Der Standard lässt prinzipiell auch anderes Subsampling zu (4:4:4, 4:1:1, etc.), aber als Standardwert wird praktisch überall 4:2:2 verwendet. Zumindest dort, wo man es nicht genau wüsste dass man etwas anderes nutzt. D.h. Rundungsfehler treten eh schon bei der Farbraumumwandlung auf, und dann eben noch "Fehler" durch das vierteln der Farbinformation. Noch bevor überhaupt transformiert wird oder der "CompressionQuality"-Wert in den Ablauf einfließt.

(Ja, ich habe schon mal einen JPEG Kompressor komplett zu Fuß gebaut.)

[Schwedenbitter]

Zitat von mensch72:

Die Kompressionsrate eines JPG errechnet sich doch mathematisch rückwärts ganz simpel aus der JPG-Dateigröße im Verhältnis zum Speicherbedarf des RGB-PixelArrays:

Gibt es dazu eine Quelle?
Und ist

Zitat:

Kompressionsrate

gleichbedeutend mit CompressionQuality ?

Zitat von mensch72:

x = (JPGfileSize*100%) / (Width*Height*3)

Wer es auf die meist 32Bit(ARGB) Speichergröße von Bitmaps im PC beziehen will rechnet eben mit "x4"
x = (JPGfileSize*100%) / (Width*Height*4)

JPGheader und JPGmetadaten sind genau wie "BitmapInfoHeader" hier zu vernachlässigen, weil es rückwärts eh stets nur eine Näherung ist.

Wofür stehen die

Zitat:

100%

? Also einfach 1 und damit die Dateigröße?