Hilfe zu IThumbnailProvider

[Benmik]

@Himitsu: Mein Fokus hat sich im Laufe der Recherche etwas verschoben, seit klar ist, dass IThumbnailProvider quadratische Bilder zurückliefert. Ich würde mittlerweile aus sportlichen Gründen gern wissen, wie man diese Sachen mit COM-Objekten und Factories bei IThumbnailProvider richtig handhabt und warum mein Code nicht funktioniert. Vielleicht erbarmt sich ja irgendwann einmal ein Wissender, der hier vorbeikommt, und erklärt es mir.

@striderx: Danke! Nie von gehört.

@venice2: Super-Link! Zum Lernen offenbar genau das Richtige!

[Benmik]

Ich vermute mal, dass wegen der Seltenheit des Suchwortes "IThumbnailProvider" im Laufe der Zeit noch so einige Leute über Google hierher kommen werden, von denen eine Reihe auch an der Extraktion von Vorschaubildern für ihre JPG interessiert sind.

Daher möchte ich hier erwähnen, welche Lösung ich für mich gefunden habe. Und zwar betten immer mehr Kameras in die JPG neben einem kleinen Thumbnail (APP1) auch noch ein weiteres großes Bild im Full-HD-Format ein, also 1920 x 1080 Pixel. Dies geschieht mittels MPF (Multi-Picture Format), einem Zusatz zur EXIF-Spezifikation, das im APP2 gespeichert wird. (Sogar die kleine Panasonic TZ101 tut das). Bei deutlich größeren Vorschaubildern als 120 Pixel Breite ist die Hochskalierung des eingebetteten Thumbnails keine Option, eine Vorschau größer als 1920 Pixel wird es aber wohl kaum geben. Es bietet sich also an, dieses Bild zu extrahieren und schlicht mit StretchDraw in der gewünschten Größe zu zeichnen.

Meine JPG haben mittlerweile locker 20 MB, während die MPF-Bilder meist zwischen 300 und 900 kB groß sind. Das Einlesen von so großen JPG und vor allem die Dekomprimierung verbrauchen enorme Zeit und Speicher. Dies bedeutet auch, dass nur relativ wenige JPG im Speicher gehalten und beim erneuten Einlesen direkt aus dem Speicher genommen werden können. Bei der MPF-Lösung werden jedoch nur die ersten 256 kB für das EXIF eingelesen (weniger als 256 kB liest Windows sowieso nicht) und dann nochmal die 300 - 900 kB für das MPF, wenn man sie selektiv aus dem Dateistream liest. Tatsächlich benötigt das Einlesen beim ersten Durchgang nur 10 msec je Datei, und ab dem zweiten nur 1 msec, und das auch bei 4.500 Dateien (16 GB Speicher).

Ich füge noch den Code bei, wie ich von TBytes zu TBitmap komme:

Delphi-Quellcode:

uses
  ...
  JpegImage,SynGDIPlus,...

var
  JpegImage:TJpegImage;
  BMP:TBitmap;
  TBMPF: TBytes;
  Breite, Höhe: integer;
If EXIF.ExtrahiereMPF(TBMPF) then begin
  JpegImage := TJpegImage.Create;
  JpegImage.CreateFromBuffer(TBMPF, Length(TBMPF));
  BMP := TBitmap.Create(Breite, Höhe);
  BMP.PixelFormat := pf24bit;
  BMP.Canvas.StretchDraw(BMP.Canvas.ClipRect,JpegImage.ToBitmap);
  JpegImage.Free;
end;

ExtrahiereMPF ist eine Methode aus meiner selbst geschriebenen EXIF-Unit, die das MPF-Bild aus dem Filestream in einen TBytes-Puffer kopiert. Ich füge noch ein Diagramm der relevanten MPF-Struktur bei, die unglaublich kompliziert und verwirrend gestaltet wurde. Die Spezifikation findet man hier. .CreateFromBuffer und .ToBitmap kommen aus SynGDIPlus von Synopse.

EDIT: Durch mein neues Vorgehen fällt plötzlich auf, dass keineswegs alle Bilder meiner Sony ein MPF haben, was mich total verblüfft. Eine Untersuchung zeigt, dass fast alle Bilder, die keins haben, Hochkantbilder sind. Eine Erklärung dafür könnte die sein, dass diese MPF damals eigentlich dazu eingeführt wurden, dass auf einem Fernseher ein besseres Vorschaubild gezeigt werden konnte. Da Hochkantbilder auf einem Fernseher viel kleiner dargestellt werden, wurde das bei ihnen wahrscheinlich weggelassen. Die Sony-Kameras werden in den Specs regelmäßig mit "MPF Baseline compliant" beworben. Es scheint so, als wäre eine alte Sache einfach immer weitergeführt worden. Verrückt.

[himitsu]

Problem an TJpegImage und Co. ist oft, dass selbst bei Zoom, oftmals die Bilder zuerst in ein TBitmap gezeichnet und anschließend gestrecht werden,
anstatt gleich gestrecht in das Temp-Bitmap gezeichnet zu werden.

Drum hat Delphi, z.B. im TImage, mit großen Bildern (JPEG,PNG,TIFF) oft Probleme.
z.B. siehe TWICImage, denn die WIC-API (Windows Imaging Component) ist eigentlich speziell für die stückchenweise Behandlung extrem großer Bilder sehr speichersparend optimiert .... man müsste nur die API richtig benutzen.

Ich hab hier einen netten Testfall, wo eine technische Zeichnug als TIFF nur wenige 100 KB groß ist, aber beim Versuch ein Vorschaubild zu bekommen, da rauchen die Delphi-Klassen bei ab, weil als Bitmap ist das Ding rießig.

[striderx]

Zitat von Benmik:

@striderx: Danke! Nie von gehört.

GDIPAPi und GDIPOBJ gehören zum Lieferumfang von Delphi.

[Benmik]

Zitat von himitsu:

Problem an TJpegImage und Co. ist oft, dass selbst bei Zoom, oftmals die Bilder zuerst in ein TBitmap gezeichnet und anschließend gestretcht werden,...

Das ist interessant, denn ich beobachte bei meiner Methode, dass die 16 GB bis an den Rand vollaufen, was so erstmal nicht verständlich ist. 1920 x 1080 müssten als Bitmap etwa 6 MB sein, das kann doch eigentlich 16.000 MB nicht auslasten, zumal sie ja nach dem Zeichnen sofort freigegeben werden.

Was käme denn als Alternative in Frage? Ich muss da wohl noch ein bisschen forschen.

[Benmik]

Zitat von himitsu:

z.B. siehe TWICImage...

Das war ein wunderbarer Hinweis. Ich habe mal probehalber auf TWICImage umgestellt und siehe da, plötzlich sind alle 24 Kerne voll ausgelastet und die Speicherbefüllung steigt langsam und linear bis auf 65% und verharrt dann dort; und das trotz einiger Umkopiererei. Sehr nützlich war diese Routine von hier ("High quality bitmap resize with transparency"):

Delphi-Quellcode:

Uses
  Winapi.Wincodec,
  Vcl.Graphics;

procedure ResizeBitmap(Bitmap: TBitmap; const NewWidth, NewHeight: integer);
var
  Factory: IWICImagingFactory;
  Scaler: IWICBitmapScaler;
  Source : TWICImage;
begin
  Bitmap.AlphaFormat := afDefined;
  Source := TWICImage.Create;
  try
    Factory := TWICImage.ImagingFactory;
    Source.Assign(Bitmap);
    Factory.CreateBitmapScaler(Scaler);
    Scaler.Initialize(Source.Handle, NewWidth, NewHeight,
      WICBitmapInterpolationModeHighQualityCubic);
    Source.Handle := IWICBitmap(Scaler);
    Bitmap.Assign(Source);
    Scaler := nil;
    Factory := nil;
  finally
    Source.Free;
  end;
end;

Dieses TWICImage muss ich mir noch genauer anschauen.

[himitsu]

Der Scaler ist zwar nicht der Schnellste (gegenüber Anderem z.B. aus GDI+)
aber er arbeitet in kleinen Blöcken und braucht selber somit kaum Speicher.
Nur blöd, wenn Delphi selber ihn garnicht verwendet und stattdessen ein TBitmap nimmt und dort über TCanvas kopiert/skaliert.
Auch schmeißen sie direkt nach dem Laden viele Interfaces sofort wieder weg, so daß man sich selber Vieles wieder unnötig neu erstellen muß.