Category: HowTos

Stuff that was hard to find but very helpfull.

Windows 7 (64bit) Druckerfreigabe mit XP Client (Canon i250)

Szenario:
An einem Windows 7, 64 Bit, soll der angeschlossenem Drucker über das Netz freigegeben werden.
Ein Windows XP, 32Bit, soll die Freigabe in Anspruch nehmen.

Problem:
Beim Verbinden des Druckers wird auf Windows XP-Seite eine Warnung ausgegeben, dass der Server keine Treiber zur Verfügung stellt.

Lösung:
Wie erwartet war ich nicht der einzige mit dem Problem. Die Lösung fand ich dann im computerbase-Forum.
Im Prinzip muss man Windows 7 “nur” beibringen, dass es auch einen 32Bit-Treiber anbieten soll.  Das funktioniert so, dass man den Windows 32bit-Treiber vom Druckerhersteller herunterlädt und am Drucker registriert: “Geräte und Drucker – *Druckername* – Druckereigenschaften – Freigabe – Zusätzliche Treiber”.

In der Praxis kommt es dann ab und an vor, dass genau das nicht funktioniert, weil der Drucker dann nicht gefunden werden kann und man eine Meldung erhält, dass kein Treiber für <Druckername> gefunden werden konnte. Wie im computerbase-Forum beschrieben, ist hier Handarbeit nötig. Die entpackten Treiber enthalten eine .inf-Datei. Diese muss man im Texteditor öffnen und den Druckernamen so abändern, dass der Name identisch mit dem Windows7-Druckernamen ist (also genau der Name, der in der Fehlermeldung genannt ist).

Im Falle meines Canon i250 sehen die betreffenden Zeilen der .inf-Datei dann so aus:

;WindowsXP
[Canon.NTx86.5.1]
"Canon Inkjet i250" = CNMI250XP, LPTENUMCanoni250F027, Canoni250
"Canon Inkjet i250" = CNMI250XP, USBPRINTCanoni250F027, Canoni250

“Canon Inkjet i250” ist dabei der Name des Druckers in Windows 7. Datei speichern und nochmal via “Geräte und Drucker – *Druckername* – Druckereigenschaften – Freigabe – Zusätzliche Treiber” installieren. Sofern das funktioniert, kann man den Drucker dann (sofern die Freigabe richtig eingestellt wurde) von Windows XP aus nutzen.

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.

JXMapKit: Karten schneller und gleichzeitig laden

Verschiebt man die Karte eines JXMapKit, müssen ja logischerweise Kartenteile (Kacheln) nachgeladen werden.
Per Default werden immer nur 4 Kacheln gleichzeitg geladen. Bei entsprechend schneller Verbindung macht es durchaus Sinn, diese Zahl zu erhöhen:

((AbstractTileFactory) jXMapKit.getMainMap().getTileFactory()).setThreadPoolSize(10);

Und schon wird spürbar schneller nachgeladen. Allerdings muss der Aufruf durchgeführt werden, bevor die erste Kachel geladen wird, wie die Javadoc aussagt:

/**
* Set the number of threads to use for loading the tiles. This controls the number of threads
* used by the ExecutorService returned from getService(). Note, this method should
* be called before loading the first tile. Calls after the first tile are loaded will
* have no effect by default.
* @param size
*/

Siehe auch: “Erste Schritte mit JavaX JXMapKit“

How to use TableModels and ListModel with NetBeans GUI Builder

A default JTable or JList comes with it’s own pre initalized model. Okay – but: how can we modify this model? Which type of model is usually pre initialized?
In the following I’ll just list some of the may possible ways to work with tables and lists and the NetBeans Gui Builder:
Continue reading How to use TableModels and ListModel with NetBeans GUI Builder

java.sql.SQLException: No suitable driver found for ‘jdbc:derby:…

Kleine Gemeinheit im “Using dblook” guide (Übersichtslink):

dblook -verbose -d ‘jdbc:derby:pathToDBDBName’

— Zeitmarke: 2010-01-04 12:27:34.578
— Quellendatenbank: pathToDBDBName
— Verbindungs-URL: ‘jdbc:derby:pathToDBDBName
— appendLogs: false

java.sql.SQLException: No suitable driver found for ‘jdbc:derby:pathToDBDBName
at java.sql.DriverManager.getConnection(DriverManager.java:602)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
at org.apache.derby.tools.dblook.go(Unknown Source)
at org.apache.derby.tools.dblook.(Unknown Source)
at org.apache.derby.tools.dblook.main(Unknown Source)
— **–> DEBUG: No suitable driver found for ‘jdbc:derby:pathToDBDBName

(Fast) Derselbe Aufruf geht via ij und NetBeans …

Lösung: dblook -d jdbc:derby:pathToDBDBName
Unterschied: einfach ohne die ‘Hochkommata‘, auch wenn es im Guide immer wieder mal mit Gänsefüßchen steht.

Escape analysis, Lock Coarsening und Biased locking

Die Ausgabe 179 des “The Java Specialists’ Newsletter” stellt ein paar interessante – wenn auch noch experimentelle – Features der Server-VM vor:

Escape analysis: Damit kann die JVM prüfen, ob ein Objekt einen bestimmten Scope nicht verlässt (z.B. nur in einer Methode verwendet wird) und dieses Objekt dann direkt auf dem Stack anlegen.

Lock Coarsening: Fordert ein Thread aufeinanderfolgend mehrere Locks auf ein Objekt an und gibt sie dann wieder frei (wie z.B. bei der Verwendung von Vector), kann die JVM diese wiederholten, teuren Anfragen zu einem lock/release zusammenfassen,

Biased locking: Wird ein Objekt von nur einem Thread ge’lock’ed, kann auf die Sperre ebenso verzichtet werden.

Im The Java Specialists’ Newsletter werden einige eindrucksvolle MicroBenchmarks gezeigt, die einiges an Performance bringen können. Aber: es sind nur MicroBenchmarks, die den Effekt sehr gut zeigen. In komplexen Applikationen kann der Benefit natürlich deutlich schlechter ausfallen. Soweit ich das aus anderen Seiten gelesen habe, sind die Optionen derzeit noch als experimentell zu betrachten – aber sie sind schon ein schöner Vorgeschmack.

Ein sehr schönes Statement im Zusammenhang mit Performance Tuning, das den Nagel auf den Kopf trifft: “Assumption is the mother of all f* ups”. Der Spruch drückt sehr schön das aus, was ich bei Performance-Optimierungen immer wieder sage: Erst Messen, dann Tunen. Und niemals Tunen ohne zu Messen. Andernfalls kann man schnell mal Stunden damit zubringen, ein Programmstück auf 5% Ausführungszeit zu drücken … das aber in der Gesamtausführung nahezu keine Zeit verbraucht – womit die Verbesserung quasi nicht existent ist. Oder schlimmer: man denkt, ein Programmteil wäre langsam, optimiert aber erfolglos an der Ursache vorbei.

Relevante Links:

http://profiler.netbeans.org/