I keep coming back to Dropbox for Photo management

When I dropped the kids off at school today, one of the teachers commented to another “Oh, you must see that video of them singing on the bike, it’s hilarious”. She grinned and looked at me expectantly.

Uh….

OK. I’ve got my entire catalogue on Mylio. I opened it, hit search, and “jingle bells bike”. Nothing.

And that was it – the moment was gone. I would have loved to share it with them, but I couldn’t.

And this is the point. If I’d had PictureLife, I probably could have found the video and streamed it pretty quickly. With Mylio – no; even if hosted in their cloud (which is not really what it’s for), it would still need to download the video first, by which time you’ve lost the moment.

Dropbox – as long as the file had that in the name, it probably could have found it immediately. Once found, a video can be played with a click, even skipped through, and it keeps playing within a few seconds. Speed is a priority.

Don’t get me wrong, Mylio is great – I just searched for “bike” and it showed me 80 photos immediately which I can scroll through chronologically with absolutely zero lag (PictureLife became dog-slow towards the end). But all the videos are white spaces without thumbnails (not sure what happened there), and even if I found and played one, it would need a full cloud subscription and be able to download the whole thing before it started playing.

Dropbox is simple, it works, they’re not mining the photos (that we know of / yet), and it streams media easily.

Can’t use Burner numbers with Yahoo registration

So, I thought I’d try Flickr as a photo hosting site, as a trial run. Since I want to make a little effort to retain privacy through obscurity (<g>), I tried creating a new account with no links to my own ID. But Yahoo require a valid phone number.

No problem, I thought – I’ll use the Burner app to create a temporary phone number to receive the verification code.

No dice. Yahoo reject VOIP numbers from apps like Burner. I’ll have to use a valid mobile – although I do have a UK one that I bought in a vending machine with no ID, and topped up with another credit card.

I’m sure government services could easily make the link, but that’s not what I’m trying to do – I’m just trying to make things a little harder for advertising and identity trading services should Yahoo sell out to someone who then try to mine my photos for information and link it back to my identity.

XMP files are far more cloud-storage friendly than EXIF

I’m currently running a large reorganisation of my 50,000-odd photos on my home server / NAS using Picasa and Mylio. While doing so, I realised one argument for using XMP rather than EXIF data.

As a small recap – both allow you to store metadata for photos, such as keywords, 5-star ratings, geolocation, and so on.

• EXIF is inline in the JPEG file, and hence you only need the JPEG file itself – if you change the EXIF data, it basically changes those bytes in the file or adds/removes that data. There are various versions of the EXIF standard, and there appear to be tens or hundreds of fields available.
• XMP is a ‘sidecar’ file – it sits in the same directory, with the same name, but with an .XMP extension. Eg. You might have a file from your iPhone called IMG_1234.jpg. With this method, the EXIF data in that JPEG is untouched, but instead an XMP file is written called IMG_1234.xmp, and some editing software such as Lightroom or Mylio know to look at the XMP file and apply the data they find there. XMP is extensible – you can have almost as many fields as you need.

I can see arguments for and against each – EXIF is in the file, so as long as you have the JPEG, the data travels with it. This can be important if, say, uploading photos to Facebook or other photo sharing sites that wouldn’t recognise the XMP file.

However, XMP has the advantage of never changing the JPEG file itself, so you can make image edits that are only applied to the JPEG at view-time. This means you can make multiple edits to the JPEG file, and it’s not repeatedly de/re-coded and re-written, decreasing quality each time you save. They’re also very useful for .RAW files, which vary in format and don’t have the same EXIF fields as JPEG files.

 

However – the thing that struck me, was when I applied 15,000 facial recognition edits from Picasa to JPEG files after a couple of days of training and processing. Picasa dutifully wrote the name tags to each JPEG file – and in so doing, changed the checksum for each one, even if only by adding a few bytes. My cloud backup software Crashplan picked this up, and immediately wanted to back up the 15,000 files all over again.

This is hundreds of Gigabytes! Of course, if I want to keep those tags, I’ll have to do it too. And again every time I add more tags – if I add album names and/or keywords at a later date – it will have to re-upload the lot each time! Backup software does often offer differential backup of only the changed bytes, but this is generally meant for a small section of one huge file being changed, not a small section of thousands of small files, and would likely not help.

If I had written them to XMP instead, then the JPEG files themselves wouldn’t have changed, and Crashplan would only have uploaded the new or changed XMP files. These would be far smaller, and far easier to sync. Hence I will be doing this in the future.

It’s at least worth writing ongoing edits to XMP files, and if you ever decide that your changes are ‘done’, you can perhaps write and ‘flatten’ those changes into the original JPG and EXIF data at that point for archival storage.