Sinn und Unsinn von E-Mail- und Link-Disclaimern

Wieder eine Mail erhalten mit dem zweifelhaften Text

Diese E-Mail und alle angehängten Dateien enthalten streng vertrauliche Informationen und sind lediglich für den/die in der Adressleiste genannte(n) Person(en) bestimmt. Sollte diese E-Mail bzw. deren Anhänge an Dritte und/oder nicht in der Adressleiste genannte Personen gelangen,  [...]

Ich hab’ diesem Disclaimern ja noch nie wirklich vertraut. Ein Artikel bei heise (Disclaimer: Unnötiger Ballast für E-Mails) bestätigt die Vermutung, dass diese Disclaimer bei uns in Deutschland nicht wirksam sind. – Ebenso wie diese widersinnigen Distanzierungen von Links:

Mit Urteil vom 12. Mai 1998 hat das Landgericht Hamburg entschieden, daß man durch die Ausbringung eines Links [...]

Auch hier gibt es eigentlich diverse Seiten, die erklären, dass das Urteil vom LG Hamburg eben genau das nicht tut, was die Links versprechen: und zwar den Seitenbetreiber schützen. Mehr Informationen gibt es unter anderem auf diesen Seiten:

• Wikipedia: Haftung für Hyperlinks
• Das Märchen vom Linkurteil
• Wirksamkeit von Disclaimern
• Warum Discalimer dem WWW schaden
• Kanzlei Jörg Heidreich: Zur Wirksamkeit von Web-Disclaimern und ix Artikel: Fußangeln (iX 08/2002, Seite 88)
• Kanzlei Martin Beukenberg: Disclaimer

Imagero und Vendor Notes / Fazit

Nachdem ich gestern schon geschrieben hatte, dass Sanselan Probleme mit den Venoder Notes /Maker Notes hat, hab ich mir  kurz  Imagero angeschaut. Kurzer Test um das Orientierung-Tag in JPEGs neu zu setzen führte dann aber zur leichten Ernüchterung:

Mit dem Code unten werden die Vendor Notes nicht falsch geschrieben – sondern gar nicht

    public static void main(String[] args) throws IOException {
        LicenseManager.install(new FranzGraf());
        String src = "C:\\temp\\src1.jpg";
        String dst = "C:\\temp\\src2.jpg";

        IOParameterBlock iopb = new IOParameterBlock(src);
        iopb.setDestination(dst);
        ImageProcOptions options = new ImageProcOptions(iopb);
        JpegFile reader = (JpegFile) options.imageFile;
        ExifApp1 app1 = (ExifApp1) reader.jmr.getMarker(ExifApp1.NAME, 0);
        if (app1 != null) {
            app1.getExif().set.orientation(Orientation.LEFT_BOTTOM);
            reader.saveImage(iopb);
        }
        iopb.close();
    }

Jetzt wollte ich eigentlich noch im Forum nachfragen, ob ich das nicht vielleicht anders machen muss – allerdings ist die Freischaltung leider noch nicht erfolgt. Letztlich ist das aber auch wieder nicht die Schuld von Imagero oder Java selbst. Es scheint ja auch nicht umsonst ein TIFF MakerNoteSafety-Tag zu geben. Ich habe mich auch kurz mit Elmar Baumann unterhalten, der in JPhotoTagger dasselbe Problem hatte. Also doch besser, EXIF und IPTC nur lesen und die Infos in Datenbank und XMP abzulegen? (Das zeigt einmal mehr den Nachteil von proprietären Formaten).

Prinzipiell ist die Idee super, die Originaldateien unangetastet zu lassen und sonst alles in XMP-Dateien abzulegen. Aber halt: wenn ich unterwegs bin, zeichne ich den Weg mit meinem GPS-Logger auf und geotagge meine Bilder anschließend mit locr. – Und spätestens danach sind die MakerNotes eh schon weg. Also ist die Entscheidung nach der “richtigen” Lib wieder zurück auf Start, wie schon im früheren Artikel:

• Drew Noakes: IPTC/EXIF lesen/nicht schreiben, open source
• Imagero: IPTX/EXIF/XMP lesen/schreiben, kostenlos für nichtkommerzeille Nutzung, nicht open source, wird aber weiterentwickelt!
• Adobe XMP SDK: nicht ausreichend für Java verfügbar
• Apache Sanselan: IPTC lesen/schreiben(bald?), EXIF lesen/schreiben, XMP lesen/schreiben, open source, aber derzeit aber offenbar nicht wirklich  gewartet, so dass auch Bugs nicht gefixed werden, für die schon ein Patch existiert (siehe hier).

Will man also das volle Paket EXIF/IPTC/XMP mindestens lesen, bleibt man bei Sanselan vs. Imagero:

	open source	aktuell	Kosten
Imagero	nein	ja	frei für nicht-kommerziell
Sanselan	ja	nein	frei

IOParameterBlock iopb = new IOParameterBlock(src);
iopb.setDestination(dst);
ImageProcOptions options = new ImageProcOptions(iopb);
JpegFile reader = (JpegFile) options.imageFile;
ExifApp1 app1 = (ExifApp1) reader.jmr.getMarker(ExifApp1.NAME, 0);
if (app1 != null) {
app1.getExif().set.orientation(Orientation.LEFT_BOTTOM);
reader.saveImage(iopb);
}
iopb.close();

Wegpunkte mit JXMapKit zeichnen

Im Artikel “Erste Schritte mit JavaX JXMapKit” habe ich schon kurz beschrieben, wie man mit NetBeans und SwingX-WS schnell und einfach eine Kartendarestllung á la GoogleMaps in Java bauen kann.

Wenn man nicht nur eine Karte anzeigen sondern auch Punkte einzeichnen will, hat man die Möglichkeiten, per jXMapKit.setAddressLocation(new GeoPosition(lat, lon)); die Koordinaten setzen, zeichnen und die Karte dorthin zentrieren. Allerdings wird die Karte damit auch immer gleich zentriert und vor allem kann man nur einen einzelnen Punkt setzen.

Mehrere Wegpunkte setzt man mithilfe des WaypointPainters:

Set set = new HashSet(); 
WaypointPainter waypointPainter = new WaypointPainter(); 
waypointPainter.setWaypoints(set); 
set.add(new Waypoint(47.76098, 11.55932)); 
jXMapKit.getMainMap().setOverlayPainter(waypointPainter); 
repaint();

Das repaint() am Ende sollte immer erfolgen, wenn neue Punkte in das Set gesetzt werden, damit die Änderung auch sofort sichtbar ist. Andernfalls muss man die Karte etwas verschieben um ein repaint zu erzwingen. Will man jetzt noch die Darstellung der Wegpunkte verändern, muss man sich noch mit dem WaypointRenderer beschäftigen.

Java Heap-Implementierung / Avoid too much sorting II

Im Artikel Avoid too much sorting habe ich ja schon kurz skizziert, dass man es generell vermeiden sollte seine Daten unnötig oft zu sortieren, weil das einfach (je nachdem wie oft der entsprechende Code aufgerufen wird) ziemlich in die Rechenzeit gehen kann.

Manchmal muss man seine Daten aber eben sortiert halten. – Dann sollte man sich aber überlegen, ob man wirklich die ganzen Daten sortieren muss, oder ob es nicht einfach reicht, immer das kleinste/größte Element einer Menge zu bekommen. Ein gutes Beispiel ist zum Beispiel der altbekannte Dijkstra-Algorithmus. Dort benötigt man in jeder Iteration z.B. den Weg mit den bisher kleinsten Kosten.

Das schreit ja schon nach Sortieren. Bzw. eigentlich sollte einem da gleich die Heap-Datenstruktur einfallen, da dort alle Operaionen maximal in O(log n) erledigt sind, und nicht (wie beim Sortieren) in bis zu O(n²). Das schöne daran ist, dass es das in Java auch schon gibt, da heißt es nur nicht Heap (da man dabei vermutlich zu sehr an die Speicherverwaltung denken könnte), sondern PriorityQueue.

Wenn man jetzt aber Objekte sortieren will die nicht per se Comparable sind, benötigt man noch eine kleine Comparator-Implementierung mit einem SimpleEntry, damit man einem beliebigem Objekt auch seine Kosten zuweisen kann. Klingt jetzt recht aufwändig – ist es aber bei weitem nicht:

import java.util.AbstractMap.SimpleEntry;
import java.util.Comparator;
import java.util.PriorityQueue;

public class Test {
    public static void main(String[] args) {
        PriorityQueue<SimpleEntry> heap =
                new PriorityQueue<SimpleEntry>(10, new FooCmp());
        heap.add(new SimpleEntry(1d, new Foo(1)));
        heap.add(new SimpleEntry(5d, new Foo(2)));
        heap.add(new SimpleEntry(2d, new Foo(3)));
        while (!heap.isEmpty()) {
            System.out.println(heap.poll().getValue().i);
        }
    }
}

class FooCmp implements Comparator<SimpleEntry> {
    @Override
    public int compare(SimpleEntry o1, SimpleEntry o2) {
        return Double.compare(o1.getKey(), o2.getKey());
    }
}

class Foo {
    int i;
    Foo(int i) { this.i = i; }
}

Sanselan und Vendor Notes

Metadaten in Bildern sind in Java scheinbar echt gar nicht so einfach.  In einem früheren Artikel habe ich kurz aufgelistet, welche Metadata-Libraries ich immerhin schon mal ausgemacht habe. – Sanselan sah da ja schon gar nicht schlecht aus.

Bei einem ersten Test bin ich dann aber darauf gestoßen, dass scheinbar die Vendor Notes echte Probleme bereiten können. Ich wollte eigentlich nur die Exif-Daten auslesen und in eine andere Datei kopieren. Die eigentlichen Exif-Daten waren alle super. Die Vendor-Notes meiner Sony Alpha 350 sahen auch ganz gut aus (keine genauen Vergleiche) – ein Bild einer Canon Powershot A570 IS war schon anspruchsvoller. Ca. die Hälfte der Vendor-Notes waren verändert bis unbrauchbar

Brav wie ich bin, erst mal auf der Mailingliste nachgefragt… keine Antwort – hm. Also mal brav einen Bug eröffnet. Und danach gesehen, dass das Verhalten in der Doku quasi schon angekündigt ist:

Note that this uses the “Lossless” approach – in order to preserve data embedded in the EXIF segment that it can’t parse (such as Maker Notes), this algorithm avoids overwriting any part of the original segment that it couldn’t parse. This can cause the EXIF segment to grow with each update, which is a serious issue, since all EXIF data must fit in a single APP1 segment of the Jpeg image.
http://commons.apache.org/sanselan/api-release/org/apache/sanselan/formats/jpeg/exifRewrite/ExifRewriter.html

Tjo. Blöd. Klar Blöd auch von den Kameraherstellern, dass diese Einträge proprietär sind – aber noch dümmer, dass es unter Windows gefühlte 10.000 Programme gibt, die die Exif-Daten einfach ändern können und sich das mit Java langsam echt zu einem ernsthaften Problem auswächst.

Als nächstes versuche ich jetzt Imagero, der ist zwar nicht frei, aber vielleicht geht’s da wenigstens.