Office: (Office 2003) Thumbnails automatisch erstellen

Hallo,

ich habe eine Inventardatenbank, wo die User zu jedem Objekt Fotos hinzufügen können.

Das habe ich so gelöst, dass die User aus einem Dateiauswahl-Dialog das gewünschte Bild im Filesystem auswählen, diese Datei kopiere ich dann in ein bestimmtes Verzeichnis (mit eindeutigem, generierten Dateinamen) und danach schreibe in eine Fototabelle die ObjektID und den Dateinamen.

Funktioniert so auch wunderbar. Das Problem ist nur, dass die User dafür die Fotos so verwenden, wie sind z.B. direkt von der Digicam kommen - d.h. es sind teilweise sehr große Files. Was ja auch nicht schlecht ist, weil man das ja mal für den Druck brauchen könnte.

ABER es gibt in der Datenbank z.B. einen Bericht, wo man einen Inventar-Katalog ausdrucken kann. D.h. 12 Objekte pro A4-Seite mit kleinem Foto und den wichtigsten Daten.
Durch die großen Bilder dauert aber erstens das Laden und vor allem das Drucken des Berichts immer recht lang, und zweitens "streikt" Access spätestens nach ein paar Bericht-Seiten wegen der großen Datenmengen und lässt dann die Bilder einfach weg.

Meine Lösungsidee wäre jetzt, zusätzlich zu den Original-Dateien verkleinerte Vorschaubilder zu generieren und diese in einem eigenen Verzeichnis abzuspeichern. Dann könnten für solche Zwecke die kleinen Bilder genutzt werden und würden das Problem hoffentlich lösen.

Hat jemand dazu irgendeine Idee?
Ist sowas überhaupt mit VBA machbar?

lg Steffi

:)

 

hallo steffi,

vielleicht hilft Dir dieser VB-Code weiter :
http://www.vbarchiv.net/archiv/tipp_...s.php?pid=1083

 

Irgendwie kann ich damit in VBA nicht wirklich was anfangen... es gibt keinen Datentyp PictureBox mit all diesen Eigenschaften *leider*

 

Also schön langsam glaub ich, es gibt da gar keine Möglichkeit unter VBA.
Ich such jetzt schon den halben Tag, aber gefunden hab ich noch nix brauchbares...

 

Unter der Voraussetzung, dass deine DB unter Windows XP läuft, kannst du diesen Code verwenden:
Code:

Beispielaufruf:
ResamplePicFile "c:\meindigicam.bmp", "c:\bildordner\daszielbild.png", 30, pictypePNG

Falls W2000, dann brauchst du die Datei gdiplus.dll im Systemverzeichnis, die man hier bekommt:
http://www.microsoft.com/downloads/d...DisplayLang=en

GDIPLUS lädt bmp, jpg, gif, png, tif

Ciao, Sascha

 

und sollte -sofern noch nicht geschehen- auf jeden Fall im Auge behalten werden. Da gab's mal eine schöne Sicherheitslücke (google spuckt einiges dazu aus).

Zum Thema und @Sascha: *top!

 

\@Arne:
Das galt für die Version 1.1 von GDIPLUS, die auch mit O2003/O2007 vertrieben wird, dann aber auch nur von diesen geladen wird und sich im Office-Verzeichnis befindet, so dass IExplorer & Co nicht drauf zugreifen können.
In WinXP-SPs und Hotfixes wurde hingegen wieder eine ausgebesserte Version 1.0 untergebracht, die auch nicht im Systemverzeichnis ausgetauscht werden kann, weil dann der Windows DLL-Cache zuschlägt und das rückgängig macht.
Eine Sicherheitslücke gibt es seither nicht mehr und GDIPLUS ist allen möglichen Anwendungen inzwischen allgegenwärtig.

Gruß, Sascha

 

Ja, das ist mir halbwegs bekannt - die von steffi angegebene Access-Version passt aber gefährlich gut zu den Office-Versionen, die du erwähnst (so genau hatte ich das damals nicht verfolgt). [Edit] Eine umfangreichere Liste findet man z.B. unter http://www.heise.de/security/artikel/51526 (beachte auch die betroffenen Windows-Komponenten). [/Edit]

Immerhin gibt es genügend Rechner, die noch ungepatcht rumstehen, weil der surfende Administrator auf solchen Firlefanz verzichtet (damit will ich das aber steffi nicht unterstellen).

Sollte aber auch nur eine Randbemerkung sein und ist hier sicherlich OT (sorry).

 

Nein, stimmt so ganz nicht. Das auf Heise ist auch etwas verwirrend.
O2003 legt bei Installation die gdiplus.dll in das Office11-Verzeichnis. Da das nicht im Systempfad liegt und die DLL auch keine ActiveX ist, kann keine andere Anwendung was damit anfangen. Schon gar nicht IE oder OL. Da ist es egal, ob W2000 oder WXP. Die Redistributable wiederum in meinem Link ist nicht gefährdet.
Infizierte JPGs werden darüber hinaus von jedem Virenscanner erkannt. Wenn so einer auf Steffis Rechner fehlt, dann kann man ihr auch nicht helfen... *wink.gif* (Die JPEGs kommen doch von einer Digicam? Deren Firmware sollte doch hoffentlich nicht malicious jpegs produzieren?)

Ciao, Sascha

 

Hi,

es handelt sich bei mir um ein Office 2003 ADP file (Frontend zu einer MS SQL Server DB). Das Ganze läuft auf einem Windows 2003 Server, der updatemäßig immer auf dem aktuellsten Stand gehalten wird.

Ich hab jetzt mal nach einer gdiplus.dll gesucht - und gleich ein paar davon gefunden, u.a. im Office-Verzeichnis.

Ich denk, es sollte unter Win2003 so funktionieren, wie Sascha das für WinXP beschrieben hat. Ich probier das jetzt mal aus und dann geb ich euch Bescheid.

lg Steffi

 

Erfolgsmeldung!!!

Danke Sascha, der Code funktioniert 1A.

 

Feine Sache, was der gute Sascha da so aus'm Ärmel zaubert !
Thanks *winner

 

Hi,

ich hab jetzt doch noch einen Kritikpunkt an der Sache:
Die durch diesen Code erzeugten Bilder werden ziemlich grauslich:
Beispiel-Foto
Zum Vergleich: Original-Foto

Das einzige, was ich an Saschas Code geändert habe ist, dass Breite u. Höhe des Thumbnails nicht anhand eines Prozentwerts berechnet werden, sondern durch einen fixen Wert:
Code:

D.h. die längere Seite eines Bildes entspricht dann immer der ThumbSize (z.B. 640px).
Aber ich glaub kaum, dass es an dieser Veränderung liegt.

Kann man irgendwas am Code von Sascha ändern, damit die Bildqualität des Thumbnails besser wird?

Die Dateigröße liegt übrigens auch noch weit über dem, was ich mit Bildbearbeitungsprogrammen erreiche (und das bei qualitativ besseren Thumbnails) - aber das ist noch ok u. auch nicht wirklich verwunderlich.

 

Hab jetzt erst die folgende Zeile im Code entdeckt:
Code:

Aber leider bringt die Erhöhung dieses Werts auch keine merkbare Verbesserung in der Bildqualität des fertigen Thumbnails.

Was interessant ist: wenn man als Quelle ein Bild angibt, das kleiner ist - es also durch diesen Code vergrößern lässt - dann ist die Qualität nicht so schlecht. Nur beim Verkleinern wirds grauenvoll (siehe Beispielbild von vorhin).

Hat keiner eine Idee, woran das liegen könnte?

 

Danke, stefacht, für deinen Test!
Interessante Geschichte. Das passiert mit dem obigen Code nur, wenn das Quellbild ein JPG ist. Bei anderen Formaten nicht.
Mir ist das bisher noch nicht aufgefallen, weil ich das Prozedere normalerweise in drei Prozeduren aufsplitte:
1. Prozedur zum Laden der Datei
2. Eine zum Skalieren des Bildes
3. Eine zum Speichern der Zieldatei
Dazwischen werden die Rückgaben dieser Prozeduren jeweils in einer StdPicture-Variablen gespeichert. Dabei tritt dieser Effekt nicht auf.
In meinem Code oben hab ich diese drei Prozeduren zu einer zusammengefasst. Und da scheint es so, als ginge GDIPLUS mit JPGs speziell um. Anscheinend werden die nach einem anderen Algorithmus skaliert. Die Lösung ist nun (...hat eine halbe Stunde gedauert, bis der Groschen gefallen ist...), aus dem geladenen GDIPLUS-Image zunächst ein Windows-Speicherbitmap zu erstellen und dieses wieder in ein GDIPLUS-Image zurückzuverwandeln. Erst dann findet die Skalierung mit der Thumbnail-Funktion statt.
Das korrigierte Code-Modul sieht nun so aus:
Code:

Gruß, Sascha