Patch exif data for Sigma Lens

Non Canon lenses can be great or even better than the one provided by Canon itself (i.e the Sigma 50mm f/1.4 DG HSM Art). The only problem you have is that theses lenses are not natively recognized by your camera body. In Adobe Lightroom instead of getting a nice description of the lens used to shot the given picture as you can see below

EF50mm1_2

you get a super generic info like 50mm as you can see below

DG50mm1_4

This is of course not nice at all and we should be able to do better than that.

Ideally you should be able to tell Lightroom to overwrite meta-data during import and replace them by some new ones. Lightroom is however unable to do that. It’s equally unable to run any king of user defined script after import. The solution comes from Automator. I have experienced with folder actions and it was no good. Action may take far to long to be triggered (sometimes more that two minutes after folder modification) and, worse than all, modifications are lost after reboot. So I decided to go for a automator service workflow.

This workflow use a command line tool called ExifTool and can be called either on a folder or on a file. It logs in selected folder or at the same place as the processed files. It only modify the tags of corresponding files (so no need to remember which picture was taken with which lens). I recommand you not to modify directly the file on the SD card because if something goes wrong your original are gone. Instead I personally first copy the picture to a staging folder, call the service and finally import into Lightroom. In theory you could import and then call the service, but this will be awfully slow because all of the files in the same folder would be checked against the filter “Sigma”. On top of that you would also have to re-synchronize you Lightroom library as the Exif data are only read during import.

All that being said here’s the Automator workflow:

wf_screenshot

and the bash shell script code:

1
2
3
4
5
6
7
8
9
10
11
12
if [[ -d $1 ]]; then
	LOG_FILE="$1/tag_sigma.log"
else
	LOG_FILE="$(dirname $1)/tag_sigma.log"
fi
echo "start processing at: $(date)" >> $LOG_FILE
for f in "$@"
do
	exiftool -overwrite_original -P -q -lensmodel="DG50mm f/1.4 HSM | A" -lensserialnumber="XXXXXXXX" -if '$lensid eq "Sigma 50mm f/1.4 DG HSM | A"' -v0 "$f" >> $LOG_FILE
done
echo "======== file(s) were processed" >> $LOG_FILE
echo "end processing at: $(date)" >> $LOG_FILE

As you can see the script also tags the lens serial number (see “XXXXXXXX”) which is otherwise reported as “00000000” and is specifically looking for the DG 50mm 1.4 HSM Art lens. It can however easily be modified to match your own lens(es).

Script: tag_sigma_exp.workflow

Always have a nice print template on the web

I just found Printfriendly that allow me to have just the print template I want: with or without comments, with or without images, without the annoying side bar and so much more.

Check yourself on your favorite website. Look at what you get on a fairly complex site like arstechnica.com.

As I also just remark that this blog is far from perfect when it comes to printing, I have installed the printfriendly plugin. If you click on a specific post, you will now see on the bottom left a print button.

How to use a proxy and force fetching the latest data

I just recently had a problem using a Java URLConnection behind a proxy and forcing the connection to get the latest available data on the server and not the one cached by the proxy. The following code snippet demonstrate how to do that.

10
11
12
13
URL metarUrl = new URL("ftp://tgftp.nws.noaa.gov:21/data/observations/metar/stations/LSGG.TXT");
Proxy myProxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("www.myproxy.ch", 8080));
URLConnection metarConnection = metarUrl.openConnection(myProxy);
metarConnection.setDefaultUseCaches(false);

Word Backup

A little bit of history (Word 5.1 1992)

With Microsoft Word 5 there was a small little option that allows you to tell Word to save every open document at a regular time interval (15 minutes for example). How this functionality was implemented was trivial. It only performed a regular “Save” or “Save As…” at the parameterized time interval. This worked nicely and everything was in order.

With such an implementation two goals where reached:

  • If the Word crashed, you will have, in the worst case, lost 15 minutes of work
  • If you made a mistake and forget to save your work, you will have, in the worst case, lost 15 minutes of work

Current time (Word 2008)

Somewhere in-between Word 5.1 and Word 2008 (I cannot say more precisely, because here, at home, we had such an upgrade path), this functionality didn’t disappear but the implementation changed. Now this functionality has been splited in two parts.

  • The first one being fairly useless and called “Always create a backup copy” which as the name says only create a “Backup Copy of <your_document_name>” file for every document you created.
  • The second one being “Save AutoRecovery info every:”. This option allows Microsoft Word to recover a file after a crash.

Everything seems to be in order, except that now we don’t have a protection against the user who quit Word without saving his whole day work (Yes it can happen, believe me).

Word Backup

Having recognized the problem and noticed that there is no “ready-to-use” solution, I decided to create a palliative solution. The provided piece of software reintroduces the old behavior of Word 5 with the newest version of it. An additional benefit of this script, when run on Mac OS X 10.5 or 10.6, is that you not only have access to the latest backup version but also to the history of it thanks to Time Machine.

Download

WordBackup 1.0

WordBackup 1.1

[update]The new version provided, logs the saved documents’ name under /Library/Logs/WordBackup.log[/update]

Paralles Desktop 4

The software that I’ll definitively not recommend you. The question is why? Because:

  • With version 3 and 4, I were not able to use it easily with my bootcamp partition (see here).
  • The support was with version 3 non existant (an email posted on 8 july 2007 is still unanswered) and with version 4 still have no clue, after more than 6 months of availability, of basic problems.
  • The company does not seems to improve its product but to add as much as possible features even if still in “beta” stage.
  • The software engineers still don’t know to programm an application that is location independant.
  • The software engineers aren’t able to write meaningfull error messages

image1lauWhat do you think that such a message can be meaning. Of course that the location of your currently installed application is not ok.

In any case I would recommend you to use VMWare that works a lot better (according to my test) or VirtualBox.

Virtual box is becoming definitively an interesting alternative. It’s free, it works without hitch with Windows 7 and Open Solaris. The only point is that you cannot move the application away from the /Application directory (yes it’s one reason because I dismissed Parallels, but VirtualBox is free and comes from Unix System).

Genève Zürich par le Jura

_mg_4332

  • Genève
  • Col de la Faucille
  • La Cure
  • Le Sentier
  • Le Pont
  • Vallorbe
  • Pontarlier
  • La Brévine
  • Le Locle
  • La Chaux-de-Fonds
  • St-Imier
  • Tavannes
  • Moutier
  • Balstahl
  • Zofingen
  • Sursee
  • Beromünster
  • Muri
  • Affoltern am Albis
  • Zürich

Total: 356 Km parcourus en l’espace de 9h environ avec une bonne heure de pause à midi.