Dec
26
2010

A New Camera Means A New Workflow

Making Picture Project Work For Me (Part 3 or 3)

(Add / View Comments) (0)Sunday, December 26, 2010 - 02:08:45 pm
(Posted Under: Photography, PictureProject)
And now for more on PictureProject. There had to be a better way, and there kinda is. Amazingly while still using PictureProject.

When it comes to handling digital photos, I've had the same system for years, all centered around PictureProject.

  1. Shoot
  2. Move the original photos directly off the SD card
  3. Make a copy of the original photo for Picture Project
  4. Cull & then import into Picture Project
  5. Edit
  6. Export lower resolution for web
It's a work flow that has worked well for me ever since I brought my first digital camera at the end of 2005.

Step 3 came from initially not understanding how PictureProject worked, and generally being cautious. As mentioned in an earlier post, one of the things that is great about PictureProject is that it maintains the original photo, virtually 'appending' any edits to the image in a separate image within the JPEG file. Which, y'know, is pretty cool. Since I didn't initially realize this, plus wanted to be able to easily access the original image for archiving, I always kept a copy of the original file before editing.

Which all meant that I had 3 copies if all photos. Which, y'know, was fine when working at 6MP.

Introduce a 12MP DSLR, and all that begins to change. At ~4MB a pop, a size which is doubled with each edit point (or 'marker' if you read the preceding posts), keeping a separate copy of the original image becomes a bit more unfeasible. And kinda ridiculous when shooting in RAW+JPEG. The untouched original has to go.

Which is doable, given that it's been rare (if at all) that I've needed access to a whole bunch of original photos. With the original always preserved by PictureProject, the only advantage to manually keeping the originals is that it's a pain in PictureProject to revert to the originals. Which has to do with the clunky way PictureProject stores edit points and risk to losing the edit points. But whatev, given the infrequency that I have needed all photos in a set to reverted to originals, I'm no longer worrying about this. And I guess there is probably a safe and easy solution to revert a set of files back to their originals[1].

A further need for a change in work flow is what has been the bane of my existence with the Nikon D5000 until now - no USB mass storage support. That's right, the camera only supports PTP over USB. Which normally wouldn't be a problem, I hardly ever connected my old camera via USB. However, given that I'm using a SDHC card with the new camera and my laptop doesn't support SDHC, there's a bit of a problem. Sure, I could use my Netbook, but that's kind of a pain. So I'll use USB please.

Windows handling of PTP is absolutely horrible. Not only does it screw with the filenames, but it doesn't allow deleting/moving photos. Not to mention it seems to show NEF's as JPEG's. Eh

However, I just found the solution - Nikon Transfer. Something I vaguely looked at (bundled with PictureProject) in 2005, before deciding to not use it. However, for a camera without USB mass storage support, it's a life saver.

One of my pet peeves with PictureProject has been that it insists on copying photos to a specific location on import. That would have been good, but I have never wanted my photos stored in folders named 001 etc. And I don't want them under \My Documents\My Pictures\PictureProject, thank you very much. Hence, I've always copied the originals myself, using a folder name I want, and imported with 'copy original files off'. What I have discovered with Nikon Transfer is that I can at least set the base folder transfers are copied to. So, hey, Nikon Transfer can transfer the photos to C:photos as I like. Sweet. I don't have the control over the folder name that I'd like, but at least it's not 001, nor under My Documents.

Being forced to use this, I've discovered one thing in PictureProject that I never knew. I can rename a (file system) folder, then have PictureProject 'find' the missing file/photo. Or, have me find the missing file actually. That I was kinda aware of in someway. But I didn't realize that it would then try and find any other missing file in that collection within that new folder. All this means that I can rename the folder, and 'find' the new location - rather than what I first did, which was rename, delete the new collection, and import the photos from the new folder into a new collection.

And hence comes a new work flow.

  1. Shoot
  2. Transfer photos from camera using Nikon Transfer
  3. Rename transferred folder as desired
  4. 'Find' the missing files within the transferred collection in Picture Project
  5. Rename collection as desired
  6. Edit
  7. Export lower resolution for web
Arguable this work flow is actually a lot easier, particularly since I don't need to switch out of Picture Project at all. Gone are the days of having to have 2 Windows Explorer windows open, and then having to open Picture Project.

There is an extra step in there, with all that renaming folders, finding the files and renaming the collection (as opposed to if Nikon Transfer asked me what folder I wanted to put the files in), but it's still oldly quicker and requires less thought than what I used to do.

An added advantage to all of this is that collections created due to transfers are stored under a "Transfers" collection/folder in Picture Project. Previously after doing an import, there was no way for me to easily tell if I'd edited and exported a batch of photos. Inherently with this work flow, provided I move collections into the root collection once I've done everything (edited, exported, put into Photobox), I can infer that anything still under "Transfers" has not been processed. That's going to be a time saver in itself.

Sadly, just like "Import", "Transfer" cannot be set to transfer to a network drive. So the last post about hacking the database still applies with this work flow.

There are a lot of ways that PictureProject works that is of annoyance to me, given the way I like to do things, but surprisingly, having to change to this new work flow has most of them.

[1] By copying the edited files to a new location, importing them into Picture Project and restoring these to originals. Provided that PictureProject allows "Revert to original" as a batch operation. Which, thankfully it does.

Dec
26
2010

Hacking Nikon's "Picture Project"

Making Picture Project Work For Me (Part 2 or 3)

(Add / View Comments) (0)Sunday, December 26, 2010 - 01:14:17 pm
(Posted Under: Photography, PictureProject)
As a follow on to the last post, I've cooked up a solution to one of my annoyances with Picture Project. I need to store my photos that are in Picture Project on a network drive, and damn it, that is what I'll do.

As gripped in the previous post, PictureProject does not allow you to select a network drive for transferring photos to / importing photos from. However, this can be fudged once the photos have been to PictureProject (via either method), by modifying the PictureProject database.

The first thing required is for a samba share to be setup. Duh. If you're like me, and use 'Mark as hidden' in PictureProject to signify something (in my case, a photo that I've kept but isn't that good), the samba share needs to be setup to handle the DOS hidden attribute correctly. That's right, despite running off a database, PictureProject stores this information as a file attribute. A bizarre and not very consistent choice, though I admit, I take advantage of this implementation.

Thanks to a brain fart last night, I was regrettably thinking I needed to use a NTFS or FAT partition to make this work. Then I came to my senses, remembered that is all controlled by samba and that the underlying file system wasn't important, and joyfully reformatted as reiserfs. Hallejiah, because the last thing I actually wanted to do was use a Windows file system.

Getting the attribute to work right over Samba is just making sure the share is setup as such:

map hidden = yes
create mask = 741
Not setting the create mask with the 'all execute' bit active is what I was tripping up on. 'testparm' is your friend. Well, it was mine last night.

After moving all of the photos on to the share, hacking the database is next. PictureProject uses an Access database (oh, how novel, and "fun"). So fire up Access, and open C:\Documents and Settings\<user>\Application Data\Nikon\PictureProject\DataBaseSource.mdb . Well, after you back it up anyway. Some Google searching indicates that the password for this, and all the other files in that directory is 'nikon'.

From there it's simply a case of changing the data in the 'path' field to match the location of where the photos are now stored. Find and replace is your friend here.

By all accounts, everything is good once doing that, providing that the share is writable and is configured correctly to map the hidden file attribute. Photos on remote network shares can be modified just like they could be when they were on the local disk. Which makes you wonder why the developers of this software thought it was a good idea to disallow direct importing from networked drives.

Vola, now all my photos are stored on a network drive, as I want.

Of course, any new photos still need to be imported / transferred to a local disk initially, and the whole process repeated (move to network drive, update database) ad nauseum. But I guess that is life, and I should just be content with the ability to relocate photos to a network drive when I run out of space again.

If PictureProject backed onto a nicer database (*cough* mysql), or if I wanted to screw around enough with Access scripting, I could probably automate it all. But I'm not sure that that sounds like my idea of fun. For now I'll just wait until I have a whole bunch to move and do it manually.

Next on the agenda is to merge the PictureProject database from my old machine into the one I'm currently using on my laptop. But that's something for another day. Or maybe the twelfth of never. [wink]
Dec
26
2010

The Dramas Of Nikon's Picture Project

Making Picture Project Work For Me (Part 1 or 3)

(Add / View Comments) (0)Sunday, December 26, 2010 - 12:10:19 pm
(Posted Under: Photography, PictureProject)
I've been using Picture Project, which came bundled with my Coolpix for years. It's far from an example of a spectacular piece of software. However, I've been despite the annoyances, I've been able to make it work. And still remains the front runner compared to the alternatives I've tried, namely Picasa and Picture Project's successor NX View.

Largely because it's RAW support, I gave NX View, which officially Picture Project has been dropped in preference for, a test drive. Maybe it'd solve all my Picture Project hassles. Apparently not.

Here's the good, bad and the ugly of Picture Project - according to me. [smile]

Why It Doesn't Suck

Preservation of Original Photos

One of the coolest parts about it, mentioned in a previous blog is that it preserves the original photograph. This is way cool, and why I've recently elected to stop manually maintaining a separate copy of original unedited photos. I'm not entirely sure of the specifics, but I'm sure it's because the JPEG specification allows for multiple images to be stored within a single JPEG file. More on this under "Why It Does Suck".

For what it's worth, NX View doesn't do this, and prompt "save a copy of the original" if you make any change. Which immediately ruled out NX View as a useful upgrade.

Image Editing

Image editing is basic. Typically, for me, this is a good thing. It pretty much does what I need. Would I complain if it did more? No. But y'know, if I want to put a ridiculous Photoshop effect on a photo, then I'll just do it in Photoshop.

With that said however, it's curious that while the Coolpix firmware supports Standard, Vivid, Black & White, Sepia and Cyanotype color options, this software only supports Black & White and Sepia. Having more options on the camera's firmware is kinda weird. And annoying, because I wouldn't want to shoot in Cyanotype - that's something to be left for post processing.

Why It Does Suck

Markers

The way Picture Project stored edits is quite accident prone. Well, okay, the way it stores them is fine. It's the user interface that is accident prone. The way it stores edits is via "markers", which no doubt refer to specific imags within the one file. That's cool. There is always the marker "Original". That's cool too. If you make an edit, a new marker is created "Created". That becomes 'Last Saved' when you leaving the editing UI for that photo (like moving to the next photo to edit). That's cool too.

You can also define custom markers. Again, cool. What is not cool is what is not cool is what happens to the 'Last Saved' marker if you have custom ones. For example, I typically will do an Auto Enhance, a bit of sharpening for most photos I put into Photobox. And this I consider to be 'Last Saved', I have my original, and my cleaned up version. Now, if I'm going to put a photo on Flickr, I'm inclined to be a bit more liberal with the editing depennding on the effect that I'm going for. It's not uncommon for me to want to go a bit more heavy handed with the color booster. So, I do that and set a maker 'Flickr'. We're still all savy. I have 'Original', 'Last Saved' (basic editing) and then 'Flickr'.

It all goes pair shaped if I go back to the photo, select the 'Flickr' marker, and then leave the photo. The second I leave the photo, the 'Last Saved' then becomes the image the 'Flickr' is set to, and what I had as 'Last Saved' is gone forever, In theory it makes sense, in practice it's really dumb. The only was to avoid guard against this is to set up another marker 'Basic Edit' if you're going to have custom markers, to avoid not accidently loosing that state. It annoys me to no end, because I hardly ever remember to do so, as it's an extra step. It might be fine in theory, but in practice it's stoopid.

Memory

It leaks memory like an empty bit bucket. Even when working with a collection of 50 photos, I have to close the application at least 3 times a session, as it invariable brings everything to a grinding half as the Windows swap file grows infinitely large.

Batch Editing

This kills me. It virtually doesn't exist. While I can select a number of photos for "Auto Enhance" (and possibly "Auto Redeye") and head of for a smoke while it works away, this doesn't work for the other functions. I can only imagine how many hours of my life I've lost over the years because I can't select multiple images and set the sharpening to "high" and come back when it's done. No, you have to do make the setting for every single photo one by one. Ahh, the fun. Nikon software developers clearly aren't rocket scientists. Or decent UI implementers.

Network Drives

This is my biggest annoyance with the software. Photo files are restricted to be stored on a local disk. Sure, you can import from a network drive, but only with 'Copy original files' selected, which throws the files into a directory structure that would make iPod / iTunes developers proud. That might work for your typical user, but it doesn't work for me. Y'know, I've been threw 3 computers in the time I've been using Picture Project. \My Documents\My PicturePicture Project just ain't a good place to be storing my photos guys!

And what happens when you're in the position that I am currently finding myself in right now? Where your volume of photos is on the verge of exceeding the free space on your machine, and your mass storage device, where you actually wanted to store the photos in the first place, is connected to a remote Linux machine?

There's got to be a better way...

Switch Styles

About Style Switching.

!Weblog Index

Nov December 2010 Jan
SU MO TU WE TH FR SA
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Categories

RSS FeedRSS Feed