Tag: Image

“bad subifd directory” Replacing/removing bad SubIFD

Handling bad SubIFD entries in photos you want to geo tag / the problem

I just converted some of my RAW photos in RawTherapee and polished them in Photoshop CS. Of course I also wanted to GeoTag them (using GeoSetter) before putting the images in my archive. Fortunately, a GPS point was found in my trace for all photos. Unfortunately, I couldn’t write the Exif-GPS position due to a “bad subifd directory”. That’s what exiftool (which geosetter uses) tells me.

So – how to get the geo information into exif – or how to get the bad SubIFD directory out?

The solution:

In the end the issue was rather easy to solve:

  1. copy your images to a linux machine (or vm or whatever)
  2. copy all images to a directory “conv” AND in parallel to “conv2“
  3. enter “conv2“
  4. remove all exif information from the conv2 images by
    find ./*.jpg -exec exiftool -exif:all= {} ;
  5. enter “conv1” & copy the exif information (except SubIFD) to the cleaned images in “conv2” by
    find ./*.jpg -exec exiftool -tagsfromfile {} -exif:all --subifd:all ../conv2/{};
  6. you’re done.
  7. (fire up geo setter and geo tag your photos)

Be happy!

Finished my Posters for ICIP and MICCAI

Finally finished the posters for my publications:

F. Graf, H.-P. Kriegel, M. Schubert, S. Poelsterl, A. Cavallaro
2D Image Registration in CT Images using Radial Image Descriptors
In Medical Image Computing and Computer-Assisted Intervention (MICCAI), Toronto, Canada, 2011.

and

F. Graf, H.-P. Kriegel, M. Weiler
Robust Segmentation of Relevant Regions in Low Depth of Field Images
In Proceedings of the IEEE International Conference on Image Processing (ICIP), Brussels, Belgium, 2011.

Robust Segmentation of Relevant Regions in Low Depth of Field Images

Great, we got accepted (as a poster) on the ICIP 2011 with the paper “Robust Segmentation of Relevant Regions in Low Depth of Field Images”:

Low depth of field (DOF) is an important technique to emphasize the object of interest (OOI) within an image. When viewing a low depth of field image, the viewer implicitly segments the image into region of interest and non regions of interest which has major impact on the perception of the image. Thus, robust algorithms for the detection of the OOI in low DOF images provide valuable information for subsequent image processing and image retrieval. In this paper we propose a robust and parameterless algorithm for the fully automatic segmentation of low depth of field images. We compare our method with three similar methods and show the superior robustness even though our algorithm does not require any parameters to be set by hand. The experiments are conducted on a real world data set with high and low depth of field images. (Abstract from the paper)

The work is a result of a collaboration with Michael Weiler. We extended his Diploma thesis and produced an improved segmentation algorithm for Low Depth Of Field images. Compared to the other 3 competing algorithms, ours is a bit slower but at least it works. The other algorithms turned out to be extremely unstable and/or sensitive to parameters.

On the project site you can find

  • an online demo
  • the test images,
  • the masks
  • the NetBeans project including the full Java source code for our algorithm and the reimplementation of the comparison partners (of course we had to re-implement as we didn’t even get binaries – as usual)

So if you plan to do some image segmentation, just go there download the stuff and cite our work 😉

Imagero: EXIF Rotation Tag schreiben

Mit Imagero 329 hat folgender Java Code seltsamerweise eine NullpointerException geliefert. Mit der aktuellen Imagero Version 429 kann man das EXIF-Rotations Tag problemlos schreiben und damit JPEGs verlostlos und schnell drehen. Mit (oder bis) Version 423 wurde unter bestimmten Umständen das Orientation Tag doppelt geschrieben.

IOParameterBlock iopb = new IOParameterBlock(src);
iopb.setDestination(src);
JpegFile reader = (JpegFile) new ImageProcOptions(iopb).imageFile;
ExifApp1 app1 = (ExifApp1) reader.jmr.getMarker(ExifApp1.NAME, 0);
if (app1 == null) { // falls das Bild noch keine EXIF Daten enthält
    EXIF exif = new EXIF(new ImageFileDirectory());
    exif.set.orientation(Orientation.TOP_LEFT);
    MetadataUtils.insert(reader, new Marker[]{exif.createMarker()}, iopb);
} else { // Falls schon EXIF Daten im Bild sind
    app1.getExif().set.orientation(Orientation.TOP_LEFT);
    reader.saveImage(iopb);
}
iopb.close();

Orientation.TOP_LEFT steht dabei für die Ausrichtung. Zum Drehen sind die folgenden Werte relevant:

  • 0°: Orientation.TOP_LEFT
  • 180°: Orientation.BOTTOM_RIGHT
  • 90°: Orientation.RIGHT_TOP
  • 270°: Orientation.LEFT_BOTTOM

Daneben gibt es noch 4 weitere Werte, die das Bild entsprechend drehen und spiegeln:

  1        2       3      4         5            6           7          8

888888  888888      88  88      8888888888  88                  88  8888888888
88          88      88  88      88  88      88  88          88  88      88  88
8888      8888    8888  8888    88          8888888888  8888888888          88
88          88      88  88
88          88  888888  888888

Wobei 1-8 derart definiert ist:

The orientation of the camera relative to the scene, when the image was captured. The relation of the ‘0th row’ and ‘0th column’ to visual position is shown as below.

Value 0th Row 0th Column
1 top left side
2 top right side
3 bottom right side
4 bottom left side
5 left side top
6 right side top
7 right side bottom
8 left side bottom

Relavante Links:

JPEG Rotation and EXIF Orientation

IPTC-Tags mit Imagero schreiben

Mit folgendem Java Code kann man mit Imagero (Version 398) ein IPTC-Feld (hier: Keyword) schreiben. Ist der Keywords-Eintrag im Bild noch nicht vorhanden, wird er erstellt, andernfalls wird “foo” der Liste hinzugefügt.

public class TestImagero {
    public static void main(String[] args) throws Exception {
        LicenseManager.install(new FranzGraf());
        String src = "a.JPG";
        IOParameterBlock iopb = new IOParameterBlock(src);
        IOParameterBlock iopbDst = new IOParameterBlock(src).setDestination(src);
        IPTCEntryCollection iec = MetadataUtils.getIPTC(iopb);
        iec.addEntry(IPTCEntryMeta.KEYWORDS, "foo".getBytes());
        MetadataUtils.insertIPTC(iec, iopbDst);
        iopb.close();
        iopbDst.close();
    }
}

Einen Eintrag namens “foo_2” entfernt man aus den Keywords folgendermaßen:

            IOParameterBlock iopb = new IOParameterBlock(src);
            IOParameterBlock iopbDst = new IOParameterBlock(src).setDestination(src);
            IPTCEntryCollection iec = MetadataUtils.getIPTC(iopb);
            IPTCEntry[] entries = iec.getEntries(IPTCEntryMeta.KEYWORDS);
            List removes = new ArrayList();
            for (IPTCEntry entry : entries) {
                if (new String(entry.getData()).equals("foo_2")) {
                    removes.add(entry);
                }
            }
            for (IPTCEntry rem : removes) {
                System.out.println(iec.removeEntry(rem));
            }
            MetadataUtils.insertIPTC(iec, iopbDst);
            iopb.close();
            iopbDst.close();

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();

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.

Autostitch: Format der pano.txt

Gerade Autostitch ausprobiert. Und siehe da: die Panos sind besser als die von meiner alten Canon Stitch-Software.

Aber: Der Ram-Verbrauch von autostitch ist brachial. Ich wollte 5 Fotos à 4592*3056 Pixel zusammenstitchen. Natürlich sollte das Ausgabefoto auch ca 3000Pixel hoch sein. Nur reichten dazu die mir zur Verfügung stehenden 2GB leider nicht aus(?!). 2500px Höhe gingen dann gerade noch.

Da autostitch ja netterweise eine pano.txt anlegt, in der die Transformationsdaten stehen, ist die Versuchung gerade groß, das selbst auszuprobieren. – Wenn mal Zeit ist vielleicht …

Dokumentation der pano.txt:

The format of pano.txt is:

filename
width height
T (3 x 3)
R (3 x 3)
f
…

so that the projection matrix for each image (original size) is:

P = T * K(f) * R

where K(f) = [ f 0 0; 0 f 0; 0 0 1]

The homography between a pair of images is

s * [r_2, c_2, 1] = P_2 * inv(P_1) * [r_1, c_1, 1]

where r is the row coordinate and c is the column.

The demo version renders panoramas in spherical coordinates theta VS
phi (longitude/latitude). You can get the theta/phi ranges from
Edit->Options after stitching. The relationships between theta/phi and
image coordinates are:

s * [r, c, 1] = P * X

where

X = [ -sin(phi); cos(phi)sin(theta); cos(phi)cos(theta) ]

How to load images in Java

Every once in a while there is a question on the NetBeans mailinglist about how to load an image (or other ressource, like a text file) relative to the executing JAR.

The Java Tutorial gives the answer in the chapter “How to use Icons“:

java.net.URL imgURL = getClass().getResource("inSamePackage.png");
java.net.URL imgURL = getClass().getResource("/de/foo/otherPackage.png");

Continue reading How to load images in Java

Java Library for reading & writing EXIF, XMP and IPTC in JPEGs

Finally it seems that I’ve found a pure Java Library that can read and write XMP Data to and from JPEGs!

In the past time I’ve been googling for such a library repeatedly. There are quite some libraries for just reading EXIF or IPTC data. Amongst others are Drew Noakes’ library and Imagero. As I am on the verge of adding more metadata functionality to my self-made image database I had 2 issues:

  1. A decision of how to store labels and descriptions to images: a database only without touching the images or IPTC, XMP within images (with cached information to a database). Finally I decided that I wanted to use XMP(or IPTC so that the information is kept close to the image.
  2. A library for this!

What I’ve found so far (incomplete listing as I came across QUITE some libs for reading data):

Imagero and Drew Noakes: Until now I was using Drew Noakes library for reding EXIF data – which was absolutely okay but couldn’t write any data 🙁 Imagero supports writing of IPTC and XMP (from what I’ve read) and is even free for non-commercial usage. But it’s not true open source and you need to request a licence every year (which works w/out problems!). Judging the work Andrey Kusnetsov (maintainer of Imagero) is putting into it I think, that’s quite acceptable.

Adobe XMP SDK: Adobe – as the inventor of XMP – has released an SDK for reading/writing XMP. Most of the SDK is written in C, the SDK Core is also available in Java (great!) but the functionality to get and write the XMP to and from files .. is not available as Java. Quite annoying.

Apache Sanselan: When searching for Apache Sanselan you most likely end up at the incubator-site which says that the project is in the stat of migrating into apache – the mailinglist also doesn’t work. The simple reason: Sanselan is already a part of Apache Commons. So, this new link is the place to go. The most interesting thing of Sanselan is the format support:

  • JPEG IPTC support: read (yes), write (soon), Can read IPTC data from exsiting JPEG/JFIF files WITHOUT modifying image data.
  • JPEG EXIF: read (yes), write (yes), Can read and write EXIF data to and from exsiting JPEG/JFIF files WITHOUT modifying image data.
  • XMP: read (yes), write (yes), Can read XMP XML (as as String) from […] JPEG […]. Can remove, insert and update XMP XML into existing JPEG files.

Update: the downside of Sanselan is that development seems to have stalled. The current release is 0.97 from February 14th, 2009. :-(((