Nikon D70s/D80/D300/D800/D810/D850 and Linux

On Sept 1, 2006, just about a week before the D80 came out here, I got a Nikon D70s. Since I'm still using linux, I've gathered some useful tips below as well. On Jan 27, 2007 I replaced the D70s with the D80. Very nice as well. On May 16, 2008 replace that one with a D300. Also nice. Nikon plays well with linux (but caveats below). Firmware upgrades are simply done by placing the right two files (A and B) in the root directory of the flash card and hitting the right menu button on the camera. Just remember you first do the A, upgrade, delete it, and then the B. Otherwise it won't work right. MSC (mass storage) mode ensures that a USB cable will see the camera like a hard drive. The PTP mode also works, so is the claim, i've not tried that. Using RAW (NEF) is also easy, the new 14bit option seems to work as fine as the old 12bit option. I use it in a gimp plugin (ufraw).

Sample picture from D800(click to enlarge to full size)

In May 2012 a brand new D800 arrived. Quirky thing, it has a split USB (usb 3.0?) port that does not yet seem to play nice with linux. That, and the reason that I was fed up with the D300 rubber door to the USB port not wanting to shut (rubber seems to expand after a year of use, and i was already on my second kit), I am now taking out the SD/CF cards and using them using an adaptor. The word on the street is that this is just as ok.

On Jul 22 2014 the D810 arrived. With later models my earlier statement that Nikons plays nice with Linux should be toned down: their firmware upgrades are EXE or DMG files. Now how much more platform specific can you get? Seriously, they cannot just give us a single ZIP file. All three platforms can deal with that. Brain dead, I have some solutions below. The USB3 port on the D800/D810 has has some standards issue, so I just just the cards. The raw (NEF) files for the D810 are only recently supported, but the commercial software had the same issues. Nikon could improve there as well by delivering sample NEF files to the community developers.

My current workflow

Further below on this page are some perhaps amusing notes on what I used to use.

Currently I use digikam to manage my photos, and although it can also import photos, somehow I prefer to use RapidPhotoDownloader for that. Maybe I'll come back to digikam later. I've also tried shotwell and F-Spot, but found them lacking and not scaling well to large numbers of photos. To edit JPG images (always good for a quick album, as picasa used to work for me so well) I can use digikam's editing capabilities, but for some more advanced procedures I use GIMP, but it's more time consuming. To edit RAW images (NEF files for a Nikon), there are several options as well, in fact digikam can also do it, and again, maybe I'll try that too some day, but I tend to use darktable for this. But it doesn't have all of the things I need, and then some post-processing would still be done in GIMP.

Picasa

For a few years I really really liked picasa, a google product that works great on linux using WINE. But google isn't sending signals it will be maintained (heard that before?), you can already see a picasa and google+ split, although they still allow you to use picasa. The program works quite well on linux, in fact, it still is the fastest scaleable photo browser there is, and I really liked their virtual album creator, and the ease to create albums. But in the most recent frozen version I cannot get web authentication to work anymore (some complex procedure using WINE is needed). But it was superb in keeping your albums online in sync with your hard drive version. In itself that was also a weakness for those who switch computers a lot.

Example of using jigl with the camera scripts

In the example below I am using a different directory for the pictures (they could eventually be stored offline or on a DVD), and the web 'copy'. Most of the time the web 'copy' is just a set of symbolic links into the actual picture data tree. This way the only archival thing we need in this directory are the gallery.dat and rsync.dat file. The rest could in theory be removed (the actual $root_name/ subdirectory, and the slides/ and thumbs/ directories used by jigl). But you don't have to do this. You can just as well keep the gallery.dat and rsync.dat file in the picture directory. 


	cd $my_picture_disk_for_today
	get-nikon                                       (grab the latest pictures from the camera)
	cd $my_web_copy_for_today
	jigl -cg                                        (make a fresh gallery.dat file)
	add-jpg -a $my_picture_disk_for_today/*JPG      (add all JPG's from what we just downloaded)
	edit gallery.dat				(set -wd name, and optionally add -lo; also set TITLE's)
	edit rsync.dat					(set the machine/root_name/pics in rsync.dat, see do_sync for template)
	do_sync


    Any subsequent new pictures can now be updated on the webpage as follows:

	
	cd $my_picture_disk_for_today
	get-nikon                                                               (grab the latest pictures from the camera)
	cd $my_web_copy_for_today
	add-jpg $my_picture_disk_for_today/DSC_0103.JPG a nice flower           (take this pictures, add some annotation)
	add-jpg $my_picture_disk_for_today/DSC_0110.JPG watch the bird fly      (another one, and some annotation)
	....
	do_sync                                                                 (runs jigl and updates the webpage)



Directory structure:

   $my_picture_disk_for_today/                                where all the originals live
   $my_web_copy_for_today/                                    where gallery.dat and rsync.dat live
   $my_web_copy_for_today/$root_name                          your local WWW mirror tree
   $my_web_copy_for_today/slides                              temporary cached copies for jigl
   $my_web_copy_for_today/thumbs                              temporary cached copies for jigl


Note that $my_picture_disk_for_today and  $my_web_copy_for_today can be the same location on your disk.

Other useful references