EXIF-Thumbnail-Generator gesucht
Dieter Lefeling
offenbar ist es selbst bei Software der Groessenordnung Photoshop nicht
ueblich, dass nach Bearbeitungen auch das Vorschaubild im EXIF-Header
der Bilddatei angepasst wird, geschweige denn andere EXIF-Info auf den
korrekten Wert gesetzt wird. Vielmehr bleibt im Header das nunmehr
falsche Thumbnail und ggf. andere falsche Bilddaten erhalten. Tja...
Gaengige Programme wie Irfanview oder XnView koennen zwar schnell und
problemlos Thumbnails fuer ihre Browser generieren, schreiben aber keine
in die Datei. Was fehlt, ist eine Moeglichkeit zum schnellen Thumbnail-
Updaten, moeglichst noch im Batchbetrieb.
Bleibt noch Exifer. Das Programm bietet genau eine solche Funktion
(Vorschaubild erzeugen), aber diese Funktion arbeitet fehlerhaft und die
Thumbnails sind Grotte (mitunter erhebliche Moiree-Effekte, die das Bild
nur noch erahnen lassen).
Was ich suche, ist ein Programm - Kommandozeile oder GUI, Windows -, das
ein nichtvorhandenes Exif-Thumbnail erzeugt bzw. ein vorhandenes durch
ein neu erzeugtes ersetzt. Jhead kann vieles, Thumbnails jedoch nur
loeschen, nicht aber schreiben. Ich wundere mich ehrlich gesagt, dass
das die einschlaegigen "Universalprogramme" a la Irfanview/XnView nicht
bieten, bzw. dass selbst Photoshop (hier Version 6) beim Speichern nach
der Bearbeitung das nun ungueltige Vorschaubild in der Datei belaesst
und kein neues generiert.
Nun denn also - gibt es da was geeignetes?
Dieter
Christian Georg Becker
> Bleibt noch Exifer. Das Programm bietet genau eine solche Funktion
> (Vorschaubild erzeugen), aber diese Funktion arbeitet fehlerhaft und die
> Thumbnails sind Grotte (mitunter erhebliche Moiree-Effekte, die das Bild
> nur noch erahnen lassen).
FixFoto kann das auch.
Krischan
Horst Saak-Winkelmann
<cbe...@informatik.hu-berlin.de> :
...
Worauf soll der geneigte Leser denn jetzt die Betonung legen?
* FixFoto kann Vorschaubilder erzeugen
* FixFoto kann fehlerhafte Vorschaubilder erzeugen
Gruß, Horst
--
Al Bogner
> Was ich suche, ist ein Programm - Kommandozeile oder GUI, Windows -, das
> ein nichtvorhandenes Exif-Thumbnail erzeugt bzw. ein vorhandenes durch
> ein neu erzeugtes ersetzt.
Ich verstehe zwar nicht, wann man so was braucht, aber ich nutze ja auch
kein Windows.
Lies mal hier um diesen Thread: http://www.cpanforum.com/posts/1458 (Copying
a preview image from one file to another)
In Verbindung mit Imagemagick müsste das doch per Script zu schaffen sein,
wenn es mit exiftool nicht alleine geht.
Al
Horst Saak-Winkelmann
<root.forwa...@n04c-nospam.pinguin.uni.cc> :
...
>Ich verstehe zwar nicht, wann man so was braucht, aber ich nutze ja auch
>kein Windows.
...
Wie Dieter schon schrieb: "offenbar ist es selbst bei Software der
Groessenordnung Photoshop nicht
ueblich, dass nach Bearbeitungen auch das Vorschaubild im EXIF-Header
der Bilddatei angepasst wird, geschweige denn andere EXIF-Info auf den
korrekten Wert gesetzt wird."
...
>Lies mal hier um diesen Thread: http://www.cpanforum.com/posts/1458 (Copying
>a preview image from one file to another)
...
Das ist dann nicht die Lösung.
...
>In Verbindung mit Imagemagick müsste das doch per Script zu schaffen sein,
>wenn es mit exiftool nicht alleine geht.
...
"Müsste" ... :-(
Deshalb hier ja der Aufruf das sich mal jemand meldet der es "weiß".
Oder hieß das jetzt "Imagemagick kann das" und "exiftool kann das"?
Gruß, Horst
--
Al Bogner
>>Ich verstehe zwar nicht, wann man so was braucht, aber ich nutze ja auch
>>kein Windows.
> ...
> Wie Dieter schon schrieb: "offenbar ist es selbst bei Software der
> Groessenordnung Photoshop nicht
Nochmals, warum will man ein Vorschaubild haben? Ich lösche die immer raus.
Braucht man unter Windows eines um ein "kleines" Bild im Dateimanager zu
sehen? Bei Konqueror unter Linux ist es zB nicht nötig, da unter .thumbnails
eines automatisch erzeugt und zugeordnet wird.
>>Lies mal hier um diesen Thread: http://www.cpanforum.com/posts/1458
>>(Copying a preview image from one file to another)
> ...
> Das ist dann nicht die Lösung.
Warum? Dort steht doch dass es klappt, aber etwas umständlich.
>>In Verbindung mit Imagemagick müsste das doch per Script zu schaffen sein,
>>wenn es mit exiftool nicht alleine geht.
> ...
> "Müsste" ... :-(
Ich kenne die Voraussetzungen von Dieter nicht. Die Frage ist, ob er schon
ein passenden Bild irgendwie bei seinen Bearbeitungen erstellt hat, dann
kann er es direkt mit exiftool hineinkopieren wenn nicht, dann muss er eben
mit IM (convert) eines erzeugen und danach kopieren, das ist 1 Zeile im
Script. etwa so convert quellbild -resize ... vorschaubild.
Ich weiß nun nicht, welche Eigenschaften ein Vorschaubild haben muss, aber
mit identify -verbose findet man das leicht raus.
> Deshalb hier ja der Aufruf das sich mal jemand meldet der es "weiß".
> Oder hieß das jetzt "Imagemagick kann das" und "exiftool kann das"?
Du willst die Manuals von IM und exiftool lesen. Für _konkrete_ Fragen
kannst du dich dann wieder melden. Wer IM und exiftool verwenden will, der
bekommt das zwar gratis, aber für den Preis der Auseinandersetzung mit den
Möglichkeiten mit diesen mächtigen Tools. Eine fertige Klicklösung erhält
man damit nicht. Für Spezialfragen gibt es für beide Tools Foren, sowie die
IM-Mailinglist.
Al
Horst Saak-Winkelmann
<root.forwa...@n04c-nospam.pinguin.uni.cc> :
...
>Nochmals, warum will man ein Vorschaubild haben? Ich lösche die immer raus.
>Braucht man unter Windows eines um ein "kleines" Bild im Dateimanager zu
>sehen? Bei Konqueror unter Linux ist es zB nicht nötig, da unter .thumbnails
>eines automatisch erzeugt und zugeordnet wird.
>
>>>Lies mal hier um diesen Thread: http://www.cpanforum.com/posts/1458
>>>(Copying a preview image from one file to another)
>> ...
>> Das ist dann nicht die Lösung.
>
>Warum? Dort steht doch dass es klappt, aber etwas umständlich.
...
Du willst es offenbar nicht verstehen bzw. lesen :-(
Es geht um ein Vorschaubild _nach einer Bildmanipulation_. Und das
kann auch bedeuten das man z.B. etwas in ein bestehendes Bild einfügt,
etwas wegstempelt, etc.. Dann sollte das in der Bilddatei enthaltene
Vorschaubild entsprechend aktualisiert werden.
Vorschaubilder auslagern und wieder einlesen (Copying a preview image
from one file to another) ist nicht das Problem!
Gruß, Horst
--
Hans Wein
> Ich wundere mich ehrlich
> gesagt, dass das die einschlaegigen "Universalprogramme" a la
> Irfanview/XnView nicht bieten, bzw. dass selbst Photoshop (hier
> Version 6) beim Speichern nach der Bearbeitung das nun ungueltige
> Vorschaubild in der Datei belaesst und kein neues generiert.
Bei der Erstellung der EXIF-Spezifikation wurde seinerzeit eine Größe
des Vorschaubildchens von nur 120x160 Pixel vorgesehen. Dem gegenüber
können nahezu alle Bildbrowser (auch der Windows-Explorer) auf Wunsch
auch mit größeren Bildern arbeiten, was bei den heutigen Monitorgrößen
auch nicht verkehrt ist. In diesem Fall muss ohnehin das Thumbnail aus
dem eigentlichen Bild erzeugt werden, was bei der Leistungsfähigkeit
moderner PCs auch nicht mehr so viel Zeit kostet. Wahrscheinlich
verspüren deshalb die Entwickler keinen sonderlichen Drang, sich dieser
Thematik (mehr) anzunehmen.
MfG
Hans
Andre Storch
>Horst Saak-Winkelmann schrieb
> Worauf soll der geneigte Leser denn jetzt die Betonung
> legen?
> * FixFoto kann Vorschaubilder erzeugen
> * FixFoto kann fehlerhafte Vorschaubilder erzeugen
Fixfoto aktualisiert das Vorschaubild beim Speichern nach
Bearbeitung und hat wohl auch eine Funktion, um
nur die Bilder im Batch-Mode zu aktualisieren.
(Die habe ich aber noch nicht beforscht)
Grüße
André
Dieter Lefeling
> Bei der Erstellung der EXIF-Spezifikation wurde seinerzeit eine Größe
> des Vorschaubildchens von nur 120x160 Pixel vorgesehen.
Das reicht ja auch. Ich verwende fuer die Ansicht noch kleinere.
> Dem gegenüber
> können nahezu alle Bildbrowser (auch der Windows-Explorer)
Ab XP, ja.
> auf Wunsch
> auch mit größeren Bildern arbeiten, was bei den heutigen Monitorgrößen
> auch nicht verkehrt ist.
Ich bin 24x36-Kontaktboegen gewohnt, das ist deutlich kleiner als
120x160 Pixel in 1280er-Aufloesung auf 19"-Monitor.
> In diesem Fall muss ohnehin das Thumbnail aus
> dem eigentlichen Bild erzeugt werden, was bei der Leistungsfähigkeit
> moderner PCs auch nicht mehr so viel Zeit kostet. Wahrscheinlich
> verspüren deshalb die Entwickler keinen sonderlichen Drang, sich dieser
> Thematik (mehr) anzunehmen.
Dann sollen sie nach der Bearbeitung die Thumnails loeschen anstatt die
alten, fehlerhaften Daten in der Datei zu belassen. Wie auch andere
fehlerhafte Daten des Exif-Headers, etwa die Bildgroesse, die nach
Ausschnitt- oder Groessenaenderung i.d.R. *nicht* aktualisiert wird.
Dieter
Dieter Lefeling
> Ich verstehe zwar nicht, wann man so was braucht, aber ich nutze ja auch
> kein Windows.
Man kann ueber den Sinn und Zweck von jpeg-integrierten Thumbnails
diskutieren - das ist nichts windows-spezifisches, seit XP und schon
laenger bei den einschlaegigen Programmen mit Browserfunktion werden
Thumbnails selbstaendig generiert. Nur fuer diese Verwendung koennte man
sie also rausloeschen und jedesmal von der Software neu generieren
lassen. Nicht alle Programme machen das so geschickt wie etwa XnView und
arbeiten mit einem einstellbaren Thumbnail-Cache. Auch dort geht es aber
mit den dateiinternen Thumbnails (kann man einstellen) schneller.
Anyway - es geht darum, dass das im Header vorhandene Thumbnail nach
einer Bearbeitung in einschlaegiger Software nicht aktualisiert wird.
Eigentlich ein klarer Programmfehler. Aendert man also den Ausschnitt
oder passt Helligkeit und Farbe an, suggeriert das Thumbnail nach wie
vor den Stand vor der Bearbeitung. Ich moechte diesen Fehler beheben und
ein neues, aktualisiertes Thumbnail generiert haben. So wie Exifer das
schon anbietet, nur bitte "besser" und technisch fehlerfrei.
> Lies mal hier um diesen Thread: http://www.cpanforum.com/posts/1458 (Copying
> a preview image from one file to another)
Scheint nicht noetig zu sein, diese Funktion bietet Exifer ebenfalls.
Man kann ein Thumbnail von Datei X in Datei Y uebertragen. Nur - woher
nimmt man eine zweite Bilddatei mit dem Thumbnail der ersten?
> In Verbindung mit Imagemagick müsste das doch per Script zu schaffen sein,
> wenn es mit exiftool nicht alleine geht.
Wie sagt man noch gleich auf unix: -v
Ich habe bisher nur die Funktion -thumbnail von convert bemerkt, zu der
die Doku meint, sie diene der Erzeugung von Thumbnails. Von solchen im
Dateiheader steht da nix.
Dieter
Al Bogner
> Du willst es offenbar nicht verstehen bzw. lesen :-(
> Es geht um ein Vorschaubild _nach einer Bildmanipulation_.
Und, wo ist das Problem?
Es wird also ein Bild verändert und danach neu abgespeichert, oder?
Von diesem neuen Bild ist es doch kein Problem ein kleines Bild nach
bestimmten Spezifikationen zu erzeugen. Vgl. auch
http://www.cit.gu.edu.au/~anthony/graphics/imagick6/thumbnails/
Die Beispiele von http://www.cit.gu.edu.au/~anthony/graphics/imagick6/ sind
übrigens sehr lesenswert.
> Und das
> kann auch bedeuten das man z.B. etwas in ein bestehendes Bild einfügt,
> etwas wegstempelt, etc.. Dann sollte das in der Bilddatei enthaltene
> Vorschaubild entsprechend aktualisiert werden.
Du kannst alles mögliche machen, letztlich ist es aber wieder ein _Bild_ mit
Größe X im Format Y. Es muss ja nicht unbedingt jpg sein. Dieses Bild kann
man doch passend verkleinern
convert -size 1000x100 xc:khaki canvas_khaki.jpg
convert -size 1000x18 xc:Orange -background Orange +size canvas_khaki.jpg
-append -gravity North -annotate 0 "BEISPIEL" canvas_khaki2.jpg
Nun ist die monochrome Farbfläche oben durch einen orangen Steifen erweitert
worden, in dem "BEISPIEL" steht.
Jetzt möchte ich davon ein Vorschaubild haben und zwar proportional auf der
X-Achse mit einer Größe von 120 Pixel.
convert canvas_khaki2.jpg -resize 120x canvas_khaki3.jpg
canvas_khaki.jpg ist also das Original
canvas_khaki2.jpg das veränderte Original und
canvas_khaki3.jpg das _neue_ Vorschaubild
Und nun kommt exiftool dran.
> Vorschaubilder auslagern und wieder einlesen (Copying a preview image
> from one file to another) ist nicht das Problem!
Gut, dann brauche ich das wohl nicht mehr erklären.
In einem Script ist es in einer Schleife wohl nicht allzu schwer alle
veränderten Bilder abzufragen, mit convert ein Vorschaubild zu erzeugen und
das dann mit exiftool hineinzukopieren.
Ich glaube übrigens auch, dass man mit IM das Bild hineinkopieren kann,
löschen kann man es ja auch. Da darfst du aber selber nachlesen. 1 Lösung
habe ich ja aufgezeigt.
Al
Al Bogner
> Dann sollen sie nach der Bearbeitung die Thumnails loeschen anstatt die
> alten, fehlerhaften Daten in der Datei zu belassen. Wie auch andere
> fehlerhafte Daten des Exif-Headers, etwa die Bildgroesse, die nach
> Ausschnitt- oder Groessenaenderung i.d.R. *nicht* aktualisiert wird.
FULL ACK,
deswegen löscht mein Script bei der "sonstigen" Bearbeitung mit ImageMagick
sofort alles bis auf das größte Bild, wobei ich annehme, dass das größte
Bild das beste ist und nicht notwendigerweise das 1. Bild ist. Ebenso
komprimiere ich meine Tiff-Bilder intern mit zip, falls mein Script
entdeckt, dass es anders kompromiert ist. Das läuft alles mit ImageMagick.
Wenn ich in den nächsten Tagen vielleicht mal Zeit habe, werde ich das näher
testen. Schickst du mir per PM irgendein bearbeitetes Bild, bei dem man
klar erkennt, dass die Original-Bildvorschau nicht mehr passt.
Bei dieser Bearbeitung soll man auch noch darauf achten, dass das Bild nicht
unnötigerweise als jpg zwischengespeichert wird. Eventuell hilft eine Pipe
im Miff-Format (nicht Tiff!). Ich muss mir das alles aber erst mal
überlegen und augenblicklich ist Zeit knapp.
Al
Dieter Lefeling
> Es wird also ein Bild verändert und danach neu abgespeichert, oder?
Ja.
> Von diesem neuen Bild ist es doch kein Problem ein kleines Bild nach
> bestimmten Spezifikationen zu erzeugen.
Es geht darum, dieses Bild in den Header der grossen Datei zu bekommen.
Aber das ist eigentlich nur ein workaround.
Eigentlich geht es darum, in einem Schritt direkt ein neues Thumbnail im
Dateiheader zu erzeugen. Okay, man kann das scripten. Nur - zehn Dateien
in einer Uebersicht zu markieren und dann "bei diesen bitte mal eben das
Thumbnail updaten", also schnell, einfach und effektiv, das geht damit
eben nicht. Genau das leistet Exifer - nur eben fehlerhaft.
> Vgl. auch
> http://www.cit.gu.edu.au/~anthony/graphics/imagick6/thumbnails/
Da steht, wie convert ein separates Thumbnail erzeugt.
Das kann meine vorhandene Software, sogar noch eine Ecke bequemer.
Nein, ich brauche keine Rahmen oder Einblendungen im Thumbnail. <8)
> Du kannst alles mögliche machen, letztlich ist es aber wieder ein _Bild_ mit
> Größe X im Format Y. Es muss ja nicht unbedingt jpg sein. Dieses Bild kann
> man doch passend verkleinern
Jaja, aber das ist alles ueberhaupt kein Thema.
> convert -size 1000x100 xc:khaki canvas_khaki.jpg
> [ snip diverse Zeilen ]
> canvas_khaki3.jpg das _neue_ Vorschaubild
Also, ich darf Dir versichern: eine 120x160-Version von einem groesseren
Bild zu erstellen, bekomme ich gerade noch hin. Schnell, bequem und in
allen moeglichen Varianten. <8)
> Und nun kommt exiftool dran.
>
> > Vorschaubilder auslagern und wieder einlesen (Copying a preview image
> > from one file to another) ist nicht das Problem!
>
> Gut, dann brauche ich das wohl nicht mehr erklären.
Was bisher (mit Exifer) moeglich ist: das in Datei X enthaltene
Exif-Thumbnail zu kopieren in den Header von Datei Y.
Was man hier braucht (und was Du wahrscheinlich meinst), ist die
Moeglichkeit, eine vorhandene separate Thumbnail-Datei in den Header
einer anderen Bilddatei zu uebertragen. Das waere ein workaround, wenn
auch nicht direkt die nachgefragte Loesung.
> In einem Script ist es in einer Schleife wohl nicht allzu schwer alle
> veränderten Bilder abzufragen, mit convert ein Vorschaubild zu erzeugen und
> das dann mit exiftool hineinzukopieren.
Also nochmal: es ist mit exiftool also moeglich, eine vorliegende Datei
bild_klein.jpg in den Exif-Header von bild_gross.jpg zu kopieren. Auch
exiftool kann aber nicht selbstaendig ein neues Thumbnail im Dateiheader
erzeugen. Ist das so korrekt?
> Ich glaube übrigens auch, dass man mit IM das Bild hineinkopieren kann,
Wie?
> löschen kann man es ja auch.
Loeschen koennen sie alle: Irfanview, XnView, jhead... Nur neu erzeugen
oder ein vorhandendes separates Thumbnail in den Header einer andere
Datei kopieren, das koennen sie eben nicht. Waere es anders, stellte
sich die Frage nicht.
Dieter
Dieter Lefeling
> Wenn ich in den nächsten Tagen vielleicht mal Zeit habe, werde ich das näher
> testen. Schickst du mir per PM irgendein bearbeitetes Bild, bei dem man
> klar erkennt, dass die Original-Bildvorschau nicht mehr passt.
Kann ich machen - melde Dich dann noch einmal hier.
Es reicht aber ein beliebiges Bild mit geaendertem Ausschnitt.
Jedenfalls wenn eine gaengige Software wie Photoshop und Konsorten da
"dran" war.
Dieter
Hans Wein
> Dann sollen sie nach der Bearbeitung die Thumnails loeschen anstatt
> die alten, fehlerhaften Daten in der Datei zu belassen. Wie auch
> andere fehlerhafte Daten des Exif-Headers, etwa die Bildgroesse, die
> nach Ausschnitt- oder Groessenaenderung i.d.R. *nicht* aktualisiert
> wird.
Wenn man die Exifdaten als Dokumentation des Bildaufnahmevorganges
betrachtet, so wäre das Löschen derselben durch die EBV-Programme in
gewisser Weise sogar folgerichtig. Schließlich hat bei entsprechendem
Bearbeitungsaufwand das bearbeitete Bild womöglich nicht mehr viel mit
dem Original aus der Kamera zu tun.
Erschwerend kommt noch hinzu, dass bestimmte Werte wie z.B. die Größe
nicht nur im "allgemeinen" Teil der Daten, sondern teilweise auch noch
wie bei Olympus in den Makernotes hinterlegt ist. Wer in diesem Bereich
auch noch alles berücksichtigen will, kommt vom Hundersten ins
Tausendste.
MfG
Hans
Al Bogner
> Es geht darum, dieses Bild in den Header der grossen Datei zu bekommen.
> Aber das ist eigentlich nur ein workaround.
Manchmal gibt es leider nur Workarounds. Ich habe mich bei den Exifdaten
auch daran gewöhnen müssen, dass es besser ist, es irgendwie hinzubekommen
als gar nicht. Mittlerweile enthalten alle meine jpg, tiff und png-Dateien
mindestens die Original-Exif-Daten, sofern dies sinnvoll ist und eine Reihe
weitere Metadaten inkl. IPTC. Da gibt es zum Teil Probleme, die ich nicht
mal mehr als "würgaround" bezeichnen will, das ist zum Verzweifeln.
Manchmal bleibt nur mehr die Lösung, von einer anderen Datei die Metadaten
zurückzukopieren. Zum Glück kann das Exiftool gezielt und automatisch.
> Eigentlich geht es darum, in einem Schritt direkt ein neues Thumbnail im
> Dateiheader zu erzeugen. Okay, man kann das scripten. Nur - zehn Dateien
> in einer Uebersicht zu markieren und dann "bei diesen bitte mal eben das
> Thumbnail updaten", also schnell, einfach und effektiv, das geht damit
> eben nicht. Genau das leistet Exifer - nur eben fehlerhaft.
Wir sind uns einig, dass das eigentlich die EBV korrekt machen soll. Es gibt
ein neues Gimp, vielleicht klappt es damit?
Ich bin aber nicht der Meinung, dass es mit Maus markieren schneller geht,
als ein Script aufzurufen.
thupd.sh <pfad> oder ähnlich ist sehr schnell getippt, wenn man die
Tab-Taste zur automat. Ergänzung zu nutzen weis. Es ist auch eine Frage der
Organisation und natürlich ist es ein Problem für Leute, die sich mit
Scripts nicht auseinandersetzen wollen oder können.
>> Vgl. auch
>> http://www.cit.gu.edu.au/~anthony/graphics/imagick6/thumbnails/
>
> Da steht, wie convert ein separates Thumbnail erzeugt.
> Das kann meine vorhandene Software, sogar noch eine Ecke bequemer.
> Nein, ich brauche keine Rahmen oder Einblendungen im Thumbnail. <8)
Das ist mir schon klar, es war eher als Hinweis gemeint, was man so alles im
Grafikbereich scripten kann und vielleicht ist das Problem auf irgendeiner
anderen Seite von dort erklärt.
> Also, ich darf Dir versichern: eine 120x160-Version von einem groesseren
> Bild zu erstellen, bekomme ich gerade noch hin. Schnell, bequem und in
> allen moeglichen Varianten. <8)
Genau, deswegen war ich ja etwas über Horst verwundert, weil man das sehr
leicht scripten kann.
> Was man hier braucht (und was Du wahrscheinlich meinst),
ja, ich habe es aber nicht getestet und habe keine Lust dafür extra ein
Testfoto mit Preview zu machen. Ich glaube, ich habe das bei meiner Kamera
sogar irgendwo deaktiviert.
> ist die
> Moeglichkeit, eine vorhandene separate Thumbnail-Datei in den Header
> einer anderen Bilddatei zu uebertragen. Das waere ein workaround, wenn
> auch nicht direkt die nachgefragte Loesung.
Das schaue ich mir an, wenn du mir ein Bild schickst.
> Also nochmal: es ist mit exiftool also moeglich, eine vorliegende Datei
> bild_klein.jpg in den Exif-Header von bild_gross.jpg zu kopieren. Auch
> exiftool kann aber nicht selbstaendig ein neues Thumbnail im Dateiheader
> erzeugen. Ist das so korrekt?
Ich habe es nicht ausprobiert, aber das meint mein Englisch-Lehrer :-)
>> Ich glaube übrigens auch, dass man mit IM das Bild hineinkopieren kann,
Ich habe das mal in der ML gefragt und gebe Bescheid sobald ich eine Antwort
habe.
Man kann zB so ein animiertes Gif machen:
for i in `ls *.png *.jpg *.jpeg *.tif *.tiff`; do
convert -resize "$XRES"x -page +0+0 -quality 40 $i convforanimgif-$i.jpg
done
convert "$NEWNAME"[0] "$NEWNAME" löscht das Vorschaubild
Ich habe mich bis jetzt mit der Syntax "[0]" nicht auseinandergesetzt. Was
ich nicht weiß, wie ich ein 2. Bild an der richtigen Stelle positioniere,
sodass es als Preview erkannt wird. Die Frage ist, ob das per Definition
immer Bild 0 ist. Ich hatte schon einen Fall, wo das nicht so war, aber
vielleicht hatte da auch eine "kaputte" Software gewütet.
identify -verbose macht aber sicher schlauer.
Al
Al Bogner
> Man kann zB so ein animiertes Gif machen:
>
> for i in `ls *.png *.jpg *.jpeg *.tif *.tiff`; do
> convert -resize "$XRES"x -page +0+0 -quality 40 $i convforanimgif-$i.jpg
> done
Da geht natürlich was ab, sorry:
convert -delay 250 -loop 0 convforanimgif-*.jpg animation.gif
Und das wollte ich eigentlich zeigen, dass man bei gif eine Wildcard
verwenden kann.
Das erstellt aber nicht _1_ neue jpg-Datei:
convert *.jpg 2in1pic.jpg
sondern:
2in1pic-0.jpg
2in1pic-1.jpg
Da mußt du wohl warten, bis ich Antwort aus der ML erhalte, wenn du nicht
selber dahinter kommst.
Al
Elmar Baumann
> Was ich suche, ist ein Programm - Kommandozeile oder GUI, Windows -, das
> ein nichtvorhandenes Exif-Thumbnail erzeugt bzw. ein vorhandenes durch
> ein neu erzeugtes ersetzt.
Für solche Zwecke (und viele andere) verwende ich die EXIF-Utils. Willst
du für ein komplettes Verzeichnis alle Thumbnails in den JPEG-Bildern
aktualisieren oder fehlende erzeugen reicht folgender Befehl: 'exifedit
/t a verzeichnisname'. Du kannst natürlich auch statt eines
Verzeichnisses nur eine Datei angeben, z.B. als Parameter in einer
Batch-Datei ([Win]DOS: %1) und dann so per Drag&Drop bearbeiten lassen
(auf Batch ziehen oder Verknüpfung auf Batch ins SendTo dann per
Kontextmenü "Senden an"). Weitere Features (anzuwenden auf Einzeldateien
oder komplette Verzeichnisse) sind, Thumbs zu extrahieren, Thumbs
anderer Dateien einzufügen oder die Größe des Thumbs zu spezifizieren,
z.B. 'exifedit /t a,200x100 datei.jpg' für ein etwas größeres Thumbnail
sowie Thumbnails zu löschen. Lege eine Bilddatei auf einen WWW-Server
oder schicke mir eine per E-Mail, dann kann ich sie konvertieren und du
kannst prüfen, ob die Qualität für dich ok ist.
--
Homepage: http://www.elmar-baumann.de/fotografie/
Gerhard Huber
...
> Was ich suche, ist ein Programm - Kommandozeile oder GUI, Windows -,
> das ein nichtvorhandenes Exif-Thumbnail erzeugt bzw. ein vorhandenes
> durch ein neu erzeugtes ersetzt. Jhead kann vieles, Thumbnails jedoch
> nur loeschen, nicht aber schreiben. Ich wundere mich ehrlich gesagt,
> dass das die einschlaegigen "Universalprogramme" a la
> Irfanview/XnView nicht bieten, bzw. dass selbst Photoshop (hier
> Version 6) beim Speichern nach der Bearbeitung das nun ungueltige
> Vorschaubild in der Datei belaesst und kein neues generiert.
> Nun denn also - gibt es da was geeignetes?
PhotoLine 32 kann das. Einfach in den JPEG-Einstellungen einstellen,
dass Vorschaubilder immer erzeugt werden und per Mehrfachkonvertierung
die Bilder umkopieren. Das besondere daran ist, dass die JPEG-Daten
dabei nicht neu gepackt werden.
Gerhard Huber
--
PhotoLine 32 Shareware Bildbearbeitung für Windows und MacOS
www.pl32.de
Holger Suhr
"Dieter Lefeling" <didis....@web.de> schrieb
> [ EXIF-Thumbnails generieren....]
> Nun denn also - gibt es da was geeignetes?
>
> Dieter
>
Hallo Dieter,
der BreezeBrowser ist hierfür meine Wahl.
Er ist z.B. auch als *einziger*? in der Lage
das Orientation-Flag in den EXIF-Daten zu setzen.
Er ist z.B. auch als *einziger*? in der Lage
Bilder so im Batch umzubenennen, daß Serienbilder
in richtiger Folge mit einbezogen werden.
Gruß Holger
Christian Georg Becker
>>Horst Saak-Winkelmann schrieb
>>Worauf soll der geneigte Leser denn jetzt die Betonung
>>legen?
>>* FixFoto kann Vorschaubilder erzeugen
>>* FixFoto kann fehlerhafte Vorschaubilder erzeugen
>
>
> Fixfoto aktualisiert das Vorschaubild beim Speichern nach
> Bearbeitung und hat wohl auch eine Funktion, um
> nur die Bilder im Batch-Mode zu aktualisieren.
Genau. Und man kann die Größe/Qualität des Vorschaubildes bestimmen.
Krischan
Dieter Lefeling
> der BreezeBrowser ist hierfür meine Wahl.
Ah ja.
> Er ist z.B. auch als *einziger*? in der Lage
> das Orientation-Flag in den EXIF-Daten zu setzen.
Also, das geht m.W. auch mit anderen Programmen.
> Er ist z.B. auch als *einziger*? in der Lage
> Bilder so im Batch umzubenennen, daß Serienbilder
> in richtiger Folge mit einbezogen werden.
Was meinst Du damit?
Dieter
Dieter Lefeling
> PhotoLine 32 kann das. Einfach in den JPEG-Einstellungen einstellen,
> dass Vorschaubilder immer erzeugt werden und per Mehrfachkonvertierung
> die Bilder umkopieren. Das besondere daran ist, dass die JPEG-Daten
> dabei nicht neu gepackt werden.
Das waere also auch ein workaround: man macht eine Pseudo-Konvertierung,
die nur aus einem Umkopieren besteht, und laesst dabei Vorschaubilder
generieren. Muss man hinterher natuerlich wieder alles zurueckkopieren.
Oder gleich die bisherigen Bilder ueberschreiben lassen. Wenn das Bild
nicht neu gepackt wird, waere das eine Alternative.
Dieter
Dieter Lefeling
> Für solche Zwecke (und viele andere) verwende ich die EXIF-Utils.
Hast Du da mal eine Quelle? Braucht man dafuer auch Perl oder einen
anderen Interpreter oder bekommt man das lauffaehig kompiliert?
> Willst du für ein komplettes Verzeichnis alle Thumbnails in den JPEG-Bildern
> aktualisieren oder fehlende erzeugen reicht folgender Befehl: 'exifedit
> /t a verzeichnisname'. Du kannst natürlich auch statt eines
> Verzeichnisses nur eine Datei angeben, z.B. als Parameter in einer
> Batch-Datei ([Win]DOS: %1)
Seit zehn Jahren ist man da etwas flexibler - man kann scripten. <8)
> und dann so per Drag&Drop bearbeiten lassen
> (auf Batch ziehen oder Verknüpfung auf Batch ins SendTo dann per
> Kontextmenü "Senden an").
Ja, das ginge. Nur wird es wieder hampelig, wenn man mehrere Dateien
heraussucht und die Funktion dann nur fuer die aufrufen will. Also quasi
alle Dateien in einer Liste. Ich muss mal kucken, ob man das bei Windows
irgendwie verscripten kann.
> Weitere Features (anzuwenden auf Einzeldateien
> oder komplette Verzeichnisse) sind, Thumbs zu extrahieren, Thumbs
> anderer Dateien einzufügen oder die Größe des Thumbs zu spezifizieren,
> z.B. 'exifedit /t a,200x100 datei.jpg' für ein etwas größeres Thumbnail
> sowie Thumbnails zu löschen. Lege eine Bilddatei auf einen WWW-Server
> oder schicke mir eine per E-Mail, dann kann ich sie konvertieren und du
> kannst prüfen, ob die Qualität für dich ok ist.
Kann ich das evtl. auch selbst ausprobieren oder ist das ein
kommerzielles Programm ohne verfuegbare Testversion?
Dieter
Dieter Lefeling
> Manchmal gibt es leider nur Workarounds. Ich habe mich bei den Exifdaten
> auch daran gewöhnen müssen, dass es besser ist, es irgendwie hinzubekommen
> als gar nicht.
Na ja, deswegen frage ich ja nach einer Loesung, die es "besser" macht.
Fuer Windows gibt es diese Loesung - nur ist sie anscheinend unsauber
programmiert.
> Wir sind uns einig, dass das eigentlich die EBV korrekt machen soll. Es gibt
> ein neues Gimp, vielleicht klappt es damit?
Also, ich kenne Photoshop seit Version 2.5 - da will ich mich eigentlich
nicht umstellen.
> Ich bin aber nicht der Meinung, dass es mit Maus markieren schneller geht,
> als ein Script aufzurufen.
Per Tastatur geht vieles schneller, per Script vieles effektiver und
flexibler als per Mausschubsen. Nur - wenn es um das gezielte Auswaehlen
von Dateien geht, ist Essig. Man kann ja schon froh sein, wenn das Pro-
gramm ueberhaupt nur wildcards unterstuetzt. Eine so nette Moeglichkeit
wie man zu Zeiten von NDOS/4DOS mit "select" hatte, stellt Windows und
offenbar auch Linux heute nicht mehr zur Verfuegung.
> thupd.sh <pfad> oder ähnlich ist sehr schnell getippt, wenn man die
> Tab-Taste zur automat. Ergänzung zu nutzen weis.
Auch das konnte NDOS/4DOS sehr geschickt. Heute kann man froh sein, wenn
man ein Add-on findet, das die cmd.exe direkt im angegebenen Verzeichnis
oeffnet und nicht im immer gleichen Userverzeichnis.
> ja, ich habe es aber nicht getestet und habe keine Lust dafür extra ein
> Testfoto mit Preview zu machen. Ich glaube, ich habe das bei meiner Kamera
> sogar irgendwo deaktiviert.
Also, ich wuesste jetzt keine Kamera, bei der man einstellen kann, ob
und welcher Teil des Exif-Headers wegfaellt oder nicht. Geh mal davon
aus, dass auch bei Deinen Bildern ein Vorschaubild enthalten ist.
> > ist die
> > Moeglichkeit, eine vorhandene separate Thumbnail-Datei in den Header
> > einer anderen Bilddatei zu uebertragen. Das waere ein workaround, wenn
> > auch nicht direkt die nachgefragte Loesung.
>
> Das schaue ich mir an, wenn du mir ein Bild schickst.
Gut, dann kuck ich mal. Ist alles auf dem anderen Rechner. <8)
Was ist mit diesem nospam-Gedoens in Deinen From- und Reply-To-
Adressen?
> > Also nochmal: es ist mit exiftool also moeglich, eine vorliegende Datei
> > bild_klein.jpg in den Exif-Header von bild_gross.jpg zu kopieren. Auch
> > exiftool kann aber nicht selbstaendig ein neues Thumbnail im Dateiheader
> > erzeugen. Ist das so korrekt?
>
> Ich habe es nicht ausprobiert, aber das meint mein Englisch-Lehrer :-)
Bliebe das Gehampel mit Perl.
> Man kann zB so ein animiertes Gif machen:
>
> for i in `ls *.png *.jpg *.jpeg *.tif *.tiff`; do
> convert -resize "$XRES"x -page +0+0 -quality 40 $i convforanimgif-$i.jpg
> done
Nun ja, GIF ist was ganz anderes als Jpeg. Es muss ja nicht nur das Bild
in den Header (!) geschrieben werden, sondern auch diverse Zeiger
angepasst werden.
Dieter
Dieter Lefeling
> Hast Du da mal eine Quelle? Braucht man dafuer auch Perl oder einen
> anderen Interpreter oder bekommt man das lauffaehig kompiliert?
Huch, das war ja einfach. <8) Ich hab's vorhin problemlos gefunden.
Die Testversion ist zwar eingeschraenkt, sollte aber erstmal reichen.
Ich probiere dann mal ein bisschen damit herum.
Dieter
Horst Saak-Winkelmann
<didis....@web.de> :
...
>Nun denn also - gibt es da was geeignetes?
...
Vielleicht findet sich ja auch jemand der ein 8BF-PlugIn dafür
schreiben kann?
Ich hätte da auch noch ein paar nützliche und lukrative Ideen :-)
Gruß, Horst
--
Al Bogner
> Per Tastatur geht vieles schneller, per Script vieles effektiver und
> flexibler als per Mausschubsen. Nur - wenn es um das gezielte Auswaehlen
> von Dateien geht, ist Essig.
Kommt darauf an. Vielleicht lasst sich ein Kriterium finden, was du
auswählst und überlässt das dann dem Script. So auf die schnelle fällt mir
ein, mache einen Ordner und verlinke dort per Maus die Dateien hinein, die
du bearbeiten willst. SO bereite ich bei mir das Brennen per Script vor.
> Man kann ja schon froh sein, wenn das Pro-
> gramm ueberhaupt nur wildcards unterstuetzt. Eine so nette Moeglichkeit
> wie man zu Zeiten von NDOS/4DOS mit "select" hatte, stellt Windows und
> offenbar auch Linux heute nicht mehr zur Verfuegung.
Kenne ich nicht oder habe ich vergessen. Kannst du das näher beschreiben,
was du da konntest?
>> thupd.sh <pfad> oder ähnlich ist sehr schnell getippt, wenn man die
>> Tab-Taste zur automat. Ergänzung zu nutzen weis.
>
> Auch das konnte NDOS/4DOS sehr geschickt. Heute kann man froh sein, wenn
> man ein Add-on findet, das die cmd.exe direkt im angegebenen Verzeichnis
> oeffnet und nicht im immer gleichen Userverzeichnis.
Ich verwende im Script Variablen mit absoluten Pfaden.
>> ja, ich habe es aber nicht getestet und habe keine Lust dafür extra ein
>> Testfoto mit Preview zu machen. Ich glaube, ich habe das bei meiner
>> Kamera sogar irgendwo deaktiviert.
>
> Also, ich wuesste jetzt keine Kamera, bei der man einstellen kann, ob
> und welcher Teil des Exif-Headers wegfaellt oder nicht. Geh mal davon
> aus, dass auch bei Deinen Bildern ein Vorschaubild enthalten ist.
Ich glaube, dass die FZ20 kein Vorschaubild erzeugt, zumindest konnte ich
diese nicht analysieren, ebenso die Caplio R1. Ich lasse mich da aber gerne
belehren. Siehe anderes Posting von mir mit meinen Tests. Ganz geschafft
habe ich es aber noch nicht.
> Gut, dann kuck ich mal. Ist alles auf dem anderen Rechner. <8)
> Was ist mit diesem nospam-Gedoens in Deinen From- und Reply-To-
> Adressen?
LOL. Meine beiden Adressen sind gültig und produzieren nur dann Fehler, wenn
der Server down ist. Verwende meine Reply-Adresse so wie sie ist. Mails and
die "From-Adresse" werden automatisch entsorgt.
> Bliebe das Gehampel mit Perl.
Nicht unter Linux :-)
>> Man kann zB so ein animiertes Gif machen:
>>
>> for i in `ls *.png *.jpg *.jpeg *.tif *.tiff`; do
>> convert -resize "$XRES"x -page +0+0 -quality 40 $i convforanimgif-$i.jpg
>> done
>
> Nun ja, GIF ist was ganz anderes als Jpeg. Es muss ja nicht nur das Bild
> in den Header (!) geschrieben werden, sondern auch diverse Zeiger
> angepasst werden.
Zur Zeit sind Feiertage, auch in Australien und Anthony schreibt zur Zeit
nicht. Ich warte auf eine Antwort in der ML. Es gibt da aber Hinweise zu
IM, die ich nicht umsetzen kann.
http://scri8e.com/IM_Tutor/my_IM_tutes/1Preview/ zeigt leider nicht die
Lösung, ist aber trotzdem ganz interessant. Da kann man automatisch
Variationen von Bildern erstellen. Siehe auch
http://www.imagemagick.org/script/command-line-options.php#preview
http://www.imagemagick.org/script/command-line-options.php#adjoin scheint
auch nicht die Lösung zu sein. Ich glaube noch immer, dass die Syntax
irgendwie mit [] zu schreiben ist. Bei den vielen Optionen ist es manchmal
nicht leicht die einfachsten Dinge zu finden. Vermutlich ist da irgendwo
was übergreifend bei IM erklärt und man findet es bei convert nicht. Ich
vermisse die alte Manpage von IM.
Al
Al Bogner
> Also nochmal: es ist mit exiftool also moeglich, eine vorliegende Datei
> bild_klein.jpg in den Exif-Header von bild_gross.jpg zu kopieren.
http://www.cpanforum.com/posts/1458
exiftool '-previewimage<=preview.jpg' dst.jpg
Note that you can only add a preview image to an image where the maker notes
support it.
exiftool '-previewimage<=pv_small.jpg' test.jpg
0 image files updated
1 image files unchanged
Es sieht so aus, dass meine aktuellen Kameras dies bei den Makernotes nicht
unterstützen.
Da habe ich doch noch ein Bild von einer Z2 gefunden:
exiftool '-previewimage<=pv_small.jpg' test.jpg
1 image files updated
Das passt aber noch nicht. Ich vermute, dass pv_small.jpg nicht die
richtigen Eigenschaften hat oder es mit dem Z2-File doch nicht möglich ist.
Mal sehen, was der Autor von Exiftool dazu sagt.
Dieter, ich warte auf ein Bild zum Testen.
Al
Martin Herrmann
> Eigentlich geht es darum, in einem Schritt direkt ein neues Thumbnail im
> Dateiheader zu erzeugen. Okay, man kann das scripten. Nur - zehn Dateien
> in einer Uebersicht zu markieren und dann "bei diesen bitte mal eben das
> Thumbnail updaten", also schnell, einfach und effektiv, das geht damit
> eben nicht. Genau das leistet Exifer - nur eben fehlerhaft.
Hallo Dieter,
Mapivi (http://mapivi.de.vu) kann das, einfach die gewünschten Bilder
selektieren und im Kontext-Menü "EXIF info"->"(re)build thumbnail"
aufrufen.
Mapivi gereniert dann für jedes Bild ein max 160 Pixel großes Thumbnail
(mittels ImageMagick: convert -size 160x160 -geometry 160x160 -quality 75
-sharpen 0.4 -filter Lanczos) und schreibt es in die EXIF Daten.
Auf Wunsch kann man mit Mapivi auch EXIF Thumbnails aus anderen Bilder
kopieren und entfernen.
Mapivi ist Open Source, kostenlos und läuft unter Windows, Linux und MacOS.
Gruß
Martin
Dieter Lefeling
> http://www.cpanforum.com/posts/1458
> exiftool '-previewimage<=preview.jpg' dst.jpg
> Note that you can only add a preview image to an image where the maker notes
> support it.
?!? - das Thumbnail ist doch Teil der Exif-Spezifikation.
> Es sieht so aus, dass meine aktuellen Kameras dies bei den Makernotes nicht
> unterstützen.
Wuerde mich sehr wundern. Es gibt doch Tools zum Extrahieren solcher
Thumbnails, so dass die in einer separaten .jpg-Datei abgelegt werden.
Kuck doch damit mal rein. Oder nimm einfach jhead und sieh Dir an, was
das Programm beim Entfernen eines Thumbnails aus der Bilddatei so macht.
Oder lies einfach direkt die Exif-Daten. Da gibt es Eintraege wie
"Thumbnail-offset" und "Thumbnail-length", mit denen die Position und
Groesse des Vorschaubilds angegeben ist.
> Dieter, ich warte auf ein Bild zum Testen.
Du hast Post.
Dieter
Al Bogner
> Da habe ich doch noch ein Bild von einer Z2 gefunden:
>
> exiftool '-previewimage<=pv_small.jpg' test.jpg
> 1 image files updated
>
> Das passt aber noch nicht.
Der Exiftool-Autor hat mir mittlerweile geantwortet und mit meinen
Test-Dateien am Mac getestet. Er schrieb mir, dass bei ihm das geänderte
Vorschaubild sichtbar ist.
Ich kann das aber nicht bestätigen. Vielleicht ist da eine Einstellung im
Dateimanager mitverantwortlich was angezeigt wird?
Ursprünglich:
exiftool test.jpg -previewimage
Preview Image : (Binary data 32004 bytes, use -b option to
extract)
Nach Änderung:
exiftool test.jpg -previewimage
Preview Image : (Binary data 37581 bytes, use -b option to
extract)
Demnach müsste da schon etwas passiert sein, Ob da eventuell ein Cache in
die Irre führt? Ich habe extra den Rechner neu gestartet, das hat aber
nichts geändert.
Al
Al Bogner
> Geh mal davon
> aus, dass auch bei Deinen Bildern ein Vorschaubild enthalten ist.
Lt. exiftool erzeugt die FZ20 und Caplio R1 keine Vorschaubilder hier.
Von einer Z2 sieht es so aus:
exiftool test.jpg -previewimage
Preview Image : (Binary data 32004 bytes, use -b option to
extract)
Al
Al Bogner
> Mapivi gereniert dann für jedes Bild ein max 160 Pixel großes Thumbnail
> (mittels ImageMagick: convert -size 160x160 -geometry 160x160 -quality 75
> -sharpen 0.4 -filter Lanczos) und schreibt es in die EXIF Daten.
Wie? Der Teil mit IM zur Erstellung des Preview-Bildes ist klar.
> Auf Wunsch kann man mit Mapivi auch EXIF Thumbnails aus anderen Bilder
> kopieren und entfernen.
> Mapivi ist Open Source, kostenlos und läuft unter Windows, Linux und
> MacOS.
Ich könnte es ja wieder mal probieren, ob ich die Installation unter Linux
schaffe :-)
Al
Al Bogner
> Du hast Post.
Du auch, mit dem gewünschten Ergebnis, allerdings von meinem Z2-Bild.
Ich habe fälschlicherweise angenommen, dass das Preview-Image des Fotos von
Konqueror für die Vorschau verwendet wird, das ist falsch.
So liest man übrigens das Preview-Bild mit Exiftool aus:
exiftool test.jpg -previewimage -b >preview.jpg
Jetzt gilt es nur mehr herauszufinden, warum Exiftool mit deinem Foto nichts
anfangen kann. Es wird wohl schon mit den Makernotes zusammenhängen. Mail
an den Exiftool-Autor ist unterwegs.
Al
Uwe Schröder
> Bei der Erstellung der EXIF-Spezifikation wurde seinerzeit eine
> Größe des Vorschaubildchens von nur 120x160 Pixel vorgesehen.
Wo steht das? Ich kenne nur die Einschränkung, daß ein Vorschaubild
nicht größer als 64KB sein darf, damit es komplett in einen Block paßt.
Mag sein, daß DCF 160×120 fordert, aber DCF beschreibt nur die
Datenstruktur auf der Speicherkarte für den Austausch zwischen Kamera,
Print-Terminals usw. Im Prinzip hat man diesen Standard ja schon
verlassen, sobald man das Bild aus dem DCIM-Verzeichnis herausbewegt.
> Dem gegenüber können nahezu alle Bildbrowser (auch der
> Windows-Explorer) auf Wunsch auch mit größeren Bildern arbeiten,
> was bei den heutigen Monitorgrößen auch nicht verkehrt ist. In
> diesem Fall muss ohnehin das Thumbnail aus dem eigentlichen Bild
> erzeugt werden, was bei der Leistungsfähigkeit moderner PCs auch
> nicht mehr so viel Zeit kostet.
Es nervt trotzdem. Fünf Bildbetrachter, fünf unterschiedliche
Speicherorte für Thumbnails. (Windows-Explorer: thumbs.db, Exifer:
EXIF-Thumbnail, Paintshop Pro: PSPBRWSE.JBF, Faststone: FSViewer.db,
IrfanView: Speichert gar nicht, sondern generiert sie ständig neu -
was Photoshop, ACDsee usw. machen, weiß ich nicht einmal.) Das sind
auf eine ganze Festplatte bezogen schon mehrere hundert MB, die da
unnütz doppelt und dreifach herumliegen.
usch
Uwe Schröder
> Bleibt noch Exifer. Das Programm bietet genau eine solche Funktion
> (Vorschaubild erzeugen), aber diese Funktion arbeitet fehlerhaft und die
> Thumbnails sind Grotte (mitunter erhebliche Moiree-Effekte, die das Bild
> nur noch erahnen lassen).
Gibt es eigentlich Informationen, warum das Programm trotz diverser
bekannter Bugs seit 2002 nicht mehr gepflegt wird? Ich hab mir schon
Sorgen gemacht, ob dem Programmierer vielleicht irgendwas zugestoßen
ist, aber andererseits bezahlt ja jemand die laufenden Kosten für
Domains und Homepage, obwohl die auch schon ewig nicht mehr
aktualisiert worden sind :-|
usch
Al Bogner
> Es nervt trotzdem. Fünf Bildbetrachter, fünf unterschiedliche
> Speicherorte für Thumbnails. (Windows-Explorer: thumbs.db, Exifer:
> EXIF-Thumbnail, Paintshop Pro: PSPBRWSE.JBF, Faststone: FSViewer.db,
> IrfanView: Speichert gar nicht, sondern generiert sie ständig neu -
> was Photoshop, ACDsee usw. machen, weiß ich nicht einmal.) Das sind
> auf eine ganze Festplatte bezogen schon mehrere hundert MB, die da
> unnütz doppelt und dreifach herumliegen.
Da hast du schon recht. Unter Linux kenne ich zwar nur .thumbnails, aber
auch dieses Verzeichnis wurde hier schon 1GB groß und ich habe mich das 1.
Mal gewundert, was da alles in meinem Home-Directory rumschwirrt.
Mittlerweile entsorge ich alle Vorschaubilder regelmäßig beim Sichern. Die
Zeit für das Neuerstellen hält sich in Grenzen.
Ich denke aber unter Linux kann man da einiges konfigurieren, zB beim
Konqueror ab welcher Größe ein Vorschaubild erstellt werden soll. Ich will
auch von 40MB-Tiffs einen Thumbnail haben und das musste ich erst
freigeben.
Al
Dieter Lefeling
> Kommt darauf an. Vielleicht lasst sich ein Kriterium finden, was du
> auswählst und überlässt das dann dem Script.
Das wird schwierig, wenn das Kriterium "alle Bilder, die ich bearbeiten
will" heisst. <8)
> So auf die schnelle fällt mir
> ein, mache einen Ordner und verlinke dort per Maus die Dateien hinein, die
> du bearbeiten willst. SO bereite ich bei mir das Brennen per Script vor.
So habe ich das zu DOS-Zeiten auch machen muessen.
> > Man kann ja schon froh sein, wenn das Pro-
> > gramm ueberhaupt nur wildcards unterstuetzt. Eine so nette Moeglichkeit
> > wie man zu Zeiten von NDOS/4DOS mit "select" hatte, stellt Windows und
> > offenbar auch Linux heute nicht mehr zur Verfuegung.
>
> Kenne ich nicht oder habe ich vergessen. Kannst du das näher beschreiben,
> was du da konntest?
Im Prinzip alles. <8) Mit select ist es moeglich, fast jeden Befehl nur
fuer einzelne, ausgewaehlte Dateien auszufuehren. Man gibt an, welche
Dateien man grundsaetzlich zur Auswahl will (bereits dabei geht weit
mehr als nur die Jokerzeichen "*" und "?") und bekommt dann eine bild-
schirmfuellende, scrollbare Liste mit allen diesen Dateien. Etwa alle
Jpegs und alle Tiffs mit "2005" im Namen, sogar sortiert nach Wunsch.
Tja - und dann kann man einfach markieren, welche bearbeitet werden
sollen und welche nicht. Nach der Auswahl wird der vorher spezifizierte
Befehl dann nur auf die gewaehlten Dateien angewandt.
Das gleiche gibt's BTW auch umgekehrt mit dem Befehl "except".
Aehnliches konnte auch schon DR-DOS, bei dem in vielen Befehle die
Option "@" zur Verfuegung stand. Darin konnte man einen Datei angeben,
in der alle abzuarbeitenden Dateinamen standen. Diese Liste liess sich
ueber den tree-Befehl bequem erzeugen und ggf. nachbearbeiten. Wenn man
nicht gleich auf ein leistungsfaehigeres Werkzeug wie "target" zurueck-
griff, das noch viel mehr konnte.
Ja, es gab schon nette Sachen. <8)
> Ich verwende im Script Variablen mit absoluten Pfaden.
So handhabt der XP-Explorer das bei der Uebergabe an ein Script oder an
eine Batchdatei ebenfalls.
> Ich glaube, dass die FZ20 kein Vorschaubild erzeugt, zumindest konnte ich
> diese nicht analysieren, ebenso die Caplio R1.
Okay, das ist ja nun inzwischen widerlegt.
> ...zeigt leider nicht die Lösung, ist aber trotzdem ganz interessant.
>
> ... scheint auch nicht die Lösung zu sein.
> Ich glaube noch immer, dass die Syntax
> irgendwie mit [] zu schreiben ist. Bei den vielen Optionen ist es manchmal
> nicht leicht die einfachsten Dinge zu finden. Vermutlich ist da irgendwo
> was übergreifend bei IM erklärt und man findet es bei convert nicht. Ich
> vermisse die alte Manpage von IM.
Ich vermisse eher ein "refresh thumbnail" im Kontextmenue. <8)
Dieter
Al Bogner
> Das wird schwierig, wenn das Kriterium "alle Bilder, die ich bearbeiten
> will" heisst. <8)
Hmmh, ich denke, das lässt sich konkretisieren.
Ich sehe zB keine Grund, wenn man das schon will, bei einem Bild das
Preview-Image zu aktualisieren und beim anderen nicht.
> Im Prinzip alles. <8) Mit select ist es moeglich, fast jeden Befehl nur
> fuer einzelne, ausgewaehlte Dateien auszufuehren. Man gibt an, welche
> Dateien man grundsaetzlich zur Auswahl will (bereits dabei geht weit
> mehr als nur die Jokerzeichen "*" und "?") und bekommt dann eine bild-
> schirmfuellende, scrollbare Liste mit allen diesen Dateien. Etwa alle
> Jpegs und alle Tiffs mit "2005" im Namen, sogar sortiert nach Wunsch.
Bis hierher kann ich unter Linux mithalten, dafür braucht es nicht mal
regexp.
> Tja - und dann kann man einfach markieren, welche bearbeitet werden
> sollen und welche nicht. Nach der Auswahl wird der vorher spezifizierte
> Befehl dann nur auf die gewaehlten Dateien angewandt.
Hier muss ich passen. Sowas habe ich noch nie gebraucht. Aber vielleicht
geht das mit mc, das/den verwende ich aber nicht. Ein schneller Blick meint
aber, das könnte funktionieren.
Al
Elmar Baumann
> Huch, das war ja einfach. <8) Ich hab's vorhin problemlos gefunden.
> Die Testversion ist zwar eingeschraenkt, sollte aber erstmal reichen.
> Ich probiere dann mal ein bisschen damit herum.
Mich würde das Ergebnis interessieren. Zur Batchdatei: Das mit %1 war
nur ein Beispiel. Ich habe früh (1994) mit DOS aufgehört und bin auf
Linux umgestiegen. Aber ich weiß noch, dass es auch unter DOS einen
SHIFT-Befehl gibt, der Argumente "nach links verschiebt". In einer
Schleife angewandt sollten sich so variable Argumentanzahlen realisieren
lassen, sprich, man wählt (markiert) beliebig viele Dateien und wirft
sie auf die Verknüpfung zur Batch-Datei bzw. schickt sie mit "Senden an"
an sie. Pseudocode in der Batch-Datei (wenn ich mich nicht irre, ist es
sinnvoll vorher unter DOS den Speicher für die Länge der Kommandozeile
deutlich zu erhöhen):
exifedit /t a %1
while shift
exifedit /t a %1
(Der DOS-Batch-Code würde mich auch interessieren)
--
Homepage: http://www.elmar-baumann.de/fotografie/
Martin Herrmann
>> Mapivi gereniert dann für jedes Bild ein max 160 Pixel großes Thumbnail
>> (mittels ImageMagick: convert -size 160x160 -geometry 160x160 -quality 75
>> -sharpen 0.4 -filter Lanczos) und schreibt es in die EXIF Daten.
>
> Wie? Der Teil mit IM zur Erstellung des Preview-Bildes ist klar.
Mittels des Perl Modules Image::MetaData::JPEG.
> Ich könnte es ja wieder mal probieren, ob ich die Installation unter Linux
> schaffe :-)
Nur Mut, viele andere haben es auch geschafft. :)
Falls Probleme auftreten -> PM.
Gruß
Martin
Al Bogner
> Ursprünglich:
> exiftool test.jpg -previewimage
> Preview Image : (Binary data 32004 bytes, use -b option
> to extract)
>
> Nach Änderung:
> exiftool test.jpg -previewimage
> Preview Image : (Binary data 37581 bytes, use -b option
> to extract)
>
> Demnach müsste da schon etwas passiert sein, Ob da eventuell ein Cache in
> die Irre führt?
Man darf nicht annehmen, dass das Preview-Image vom Dateimanager genutzt
wird. Es gibt kaum Programme, die das Preview-Image nutzen können.
Ebenso entspricht ein "kleines Bild im Bild" nicht unbedingt immer den
Kriterien eines "Preview Images". Die "kleinen Bilder" von Canon, Ricoh und
Panasonic-Kameras, die _ich_ kenne, sind keine "Preview Images", die sich
durch entsprechende Makernotes definieren.
Unter Linux fand ich nur die Möglichkeit das "kleine Bild" mit jhead zu
extrahieren. Wenn es ein "echtes preview-image" ist, dann kann man auch
exiftool verwenden.
Ich zitiere, was mir der Autor von Exiftool geschickt hat:
"The canon.jpg file you sent has a thumbnail image, not a preview.
jhead doesn't know about preview images."
Al
Al Bogner
>> Ich könnte es ja wieder mal probieren, ob ich die Installation unter
>> Linux schaffe :-)
>
> Nur Mut, viele andere haben es auch geschafft. :)
> Falls Probleme auftreten -> PM.
Liest du die hier genannte Antwortadresse?
Wenn man Debian Sid verwendet, dann hat man ja den "Bösewicht" gepachtet und
darf sich nicht wundern, wenn etwas nicht funktioniert. Mich würde es
interessieren dein Programm mal live zu testen, aber aus jetziger Sicht
geht mir mit meinem eigenen Script nichts ab.
Danke für das Angebot des PM.
Al
Uwe Schröder
> Man darf nicht annehmen, dass das Preview-Image vom Dateimanager genutzt
> wird. Es gibt kaum Programme, die das Preview-Image nutzen können.
In der Dokumentation von Exif 2.1 (1998-06-12) kommt die Bezeichnung
"preview image" auch kein einziges Mal vor, da ist durchgängig von
"thumbnail" die Rede.
| 2.3. Definition of Glossary
| The original image is called the "primary image," and small images
| used to index the primary images are called "thumbnail" images,
> Ich zitiere, was mir der Autor von Exiftool geschickt hat:
> "The canon.jpg file you sent has a thumbnail image, not a preview.
> jhead doesn't know about preview images."
Ohne jetzt auch nur eine Idee zu haben, was ein "preview image" im
Gegensatz zu einem "thumbnail" sein soll, würde ich vorschlagen, dann
halt "exiftool -ThumbnailImage" statt "exiftool -PreviewImage" zu
benutzen...
usch
Uwe Schröder
> man wählt (markiert) beliebig viele Dateien und wirft
> sie auf die Verknüpfung zur Batch-Datei
Wie es in der NT-Welt ist, weiß ich nicht, unter W98 werden dabei
jedenfalls nur die 8.3-Aliasnamen übergeben. Wenn das aufgerufene
Programm den Parameter benutzt, um eine neue Datei anzulegen, hat man
dann ein Problem.
> wenn ich mich nicht irre, ist es sinnvoll vorher unter DOS den
> Speicher für die Länge der Kommandozeile deutlich zu erhöhen
Hm... kriegt man die länger als 128 Zeichen? Muß ich doch glatt mal
nachschauen. Ansonsten ist nämlich bei drei oder vier Dateien Schluß,
je nach Verzeichnistiefe.
> exifedit /t a %1
> while shift
> exifedit /t a %1
>
> (Der DOS-Batch-Code würde mich auch interessieren)
Irgenwas in der Art:
:LOOP
IF "%1" == "" GOTO ENDE
DINGSBUMS %1
SHIFT
GOTO LOOP
:ENDE
usch
Al Bogner
>> Ich zitiere, was mir der Autor von Exiftool geschickt hat:
>> "The canon.jpg file you sent has a thumbnail image, not a preview.
>> jhead doesn't know about preview images."
>
> Ohne jetzt auch nur eine Idee zu haben, was ein "preview image" im
> Gegensatz zu einem "thumbnail" sein soll, würde ich vorschlagen, dann
> halt "exiftool -ThumbnailImage" statt "exiftool -PreviewImage" zu
> benutzen...
Ich verstehe es auch nicht und für _mich_ ergibt sich bis jetzt kein
wesentlicher Nutzen von diesen "kleinen Dateien" am PC. Es mag vielleicht
bei Betrachtung am Kamera-Display Sinn machen und bei kleinen Festplatten
bzw. alten PCs mit Spezialprogrammen.
Al
Uwe Schröder
> Ich verstehe es auch nicht und für _mich_ ergibt sich bis jetzt
> kein wesentlicher Nutzen von diesen "kleinen Dateien" am PC.
Was meinst du mit "kleine Dateien"? Ich finde es halt sinnvoll, alle
zusammengehörenden Informationen auch zusammen zu speichern. Und da
gehört eben ein Thumbnail ebenso direkt als Meta-Daten in die
Originaldatei hinein wie Bildtitel, Aufnahmedatum,
Aufnahmebedingungen, Keywords usw.
> Es mag vielleicht bei Betrachtung am Kamera-Display Sinn machen und
> bei kleinen Festplatten bzw. alten PCs mit Spezialprogrammen.
Der Löwenanteil meines täglichen inkrementellen Backups entfällt auf
die Datei FSViewer.db. Jedes Mal, wenn sich auch nur ein einziges Bild
geändert hat, müssen wieder die kompletten 200 MB Thumbnail-Cache am
Stück gesichert werden. :-/ Ähnliches gilt (wenn auch in geringerem
Maße, weil es da eine Cache-Datei pro Verzeichnis gibt statt einer
einzigen Riesen-Datei für alles) für die PSPBRWSE.JBF und die
thumbs.db. Das könnte man sich alles völlig sparen, wenn die Programme
einfach die eingebetteten Thumbnails aus den Bilddateien verwenden würde.
usch
Dieter Lefeling
> Mich würde das Ergebnis interessieren.
Nun denn:
Exifedit schreibt erstmal problemlos neue Thumbnails in die Datei.
Seltsamerweise wollte der Befehl a ohne weitere Parameter nicht das
gewuenschte tun, mit /t a,160 (eigentlich synonym zu /t a) ging es dann
aber.
Nur... das Ergebnis ist genauso uebel wie vorher mit Exifer. Moeglicher-
weise verwenden beide Programme sogar die gleiche jpeg-Bibliothek. Was
dort an Thumbnail generiert wird, ist mitunter kaum noch als Bild zu
bezeichnen. Das Ergebnis sieht so aus wie per bilinearer Interpolation
oder noch darunter (falls das moeglich ist). Also: keine Verbesserung,
nur mehr Aufwand.
Immerhin kann man dem Programm aber ein externes Thumbnail vorsetzen,
das es dann einbinden soll (/t a,@dateiname.thumb). Gibt man exifedit
also mal ein ordentliches, per Lanczos-Methode erstelltes Thumbnail vor,
wird das Ergebnis dann tatsaechlich so, wie es soll.
> Zur Batchdatei: Das mit %1 war
> nur ein Beispiel. Ich habe früh (1994) mit DOS aufgehört und bin auf
> Linux umgestiegen.
Das merkt man. <8) Seit gut 10 Jahren (mit Windows 95) braucht man
solche Kruecken nicht mehr, denn es gibt serienmaessig den Windows
Scripting Host mit einer sehr umfangreichen und maechtigen Script-
sprache, die nicht nur den Zugriff auf Betriebssystem ermoeglicht.
> Aber ich weiß noch, dass es auch unter DOS einen
> SHIFT-Befehl gibt, der Argumente "nach links verschiebt".
Ja, so hat man sich damals behelfen muessen. Das ist aber ungefaehr so
aktuell wie "mit 16 MB RAM bist Du der Koenig". <8)
> ...
> exifedit /t a %1
> while shift
> exifedit /t a %1
>
> (Der DOS-Batch-Code würde mich auch interessieren)
Als Batch sah das schon ein bisschen anders aus (Schleifenkonstrukte
gibt es da nicht, shift verschiebt einfach nur die Parameter). Aber das
ist hier eh obsolet, denn es gibt ja wie gesagt den WSH. Da sieht der
Zugriff auf die Befehlszeile schon etwas anders aus. Es gibt das Objekt
Wscript (das Script selbst) mit den noetigen Methoden und Eigenschaften:
Argumentanzahl = WScript.Arguments.Count
greift direkt auf die Anzahl der Parameter zu. "Arguments" enthaelt
neben der Eigenschaft Count auch ein Array mit den Parametern, auf das
direkt zugegriffen werden kann. Etwa ganz elegant ueber "each in":
For Each Arg in WScript.Arguments
WScript.Echo "Argument: " & Arg
Next
oder ganz klassisch ueber Zaehlschleife
For i=1 to Argumentanzahl
WScript.Echo "Parameter " & i & " ist " & WScript.Arguments(i-1)
Next
Tatsaechlich ist es moeglich, mehrere markierte Dateien als Parameter an
eine Anwendung bzw. ein Script zu uebergeben. Jede Datei wird dabei mit
ihrem vollen absoluten Pfadnamen uebergeben. Die maximal noch moegliche
Laenge habe ich jetzt nicht im Kopf, aber 20 Dateien "gingen" noch. Das
reicht mir erstmal. Selbstredend wird jeweils der volle Dateiname und
nicht etwa die 8+3-Kurzform uebergeben. Fuer komplette Verzeichnise kann
man einfach pruefen, ob der Parameter ein Verzeichnis ist (bequem ueber
die FolderExists-Methode des FileSystemObject) und alle jpeg-Dateien
darin abarbeiten.
Ich habe mal ein kleines Script gebastelt, das exifedit fuer jede Datei
aufruft und ein neues Thumbnail schreibt. Dessen Qualitaet ist wie
gesagt bescheiden. Mit manuell generierten Thumbnails ging es aber.
Jetzt muesste ggf. noch ein Kommandozeilentool a la convert dazukommen,
das ein qualitativ ordentliches Thumbnail generiert. Dann liesse sich
das alles in einem Rutsch machen. Ein bisschen hampelig wird die Sache
nur dadurch, dass das Thumbnail im gleichen Verzeichnis wie die zu
aktualisierende Datei liegen muss - da muss man also etwas mit den
Pfaden aufpassen. "Im Prinzip" funktioniert das aber.
Gibt es convert irgendwo ggf. einzeln zu finden, also ohne das komplette
ImageMagick-Paket? Oder eine Alternative?
Dieter
Uwe Schröder
> Ja, so hat man sich damals behelfen muessen. Das ist aber ungefaehr so
> aktuell wie "mit 16 MB RAM bist Du der Koenig". <8)
16 MEGAbyte? Ach komm, ich erinnere mich an Zeiten, wo 16 KILObyte
normal und 32 KB das Maximum dessen waren, was das Betriebssystem
verwalten konnte, und man für 64 KB schon Tricks wie Speicherbank-
Umschaltung in Assembler machen mußte :-)
> es gibt ja wie gesagt den WSH
Würg. Hab ich mich nie mit beschäftigt, das sieht mir zu sehr nach
Visual Basic aus. Da schreib ich lieber gleich ein kleines Executable
in C++ ;)
usch
Al Bogner
>> Ich verstehe es auch nicht und für _mich_ ergibt sich bis jetzt
>> kein wesentlicher Nutzen von diesen "kleinen Dateien" am PC.
>
> Was meinst du mit "kleine Dateien"?
Sollte eigentlich "kleine Bilder" heißen, die dann auch kleine Dateien
sind :-)
Ich habe jetzt da nicht viel Lust an der Bezeichnung rumzureiten, Preview,
Thumbnail oder was immer du willst. Einen wesentlichen Unterschied dürfte
es aber geben, sonst würde Exiftool mit allen "kleinen" Bildern klar
kommen.
> Ich finde es halt sinnvoll, alle
> zusammengehörenden Informationen auch zusammen zu speichern.
ACK
> Und da
> gehört eben ein Thumbnail ebenso direkt als Meta-Daten in die
> Originaldatei hinein wie Bildtitel, Aufnahmedatum,
> Aufnahmebedingungen, Keywords usw.
Mag sein, aber wenn der Großteil der Programme dies nicht nützt, was bringt
es dann?
> Der Löwenanteil meines täglichen inkrementellen Backups entfällt auf
> die Datei FSViewer.db.
Kenne ich nicht, aber so wie sich das liest, wird die Datei automatisch
erstellt. Was passiert, wenn du sie löscht? Wird sie automatisch neu
angelegt? So ist das zumindest mit digikam. In diesem Fall lohnt sich
sichern nicht. Also einfach ausklammern.
> Jedes Mal, wenn sich auch nur ein einziges Bild
> geändert hat, müssen wieder die kompletten 200 MB Thumbnail-Cache am
> Stück gesichert werden. :-/
Bessere Sicherungssoftware verwenden, wenn man da nicht ausklammern kann.
Mein Sicherungsscript für die Fotos macht nach einigen Ergänzungen gerade
einen Testlauf. Da werden die Fotos aber einzeln auch symmetrisch mit gpg
verschlüsselt, sodass ich bei Bedarf die DVDs problemlos entsorgen kann und
natürlich ist auch ein automatisches Entschlüsseln möglich. Die
Sicherheitsstufe ist wegen des PW sehr gering, aber wer sich die Mühe macht
das zu knacken, darf die Bilder auch sehen :-) $Bekannter, den die Bilder
interessieren könnten, wird dazu aber eher nicht in der Lage sein.
Die Haltbarkeit der DVD spielt nicht die Rolle, da ja von Zeit zu Zeit neue
Komplett-Sicherungen auf DVD erstellt werden. Zwischendurch wird auf
diverse HDs im Netzwerk gesichert.
> Ähnliches gilt (wenn auch in geringerem
> Maße, weil es da eine Cache-Datei pro Verzeichnis gibt statt einer
> einzigen Riesen-Datei für alles) für die PSPBRWSE.JBF und die
> thumbs.db. Das könnte man sich alles völlig sparen, wenn die Programme
> einfach die eingebetteten Thumbnails aus den Bilddateien verwenden würde.
Siehe oben, einfach ausklammern. Alles was sich automatisch wieder erstellen
läßt, braucht IMHO nicht gesichert werden. Im Chaos-Fall ist die Zeit dann
auch egal, die zum Erstellen von Hilfsdateien benötigt wird. Vor einer
Sicherung lösche ich sogar per Script automatisch bestimmte Dinge wie
Cache-Verzeichnisse, Thumbnails, Cookies etc.
Mein Script erstellt auch Varianten der bearbeiteten Bilder für Beamer, TV,
Handy, etc. Da hätte ich viel zu sichern. Letztlich habe ich alle Bilder
mit Variationen neu berechnen lassen und das hat 3 Tage gedauert, aber das
mache ich sicher so schnell nicht wieder. Bei Multitasking unter Linux,
merkt man das bei "normalen" Arbeiten gar nicht. Da ist der CPU endlich
nicht mehr langweilig. :-)
Übrigens, es gibt neben ImageMagick auch http://netpbm.sourceforge.net/ und
http://www.boutell.com/gd/
Ich verwende das aber nicht.
Al
Hans Wein
> Nur... das Ergebnis ist genauso uebel wie vorher mit Exifer.
> Moeglicher- weise verwenden beide Programme sogar die gleiche
> jpeg-Bibliothek. Was dort an Thumbnail generiert wird, ist mitunter
> kaum noch als Bild zu bezeichnen. Das Ergebnis sieht so aus wie per
> bilinearer Interpolation oder noch darunter (falls das moeglich
> ist). Also: keine Verbesserung, nur mehr Aufwand.
Bei Exifer erkennt man eindeutig, dass es das Skalierungsverfahren ist.
Die Thumbnails sehen ja bereits am Bildschirm übel aus, und zu diesem
Zeitpunkt hat noch gar keine JPEG-Kompression stattgefunden.
> Immerhin kann man dem Programm aber ein externes Thumbnail vorsetzen,
> das es dann einbinden soll (/t a,@dateiname.thumb). Gibt man exifedit
> also mal ein ordentliches, per Lanczos-Methode erstelltes Thumbnail
> vor, wird das Ergebnis dann tatsaechlich so, wie es soll.
Ich arbeite häufiger mit den Bibliotheken von XnView. Hier gibt es einen
Parameter für "Quick and dirty" bzw. hohe Qualität. Die erstere bringt
die gleichen Ergebnisse wie Exifer, die zweite ist OK.
> Gibt es convert irgendwo ggf. einzeln zu finden, also ohne das
> komplette ImageMagick-Paket? Oder eine Alternative?
Die XnView-Bibliothek gibt es auch als ActiveX-Komponente. Eventuell
lässt sich damit was anfangen. Ich selbst benutze sie "nur" unter VB.
MfG
Hans
Hans Wein
> 16 MEGAbyte? Ach komm, ich erinnere mich an Zeiten, wo 16 KILObyte
> normal und 32 KB das Maximum dessen waren, was das Betriebssystem
> verwalten konnte, und man für 64 KB schon Tricks wie Speicherbank-
> Umschaltung in Assembler machen mußte :-)
Deine Erinnerungen sind lückenhaft - nimm das Ganze mal zwei, dann
stimmts :-)
> Würg. Hab ich mich nie mit beschäftigt, das sieht mir zu sehr nach
> Visual Basic aus. Da schreib ich lieber gleich ein kleines Executable
> in C++ ;)
Komisch... Anscheinend keine Ahnung von VB, aber dicke Backen machen :-)
MfG
Hans
David Haller
>> Tja - und dann kann man einfach markieren, welche bearbeitet werden
>> sollen und welche nicht. Nach der Auswahl wird der vorher spezifizierte
>> Befehl dann nur auf die gewaehlten Dateien angewandt.
>
> Hier muss ich passen. Sowas habe ich noch nie gebraucht. Aber vielleicht
> geht das mit mc, das/den verwende ich aber nicht. Ein schneller Blick meint
> aber, das könnte funktionieren.
Jup. F2 -> @ "Do something on the tagged files"
Und auch das mit den Dateinamen in einer Datei ist trivial loesbar:
while read name; do script parameter "$name"; done < dateien.liste
oder falls das script selber die Schleife "macht":
bash:
script parameter $(< dateien.liste)
allgemein:
script parameter `cat dateien.liste`
oder (speziell bei sehr grossen Dateiliste):
xargs script parameter < dateien.liste
Die Dateiliste selbst kann man erzeugen wie man will, z.B. per
ls *2005-{foo,bar}*.tif | grep -v 'bla' > dateien.liste
und ggfs. per Editor nachbearbeiten. Oder wie auch immer.
-dnh
--
Computers make very fast, very accurate mistakes.
Al Bogner
>> Hier muss ich passen. Sowas habe ich noch nie gebraucht. Aber vielleicht
>> geht das mit mc
> Jup. F2 -> @ "Do something on the tagged files"
>
> Und auch das mit den Dateinamen in einer Datei ist trivial loesbar:
>
> while read name; do script parameter "$name"; done < dateien.liste
>
> oder falls das script selber die Schleife "macht":
>
> bash:
> script parameter $(< dateien.liste
Hallo David,
das ist aber eine Überraschung hier von dir zu lesen. Da fühle ich mich mit
meinen Bash-Vorschlägen nicht mehr so in der Minderheit :-)
Kennst du eine Lösung für das ursprüngliche Problem des Threads? Wie ich
schon gepostet habe, kann exiftool das nur mit bestimmten Dateien, d.h. in
den Original-Makernotes muss ein Eintrag dazu vorhanden sein.
Siehst du eine Möglichkeit mit ImagickMagick? Ich kann nicht glauben, dass
es damit nicht geht. Aus der IM-ML kam leider noch keine Antwort.
Al
Elmar Baumann
[...]
Dann ist der WSH zweifellos ein Fortschritt gegenüber DOS-Batch. Windows
verwende ich auch (seit ca. 1998), es gibt etliche Programme, die ich
schätze, nur dafür, aber zum Skripten nur die Bash (Gnu Utils oder
cygwin). Ich kann mir vorstellen, dass sich der Kommandozeilenpuffer
erhöhen lässt. 20 Dateien sind recht wenig. Anfang 1995 machte ich mit
der damilgen Bash unter Linux einen Test: 120.000 Zeichen groß war der
Kommandozeilenpuffer. Heute konnte ich bislang keine Grenze feststellen.
> Ein bisschen hampelig wird die Sache
> nur dadurch, dass das Thumbnail im gleichen Verzeichnis wie die zu
> aktualisierende Datei liegen muss - da muss man also etwas mit den
> Pfaden aufpassen. "Im Prinzip" funktioniert das aber.
Kann man dem @ keinen Pfad übergeben, z.B. %TMP%\tumbnail.jpg? Hilft es,
temporär das zu bearbeitende Bild in das %TMP%-Verzeichnis zu
verschieben, dort das Thumbnail-Bild zu generieren, einzufügen,
Thumbnail löschen und bei Erfolg (Rückgabewert == 0) die Datei mit neuem
Thumbnail wieder zurück zu verschieben?
> Gibt es convert irgendwo ggf. einzeln zu finden, also ohne das komplette
> ImageMagick-Paket? Oder eine Alternative?
Ich kenne es nur im Paket. Vielleicht hat IrfanView oder ein ähnliches
Programm eine Kommandozeilenoption?
--
Homepage: http://www.elmar-baumann.de/fotografie/
Uwe Schröder
>>16 MEGAbyte? Ach komm, ich erinnere mich an Zeiten, wo 16 KILObyte
>>normal und 32 KB das Maximum dessen waren, was das Betriebssystem
>>verwalten konnte, und man für 64 KB schon Tricks wie Speicherbank-
>>Umschaltung in Assembler machen mußte :-)
>
> Deine Erinnerungen sind lückenhaft - nimm das Ganze mal zwei, dann
> stimmts :-)
Nicht wirklich. 64 KB Adreßraum, davon 32 KB durch das BASIC-ROM
belegt, bleiben noch 32 KB für das RAM übrig. Volle 64 KB RAM nur,
indem man die ROM-Bank wegschaltet ... aber dann steht man halt ohne
Betriebssystem da und darf *alles* selber machen. *ächz*
Da: http://www.zock.com/8-Bit/Ad_SVI318-328.JPG ;-)
> Komisch... Anscheinend keine Ahnung von VB, aber dicke Backen machen :-)
Ich hab lange genug diverse BASIC-Dialekte programmiert, um es nie
wieder anfassen zu wollen :-P
Nee, aber ernsthaft ...
VB: Dim i As Integer
Dim j As Integer
Dim k As Integer
C: int i, j, k;
... ich finde BASIC als Programmiersprache einfach furchtbar
umständlich und langatmig. *shrug*
usch
Uwe Schröder
> Ich habe jetzt da nicht viel Lust an der Bezeichnung rumzureiten,
> Preview, Thumbnail oder was immer du willst.
Ich reite gar nicht ... du hast mit "Preview" angefangen, was nur mit
den entsprechenden proprietären Makernotes funktioniert. Laut Betreff
geht es um Thumbnails, und die sind Teil der EXIF-Spezifikation :)
>> Und da gehört eben ein Thumbnail ebenso direkt als Meta-Daten in
>> die Originaldatei hinein wie Bildtitel, Aufnahmedatum,
>> Aufnahmebedingungen, Keywords usw.
>
> Mag sein, aber wenn der Großteil der Programme dies nicht nützt,
> was bringt es dann?
Das Henne-Ei-Problem. Irgendwo muß man ja mal anfangen - wenn alle
Bilder Thumbnails hätten, bräuchten die Programme keine eigenen
Thumbnail-Routinen mehr.
>> Der Löwenanteil meines täglichen inkrementellen Backups entfällt
>> auf die Datei FSViewer.db.
>
> Kenne ich nicht, aber so wie sich das liest, wird die Datei
> automatisch erstellt. Was passiert, wenn du sie löscht? Wird sie
> automatisch neu angelegt?
Ja, aber bei größeren Verzeichnissen dauert es dann eben entsprechend
lange, bis alle Thumbnails erzeugt sind. An Ausklammern hab ich auch
schon gedacht - ich muß noch mal darüber meditieren, ob der mögliche
Zeitgewinn nach einem eventuellen Restore den täglichen Zeitverlust
beim Backup wirklich wert ist.
> Bessere Sicherungssoftware verwenden, wenn man da nicht ausklammern
> kann.
Man kann. Bessere Software hätte ich trotzdem gerne :)
Das Sichern ist nicht das Problem, das geht mit TrayBackup recht gut.
Aber wehe, man will mal z.B. ein bestimmtes Bild vom Backup
zurückspielen - es wird leider keine Datenbank mitgeführt, auf welchem
Medium sich welche Datei befindet :(
Du kennst nicht zufällig ein Backup-Programm, das unter Win98 läuft,
DVD-RAM als Medium nutzen kann und in Bedienung und Funktionsumfang
HPs "Colorado Backup II" entspricht?
> Vor einer Sicherung lösche ich sogar per Script automatisch
> bestimmte Dinge wie Cache-Verzeichnisse, Thumbnails, Cookies etc.
Gelöscht wird bei mir sicherheitshalber immer *nach* dem Backup :)
usch
Al Bogner
> Ja, aber bei größeren Verzeichnissen dauert es dann eben entsprechend
> lange, bis alle Thumbnails erzeugt sind. An Ausklammern hab ich auch
> schon gedacht - ich muß noch mal darüber meditieren, ob der mögliche
> Zeitgewinn nach einem eventuellen Restore den täglichen Zeitverlust
> beim Backup wirklich wert ist.
Wie oft brauchst du ein Restore? Wirkliche Probleme hatte ich bis jetzt nur
1x, und da bin ich als root (Admin) bei rm -r auf der Tastatur abgerutscht
und war ein Directory zu hoch. (würg)
Für den Ausnahmefall kalkuliere ich also keine Zeit, wie lange die
Wiederherstellung braucht. Wenn du öfters eine Wiederherstellung brauchst,
musst du über organisatorische Dinge nachdenken.
>> Bessere Sicherungssoftware verwenden, wenn man da nicht ausklammern
>> kann.
>
> Man kann. Bessere Software hätte ich trotzdem gerne :)
Eigene schreiben :-)
> Das Sichern ist nicht das Problem, das geht mit TrayBackup recht gut.
> Aber wehe, man will mal z.B. ein bestimmtes Bild vom Backup
> zurückspielen - es wird leider keine Datenbank mitgeführt, auf welchem
> Medium sich welche Datei befindet :(
Genau wegen so was, habe ich mein eigenes simples Script. Mit einem Backup
können die meisten ruhig schlafen, solange sie kein Restore probiert haben.
Wo sich eine Datei befindet, ist relativ einfach, wenn man ein Log macht.
Ich mache folgendes:
Gegeben ist die hierarchische Struktur der Original-Bilder mit jpg und
tiff-Bilder. Hilfsbilder, wie Bildindexe, werden mit mit .jpeg bezeichnet,
die kann ich so leicht ausklammern. Es gibt noch eine Reihe von weiteren
Annahmen, aber das geht hier zu weit. Für die bearbeiteten Bilder gibt es
eine _identische_ Struktur mit ähnlichem Namen, sodass man leicht abfragen
bzw. verknüpfen kann, also zB
Original:
/netzlaufwerksverzeichnis/original_digitalfotos/user/2005-10_herbstfruechte_digicam
Bearbeitet:
/netzlaufwerksverzeichnis/digitalfotos/user/2005-10_herbstfruechte
Ich erstelle nun per Script _genau_ _diese_ Struktur wieder und
verschlüssele jedes Bild einzeln per GPG. GPG hat den Vorteil, dass es auch
gleichzeitig komprimiert, soweit Bilder überhaupt noch wesentlich
komprimierbar sind. Meine Tiffbilder werden sowieso automatisch
komprimiert, falls mein Script entdeckt, das sie nicht intern gezippt sind.
Hint:
identify -verbose "$INP" | grep "Compression: Zip"
wenn nicht:
convert "$INP" -compress zip "$INP"_zip.tif
Inkrementell dazu speichern kannst du damit auch, musst ja nur abfragen, ob
die Datei schon existiert bzw. verändert wurde. Ich sichere aber immer
_alles_ zwischendurch auf HD und von Zeit zu Zeit, wenn ich denke, dass
sich vieles geändert hat, brenne ich auf eine unsichere DVD, man kann
natürlich auch DVD-RAM verwenden. Auf meine Sicherungs-CDs und DVDs musste
ich noch nie zurückgreifen. Uralte Aldi-CDs bringen aber noch keine
CRC-Fehler mit readcd, bei den DVDs habe ich noch nicht getestet, lesbar
sind sie aber.
> Du kennst nicht zufällig ein Backup-Programm, das unter Win98 läuft,
gpg und zip sollten funktionieren und das sollte für ein Backup reichen.
Backup-SW macht ja letztlich auch nichts anderes. Komprimieren oder/und
verschlüsseln. Ich habe zusätzlich zu DVD-Sicherungen auf mehreren HDs
immer die letzten 3 Sicherungsstände. Natürlich kann noch immer irgendeine
Situation eintreten, wo man etwas verliert. Speziell sollte man aufpassen,
wenn in der Nachbarschaft gebaggert wird, da wären fast mal alle HDs dabei
unbrauchbar geworden und die aktuelle DVD-Sicherung war 1 Monat alt.
Bleibt noch das Problem, wenn alles nicht mehr auf ein Medium passt. Auch
das kann man lösen, einfach ein Script durchlaufen lassen, dass auf
oberster Ebene der gesicherten Struktur, die Ordnergröße rekursiv berechnet
und in einem Verzeichnis Links erstellt bis die 1. DVD voll ist, usw. Das
Analysieren dauert hier für 4 DVDs geschätzt 1 Minute, vielleicht auch
weniger.
> DVD-RAM als Medium nutzen kann
Dafür gibt es dann das nächste Script um auf ein Medium auszulagern, bei
DVD-RAM dürfte es besonders leicht sein.
> und in Bedienung und Funktionsumfang
> HPs "Colorado Backup II" entspricht?
Kenne ich nicht, ich mag aber auch keine Backup-Programme, sondern sichere
nur das, was ich _wirklich_ wieder brauche, wenn ich einen Rechner neu
aufsetze und dafür gibt es dann je nach Fall komprimierte oder
verschlüsselte Dateien oder auch ganze Ordner. Ein Einwand ist natürlich,
was ist, wenn ein Archiv beschädigt ist, aber deswegen sichere ich eben
redundant.
Dazu gehört auch eine Analyse des kompletten Rechners (unter Linux speichere
ich die Ausgabe von hwinfo, lshw, sitar, siga, etc., unter Win soll Everest
und Sandra ganz informativ sein).
Ich halte nichts davon per Image-Backup im Fall der Fälle zurückzusichern,
da setze ich den Rechner lieber neu auf und kopiere _meine_ Daten zurück.
Die Sache ist einfach die, ich brauche das eigentlich nie. Ich kenne die
Situation nur dann, wenn ein Rechner wegen eines neuen Betriebssystems
aufgesetzt wird und das kann man planen.
>> Vor einer Sicherung lösche ich sogar per Script automatisch
>> bestimmte Dinge wie Cache-Verzeichnisse, Thumbnails, Cookies etc.
>
> Gelöscht wird bei mir sicherheitshalber immer *nach* dem Backup :)
Ich lösche nur Dinge, die das System automatisch wiederherstellt.
Al
Dieter Lefeling
> Dann ist der WSH zweifellos ein Fortschritt gegenüber DOS-Batch.
Ich denke, das kann man so sagen, ja. <8)
> Ich kann mir vorstellen, dass sich der Kommandozeilenpuffer
> erhöhen lässt. 20 Dateien sind recht wenig. Anfang 1995 machte ich mit
> der damilgen Bash unter Linux einen Test: 120.000 Zeichen groß war der
> Kommandozeilenpuffer. Heute konnte ich bislang keine Grenze feststellen.
Also, die 20 Dateien (je kompletter Pfad mit 20..30 Zeichen) waren nur
ein Beispiel. Das ging noch. Hingegen waren 350 Dateien auf einen Rutsch
dann doch zuviel. Dazwischen hab' ich nichts ausprobiert. <8)
> > Ein bisschen hampelig wird die Sache
> > nur dadurch, dass das Thumbnail im gleichen Verzeichnis wie die zu
> > aktualisierende Datei liegen muss - da muss man also etwas mit den
> > Pfaden aufpassen. "Im Prinzip" funktioniert das aber.
>
> Kann man dem @ keinen Pfad übergeben, z.B. %TMP%\tumbnail.jpg?
Ich habe es jetzt mal selbst ausprobiert - entgegen der Dokumentation
geht das tatsaechlich. Also direkt mit Angabe des vollen Thumb-Pfades,
wie exifedit /b /t a,@f:\daten\thumb\bild.thm g:\bilderkes\neu\bild.jpg
Das macht die Sache natuerlich besonders einfach. <8)
> > Gibt es convert irgendwo ggf. einzeln zu finden, also ohne das komplette
> > ImageMagick-Paket? Oder eine Alternative?
>
> Ich kenne es nur im Paket. Vielleicht hat IrfanView oder ein ähnliches
> Programm eine Kommandozeilenoption?
Ich habe noch keines gefunden. Muss ich dann doch wohl convert nehmen.
Immerhin unterstuetzt das anscheinend auch den Lanczos-Algorithums und
eine frei waehlbare Jpeg-Kompression.
Mal FYI als bisheriges Ergebnis:
Inzwischen habe ich einen recht brauchbaren Weg gefunden. Nach diversen
Varianten mit dem Kontextmenue und "Senden An" (geht alles) habe ich das
VBS-Script direkt in XnView eingebunden. Es gibt dort den editierbaren
Menuepunkt "Oeffnen mit", der auch im Kontextmenue erscheint.
Im Unterschied zu anderen Methoden generiert XnView fuer jede einzelne
ausgewaehlte Datei einen eigenen Programmaufruf. Wenn man also zwei
Dateien markiert, erzeugt es ein programm.exe datei1.jpg und danach ein
programm.exe datei2.jpg, und zwar ohne den Ablauf des ersten Programms
abzuwarten. Es wird also immer nur genau ein Parameter (voller Pfad der
gewaehlten Datei) uebergeben.
Das ganze sieht dann also so aus, dass man ganz bequem einfach alle
Dateien mit zu aktualisierenden Thumbnails im XnView-Browser auswaehlt
und dann "Oeffnen mit | Thumbnail-Updater.vbs" startet. 8-)
Derzeit werden die Thumbnails noch in einem Schritt vorher manuell
generiert. Mit Einbinden von convert in das Script wird auch das
automatisiert. Ich denke, das waere dann so etwa die Loesung, die ich
mir vorgestellt habe.
Haette man BTW auch gleich in XnView integrieren koennen. <8)
Dieter
Elmar Baumann
> Derzeit werden die Thumbnails noch in einem Schritt vorher manuell
> generiert. Mit Einbinden von convert in das Script wird auch das
> automatisiert. Ich denke, das waere dann so etwa die Loesung, die ich
> mir vorgestellt habe.
Solche Tasks lassen sich automatisieren. Mit den ExifUtils und anderen
Programmen kann man die Bilder auf Fotografierzeit lt. EXIF-Daten
datieren, meist ist das ohnehin der Fall nach Übertragung auf den PC.
Automatik: Mit dem WSH lässt sich sicher die Änderungszeit einer
Bilddatei auslesen. Ist diese neuer als die Fotografierzeit in den
EXIF-Daten, ruft man das Thumbnail-Aktualisierungs-Skript für diese
Datei auf. Man kann das als "Geplanten Task" einrichtet. Beim geplanten
Task muss der Computer zu der Zeit eingeschaltet sein; sicher gibt es
externe Lösungen für geplante Tasks wie "Einmal täglich" (Annahme:
Kamerauhr geht nicht signifikant vor Rechneruhr).
Pseudocode:
Bildverzeichnisse="E:\Bilder,F:\Bilder,..."
Für alle JPG-Dateien in $Bildverzeichnisse
Falls JPG-Datei-Änderungszeit größer Schreibzeit gemäß EXIF-Daten
Aktualisiere Thumbnail in JPG-Datei
--
Homepage: http://www.elmar-baumann.de/fotografie/
Al Bogner
> Solche Tasks lassen sich automatisieren. Mit den ExifUtils und anderen
> Programmen kann man die Bilder auf Fotografierzeit lt. EXIF-Daten
> datieren,
grmpf
> meist ist das ohnehin der Fall nach Übertragung auf den PC.
> Automatik:
nochmals grmpf
Aber das Thema wurde hier schon mal kürzlich diskutiert, dass das nicht das
Gelbe vom Ei ist.
> Mit dem WSH lässt sich sicher die Änderungszeit einer
> Bilddatei auslesen. Ist diese neuer als die Fotografierzeit in den
> EXIF-Daten, ruft man das Thumbnail-Aktualisierungs-Skript für diese
> Datei auf.
Da gibt es sicher Situationen, wo das nicht passt. Ich habe mir bei convert
-fuzz, so geholfen, dass es nur 1x angewandt wird, dass ich "processed" in
den Metadaten vermerke. Nachdem es auch bösartige Programme gibt, die
unerwartet Exif-Felder verändern, habe ich es mehrmals, u.a. in UserComment
vermerkt.
Al
Dieter Lefeling
> Dieter Lefeling wrote:
> > Derzeit werden die Thumbnails noch in einem Schritt vorher manuell
> > generiert. Mit Einbinden von convert in das Script wird auch das
> > automatisiert. Ich denke, das waere dann so etwa die Loesung, die ich
> > mir vorgestellt habe.
>
> Solche Tasks lassen sich automatisieren.
Ja, ist gerade geschehen. <8)
Funktioniert jetzt wie eine eingebaute Funktion von XnView.
Du meinst aber wohl "noch automatischer".
> Mit den ExifUtils und anderen
> Programmen kann man die Bilder auf Fotografierzeit lt. EXIF-Daten
> datieren, meist ist das ohnehin der Fall nach Übertragung auf den PC.
Fuer diese Funktion benutze ich XnView. Oder frueher Exifer. Sofern das
denn noetig ist: Beim Uebertragen per Kartenleser passt die Aufnahmezeit
auch dann noch, wenn die Datei auf der Platte liegt.
> Automatik: Mit dem WSH lässt sich sicher die Änderungszeit einer
> Bilddatei auslesen.
Klar, alle relevanten Datenfelder.
> Ist diese neuer als die Fotografierzeit in den
> EXIF-Daten, ruft man das Thumbnail-Aktualisierungs-Skript für diese
> Datei auf.
Kann man machen. Ist hier aber keine Option, weil ich alle Bilder auf
die Aufnahmezeit datiere, sofern sie nach Bearbeitung eine andere Zeit
erhalten. Ich ueberlege sogar, im Script das Dateidatum auszulesen und
nach dem Thumbnail-Update wieder auf den vorherigen Wert zu setzen.
BTW - ich nutze jetzt convert (-resize 160 -quality 70 -strip) zum
Erzeugen der Thumbnails. Dafuer darf man sich dann 17 MB Daten auf die
Platte und in die Registry muellen lassen. Derzeit probiere ich mit dem
einen oder anderen Kommandozeilenprogramm herum, das ebenfalls Thumb-
nails erzeugen kann. Wenn das befriedigend funktioniert, verschwindet
der ganze Kram wieder. Oder gibt es das definitive Argument fuer das
komplette Magick-Paket?
Dieter
Dieter Lefeling
> Elmar Baumann schrieb:
>
> > Ich kenne es nur im Paket. Vielleicht hat IrfanView oder ein ähnliches
> > Programm eine Kommandozeilenoption?
>
> Ich habe noch keines gefunden.
Sollte heissen: ich hab' nicht genau genug hingesehen. Doch, Irfanview
hat einen Kommandozeilenmodus, mit dem man auch resizen kann. Allerdings
nicht so flexibel wie mit convert. Irfanview ueber Kommandozeile habe
ich bisher noch nicht benutzt.
Dieter
Dieter Lefeling
> Dieter Lefeling wrote:
> [...]
> > Gibt es convert irgendwo ggf. einzeln zu finden, also ohne das komplette
> > ImageMagick-Paket? Oder eine Alternative?
>
> Ich kenne es nur im Paket.
Und noch ein Update: der gute Horst hat mich auf jpegnail aufmerksam
gemacht. Nicht viel mehr als 100 KB, und macht genau das, was es hier
soll - es entfernt oder generiert Thumbnails. Die Skalierungsqualitaet
ist fuer diesen Zweck voellig okay, das Programm unterstuetzt auf der
Befehlszeile auch Jokerzeichen (bei Bedarf alles in einem Rutsch), es
behaelt Dateidatum und -uhrzeit offenbar bei, und das erwaehnte Script
laeuft mit diesem Prograemmchen deutlich schneller. Wenn jemand noch
einen Haken kennt: nur zu. Bisher sieht's IMHO gut aus.
Dieter
Al Bogner
> Derzeit probiere ich mit dem
> einen oder anderen Kommandozeilenprogramm herum, das ebenfalls Thumb-
> nails erzeugen kann.
Hast du mein anderes Posting zu GD und Netpbm gelesen? Allerdings habe ich
es nicht ausprobiert. Schreib mal was du davon hältst.
Al
Dieter Lefeling
> Hast du mein anderes Posting zu GD und Netpbm gelesen?
Kann ich jetzt auf die Schnelle nicht finden. Msg-ID?
> Allerdings habe ich es nicht ausprobiert. Schreib mal was du davon hältst.
Generiert das mit weniger Aufwand bessere Thumbnails ?-)
Dieter
Al Bogner
> Al Bogner schrieb:
>
>> Hast du mein anderes Posting zu GD und Netpbm gelesen?
>
> Kann ich jetzt auf die Schnelle nicht finden. Msg-ID?
Es standen nur die Links dort.
http://netpbm.sourceforge.net/
http://www.boutell.com/gd/
>> Allerdings habe ich es nicht ausprobiert. Schreib mal was du davon
>> hältst.
>
> Generiert das mit weniger Aufwand bessere Thumbnails ?-)
Angeblich ja, ich habe aber nur gelesen, dass Netpbm "kleiner" sein soll als
IM.
BTW ich verstehe nicht, warum du so mit HD-Kapazität geizt. Ein paar MB
stehen doch in keinem Verhältnis zu den vielen Bildern.
Al
David Haller
> David Haller wrote:
[..]
> das ist aber eine Überraschung hier von dir zu lesen. Da fühle ich mich mit
*g*
> Kennst du eine Lösung für das ursprüngliche Problem des Threads? Wie ich
> schon gepostet habe, kann exiftool das nur mit bestimmten Dateien, d.h. in
> den Original-Makernotes muss ein Eintrag dazu vorhanden sein.
Hm. Das koennte man ggfs. durch ein Wrapper-Perl-Script umgehen, ich
kenne aber die Details von EXIF und ExifTool (noch) nicht genug. Und
ich habe halt selber bisher keinen Bedarf an sowas, meine 2 Kameras
sind beide analog :)
Wenn du mal selber schaust (am besten mit einem Editor mit
Syntax-Highlighting) ist 'exiftool' "nur" ein Wrapper um
Image::ExifTool und eine so spezialisierte Arbeit wie gefordert
muesste sich relativ einfach schreiben lassen. Dumm nur, dass es kein
'Datum' zum Preview/Thumbnail gibt. Eine automatische Erkennung ob der
Thumbnail noch zum Bild passt geht also eher nicht. Aber auf eine
Dateiliste (Datei/Kommandozeile) waere es kein Problem.
Wobei ich mir ueber den Unterschied(?) von PreviewImage und ThumbnailImage
nicht klar bin. Hm. Du hattest mir mal Bilder gemailt, die beides
haben, z.B. pic5.jpg aus dem jpgfiles_mit_exif_fuer_david.tgz:
Preview Image Start : 14409
Preview Image Length : 37376
Thumbnail Offset : 4096
Thumbnail Length : 4928
Preview Image : (Binary data 37376 bytes, ...)
Thumbnail Image : (Binary data 4928 bytes, ...)
Beide Tags sind jedenfalls prinzipiell 'Writeable' in ExifTool.
Hm. Kannst du mir mal ein Beispiel-Bild mailen wo ExifTool nicht mitspielt
(an die Adresse die du kennst, despammed.com filtert sowas vermutlich aus)?
Dann koennte ich mal ein bisserl basteln. Kann aber nix versprechen,
da ich z.Z. einiges wichtigeres zu erledigen habe.
-dnh
--
Fighting for peace is like fucking for virginity.
Elmar Baumann
> Du meinst aber wohl "noch automatischer".
Ja, gar nichts mehr tun, der Computer erledigt das. Geht so wie
beschrieben nur, wenn man bei Änderungen das Änderungsdatum belässt. Das
Skript kann dann nach dem Einfügen des Thumbnails das Dateidatum auf
Fotografierzeit zurücksetzen.
> Oder gibt es das definitive Argument fuer das
> komplette Magick-Paket?
Nicht, wenn du nur convert brauchst für einen einzigen Zweck und es
dafür eine brauchbare Alternative gibt. Sind noch zig Gigabyte auf der
Programmpartition frei, spricht auch nichts dagegen, man weiß nie ob man
nicht vielleicht doch einmal eines der Programme (convert, identify,
...) brauchen kann (wobei ein Gegenargument ist, dass man dann via
Internet schnell die aktuellste Version herunterladen kann).
--
Homepage: http://www.elmar-baumann.de/fotografie/
Elmar Baumann
> Und noch ein Update: der gute Horst hat mich auf jpegnail aufmerksam
Das scheint genau deine Anfordung zu erfüllen. Ist die Qualität in
Ordung, würde ich es einsetzen. In der Beschreibung steht "You may
obtain sharper images by using one of the filters implemented in
ImageMagick." Die Doku habe ich nicht gelesen. Aber wenn es heißt, mit
einem Tool des IM-Pakets kann jpegnail die Qualität verbessern, ist das
ein Grund, IM zu installieren (Andererseits könnte die Aussage so
interpretiert werden, dass der Autor das noch nie versuchte).
--
Homepage: http://www.elmar-baumann.de/fotografie/
Al Bogner
>> Kennst du eine Lösung für das ursprüngliche Problem des Threads? Wie ich
>> schon gepostet habe, kann exiftool das nur mit bestimmten Dateien, d.h.
>> in den Original-Makernotes muss ein Eintrag dazu vorhanden sein.
>
> Hm. Das koennte man ggfs. durch ein Wrapper-Perl-Script umgehen, ich
> kenne aber die Details von EXIF und ExifTool (noch) nicht genug. Und
> ich habe halt selber bisher keinen Bedarf an sowas, meine 2 Kameras
> sind beide analog :)
Mich interessiert es auch nur theoretisch. Ich habe diesbgl. mit dem
Exiftool-Autor schon Mails ausgetauscht und ich denke er hat gute Gründe,
warum er das nur für Dateien mit entsprechenden Makernotes zulässt.
> Wenn du mal selber schaust (am besten mit einem Editor mit
> Syntax-Highlighting) ist 'exiftool' "nur" ein Wrapper um
> Image::ExifTool und eine so spezialisierte Arbeit wie gefordert
> muesste sich relativ einfach schreiben lassen. Dumm nur, dass es kein
> 'Datum' zum Preview/Thumbnail gibt. Eine automatische Erkennung ob der
> Thumbnail noch zum Bild passt geht also eher nicht. Aber auf eine
> Dateiliste (Datei/Kommandozeile) waere es kein Problem.
Ich habe mir bei einem ähnlichen Problem organisatorisch geholfen, ich
vermerke einfach automatisiert in mehreren Exif-Feldern, dass das Bild
bearbeitet wurde. Redundant deswegen, weil es passieren kann, dass man
Metadaten verliert und man sie dann vielleicht noch woanders vorfindet. Ich
habe also immer ein Original- und ein _bearbeitetes_ Foto. Das Original
bleibt unverändert und das bearbeitete Foto hat sich in irgendeiner Form
verändert. Mag sein, dass man das bei einem Preview nicht merkt, aber ich
würde einfach annehmen, dass _jedes_ Bild eine neue Preview zu bekommen
hat. Da ich ein bearbeitetes Bild wegen Komprimierungsverlusten kein 2. Mal
bearbeite, sondern bei Bedarf wieder auf das Original zurückgreife, ist das
schon irgendwie ein Workaround, wenn man die Bearbeitung in den Metadaten
vermerkt.
> Wobei ich mir ueber den Unterschied(?) von PreviewImage und ThumbnailImage
> nicht klar bin.
Ich auch nicht.
> Hm. Du hattest mir mal Bilder gemailt, die beides
> haben, z.B. pic5.jpg aus dem jpgfiles_mit_exif_fuer_david.tgz:
Müsste ich suchen, was das für Bilder waren. Kannst du die Erstellungszeit
des Fotos abfragen, dann finde ich es schneller.
Womit bzw. wie hast du u.a. abgefragt?
> Preview Image Start : 14409
> Preview Image Length : 37376
> Thumbnail Offset : 4096
> Thumbnail Length : 4928
> Preview Image : (Binary data 37376 bytes, ...)
> Thumbnail Image : (Binary data 4928 bytes, ...)
>
> Beide Tags sind jedenfalls prinzipiell 'Writeable' in ExifTool.
>
> Hm. Kannst du mir mal ein Beispiel-Bild mailen wo ExifTool nicht mitspielt
> (an die Adresse die du kennst, despammed.com filtert sowas vermutlich
> aus)?
Mache ich gleichzeitig mit dem Absenden dieses Postings. Grundsätzlich habe
ich mit allen FZ20-Fotos und Caplio R1-Fotos Probleme, mit Minolta Z2-Fotos
nicht. Es würde mich wundern, wenn ich dir ein Z2-Foto geschickt habe.
Kannst du bei bei dem dir vorliegenden Foto ein anderes Preview-Bild mit
exiftool einfügen?
Ich lasse diesesmal absichtlich meine langen Dateinamen, dann weis ich
welches Bild du hast.
exiftool
'-previewimage<=preview_050527_1833.002_fr_abit.error.screenshots.d_fz20-original.jpg'
050829_1620.002_mo_saalfelden.steinernes.meer_r1-original.jpg
0 image files updated
1 image files unchanged
exiftool
'-previewimage<=preview_050527_1833.002_fr_abit.error.screenshots.d_fz20-original.jpg'
051008_1536_sa_oktoberbluete_fz20-original.jpg
0 image files updated
1 image files unchanged
Ich schicke dir auch noch eines mit, wo es passt:
exiftool
'-previewimage<=preview_050527_1833.002_fr_abit.error.screenshots.d_fz20-original.jpg'
041005_1629.001_di_schoenramer.moor.digicam_z2-original.jpg
1 image files updated
Nur aus Interesse, hast du mein Mail bzgl. dvdwizard erhalten. Eine Antwort
war ja nicht unbedingt nötig.
> Dann koennte ich mal ein bisserl basteln. Kann aber nix versprechen,
> da ich z.Z. einiges wichtigeres zu erledigen habe.
Ich habe daran nur theoretisches Interesse.
Al
Dieter Lefeling
> [ jpegnail ]
>
> Das scheint genau deine Anfordung zu erfüllen. Ist die Qualität in
> Ordung, würde ich es einsetzen. In der Beschreibung steht "You may
> obtain sharper images by using one of the filters implemented in
> ImageMagick."
Also, bei maximal 200 Pixeln Thumbnailbreite ist Schaerfe nicht so das
grosse Thema. Ich kann visuell keinen relevanten Unterschied zu convert
mit gleicher -quality 80 erkennen.
> Die Doku habe ich nicht gelesen. Aber wenn es heißt, mit
> einem Tool des IM-Pakets kann jpegnail die Qualität verbessern, ist das
> ein Grund, IM zu installieren (Andererseits könnte die Aussage so
> interpretiert werden, dass der Autor das noch nie versuchte).
Ich lese das so, dass der Autor weiss, dass man mit anderen Verfahren
(bikubisch, Lanzcos) bessere Ergebnisse erhaelt, und IM unterstuetzt
diese Verfahren eben. Die bessere Qualitaet ist sicher bei groesseren
Dateien relevant, fuer den angepeilten Zweck aber IMHO irrelevant. Das
Ergebnis ist jedenfalls i.O. und um Laengen besser als bei Exifer oder
exifedits eigenem Thumbnailgenerator.
Soll heissen: jpegnail macht die Sache schon sehr gut. Es gibt da nur
zwei Stellen, an denen es noch hakt:
Datei- oder Verzeichnisnamen mit Leerzeichen kann man bekanntlich mit
Anfuehrungszeiten in den Griff bekommen (jpegnail "tolles bild.jpg").
Das funktioniert allerdings *nicht*, wenn der Dateiname Jokerzeichen
enthaelt. Ein Aufruf mit "neue Bilder\Mai 05\*.jpg" klappt also nicht.
Moeglicherweise eine Eigenheit des verwendeten Compilers bzw. dessen
Befehlszeilenparser (reine Vermutung). Meine Loesung besteht darin, in
diesem Fall eben den bei Win32 nach wie vor unterstuetzten 8+3-Kurznamen
zu verwenden (VB-Script verfuegt ueber entsprechende Eigenschaften des
File-Objekts).
Vor allem aber: es gibt Faelle, in denen arbeitet jpegnail zwar, aber
das Ergebnis enthaelt anschliessend kein Thumbnail. Es sieht so aus,
dass dies dann der Fall ist, wenn das zu Ausgangsbild keinerlei Exif-
Informationen enthaelt. Mit convert + exifedit ist dieser Fall ein
Problem.
Ich habe das urspruengliche Problem jetzt mit einem etwas flexibleren
Script geloest, das ins SendTo-Menue integriert wurde und das updaten
von einzelnen Dateien oder ganzen Verzeichnissen ermoeglicht. Jedenfalls
abgesehen von der zuletzt genannten "Eigenheit" von jpegnail.
Dieter
Elmar Baumann
> Das funktioniert allerdings *nicht*, wenn der Dateiname Jokerzeichen
> enthaelt. Ein Aufruf mit "neue Bilder\Mai 05\*.jpg" klappt also nicht.
Es könnte auch sein, dass Vektoren wie in der Bash gebildet werden: Per
Default ist das Leerzeichen ein Feldseparator. Überbigt man "ab cd ef"
wird ein Vektor mit den drei Elementen "ab", "cd" und "ef" gebildet.
Werden der Bash so Dateinamen überreicht, gibt es auch Probleme mit
Leerzeichen in Dateinamen. Diese umgeht man durch Ändern des
Feldseparators, z.B. setzt man den Linefeed (kommt in der Regel nicht in
Dateinamen vor). Arbeitet ein Programm so (*.jpg wird zu allen passenden
Dateinamen erweitert und ein Vektor gebildet, wobei ein Leerzeichen die
Elemente trennt), kann man das nur ändern, indem man es in einer
Schleife aufruft und stets nur einen Dateinamen überreicht.
Wenn du mit der aktuellen Lösung zufrieden bist (XnView + SendTo), gibt
es eigentlich keinen Grund, diese Vermutung zu überprüfen.
--
Homepage: http://www.elmar-baumann.de/fotografie/
Dieter Lefeling
> Es könnte auch sein, dass Vektoren wie in der Bash gebildet werden: Per
> Default ist das Leerzeichen ein Feldseparator. Überbigt man "ab cd ef"
> wird ein Vektor mit den drei Elementen "ab", "cd" und "ef" gebildet.
> Werden der Bash so Dateinamen überreicht, gibt es auch Probleme mit
> Leerzeichen in Dateinamen. Diese umgeht man durch Ändern des
> Feldseparators, z.B. setzt man den Linefeed (kommt in der Regel nicht in
> Dateinamen vor). Arbeitet ein Programm so (*.jpg wird zu allen passenden
> Dateinamen erweitert und ein Vektor gebildet, wobei ein Leerzeichen die
> Elemente trennt), kann man das nur ändern, indem man es in einer
> Schleife aufruft und stets nur einen Dateinamen überreicht.
Also, als ich zuletzt programmiert habe (okay, ist ein bisschen her),
war letzteres die uebliche Logik, zumal sie direkt auf Betriebssystem-
funktionen aufsetzen kann. Eigentlich erwarte ich aber, dass Software
gaengige Dinge wie Jokerzeichen abfangen kann. Ist ja nun nichts weiter
exotisches. Aber sei's drum, dafuer habe ich ja den genannten workaround
mit den Kurznamen gefunden. Ist good ol'DOS doch noch zu was nuetze. <8)
> Wenn du mit der aktuellen Lösung zufrieden bist (XnView + SendTo), gibt
> es eigentlich keinen Grund, diese Vermutung zu überprüfen.
Wie beschrieben hat jede Loesung ihre kleinen Macken, aber es laeuft
hinreichend. Anstatt IM-convert benutze ich jetzt nconvert von der
XnView-Website. Etwas eigenwillige Syntax, tut's aber gut und bietet ein
paar nette Goodies. Man kann etwa im Ausgabedateinamen den Namen der
Ursprungsdatei einbinden, ebenso das Ursprungsverzeichnis, und sogar
einen konfigurierbaren Zaehler. 8-)
Jedenfalls liegen nunmehr verschiedene Scripts vor, die sich in SendTo
(oder auch direkt weiter oben in Kontextmenue) einbinden lassen, wie
auch in XnView und Exifer. Interessant dabei BTW die unterschiedliche
Handhabung seitens dieser Programme: sind n Dateien markiert, generiert
XnView nacheinander n Aufrufe des Scripts mit jeweils einem uebergebenen
Dateinnamen. Exifer verwirft Mehrfachmarkierungen und uebergibt grund-
saetzlich nur *einen* Dateinamen, und der Explorer uebergibt saemtliche
markierten Dateien als Parameter 1 bis n. Was man nicht so alles heraus-
findet... #-)
Dieter