Comments on: Who’s got the tag? Database truth versus file truth, part 3

By: link

link — Tue, 30 Oct 2007 15:28:07 +0000

hello

i agree

By: James Aguilar

James Aguilar — Mon, 16 Apr 2007 07:00:22 +0000

I didn’t read all the other comments but it seems the best way of doing it would be storing tags primarily in the database. Then you could provide a hook API that allows the DB to check the file’s tag integrity whenever it gets referenced. Any files missing their corresponding tags get them replaced automatically.

By: Withheld

Withheld — Mon, 16 Apr 2007 02:18:21 +0000

“I would gladly buy a copy of Office to run on Linux (but not using an emulator). The glass is about 1/3 full. Let’s keep working on it.”

You can. Crossover Office does not use any form of emulation. Or, if you’d rather not pay anything beyond Office’s ridiculous price tag, you can use vanilla WINE. Wine is not an emulator.

By: Daniel

Daniel — Sun, 15 Apr 2007 22:29:24 +0000

Why not employ both techniques? OS X could have an option called “export file,” and then add the metadata to the file from Spotlight’s database in a way that something like Flickr or Vista would understand.

By: survivalsin

survivalsin — Mon, 26 Mar 2007 12:22:29 +0000

[1] On the same file, my tags may not be the same as your tags.
[2] Identical file copy should not include any modifications by user.
So, I think OS X’s way is better.

By: Reed Hedges

Reed Hedges — Sun, 04 Mar 2007 16:47:00 +0000

…Hmmm…

Sounds like the problem in Vista is essentially a bug in either camera manufacturer’s software, Vista, or the design of metadata in Vista files. Basically, there’s no valid reason that that metadata should ever get “corrupted”.

What I originially *thought* your article would be about, is this: what happens if I replace all the pixels in yellowflower.jpeg with an image of a Lilly instead of an Iris? Then the metadata is just wrong vs. the object it purports to describe (rather than “corrupted”). Now that’s a tricky problem.

By: Nick Young

Nick Young — Fri, 02 Mar 2007 20:31:29 +0000

I’ve been contemplating the same thing Jon. I figured that when I tagged my photos in iPhoto the tags would only work in iPhoto. I know that with mp3’s there is an integrated tag structure. Not so with photos. If the designers of image formats could come up with a way to have tag fields withing the file that would be idea. It would remove the risk of corruption because it would be built into the format and part of the standard.

By: Jon Udell

Jon Udell — Thu, 22 Feb 2007 13:50:58 +0000

“Flat out wrong. Read the article the post links to? There is no mention of JPEGs whatsoever.”

Yes, thanks for pointing that out. In fact it’s a RAW issue not a JPEG issue, and there’s been discussion here:

http://blogs.msdn.com/pix/search.aspx?q=nikon+raw&p=1

By: Jon Udell

Jon Udell — Thu, 22 Feb 2007 13:48:51 +0000

“Only if you cannot think of a simple system to auto-transfer that metadata.”

I can. You can. The vast majority of folks cannot.

By: anona

anona — Thu, 22 Feb 2007 07:02:09 +0000

“If you’re an avid Flickr user, if you invest effort tagging photos in OS X, and if that effort is lost when you upload to Flickr, then OS X did not Just Work for you.”

Only if you cannot think of a simple system to auto-transfer that metadata.

For instance, I just used a free script at Doug’s AppleScripts (http://www.dougscripts.com/itunes/) called “All Tag Data to File Comments” to transfer a bunch of tags including ratings from a selection of iTunes songs to their associated files on disk. Next those files were moved into a folder and deleted from iTunes: a simple archiving process. Metadata for those songs are now in the comments and thus can be read back into iTunes should I choose to import them with a reverse script.

It’d be trivial then to do the same with a Flickr uploading app that parses the metadata in file GetInfo comments and populates Flicker tags.

By: Pastco

Pastco — Thu, 22 Feb 2007 01:47:39 +0000

Your discussion is a good one but that post from Lifehacker is grossly over simplied and you have interpreted inaccurately.

>Many applications are guilty of changing JPEGs behind the scenes and there is nothing forcing them to do it >in compatible ways. Here is a recent example with Vista.

Flat out wrong. Read the article the post links to? There is no mention of JPEGs whatsoever.

As the article quite clearly notes – The problem is not with JPEG files but with RAW. All camera makers have different versions of RAW which is one reason why Adobe wants a standard RAW format. Almost any app mangles the makernote field in a RAW because all camera makers do it differently. Even the kb notes that “This metadata is specific to the manufacturer of the camera.” This is a typical lazy blogger, lazier blog reader problem because the issue is not just with Vista. If you edit RAW information with photoshop you can have problems with other applications. It is an industry problem and there are applications that let you save the original metadata before using other apps to edit.

JPEG is a not a camera specific format so you can change the metadata with different applications without much less concern losing anything. I have tagged JPEGs for years, back and forth with various apps and there have never been any problems. With standard formats the issue of file corruption on your machine is much less of an issue than you make it out to be.

By: Jon Udell

Jon Udell — Wed, 21 Feb 2007 21:46:50 +0000

“What about a “universal file format metawrapper””

I love it. How we get from here to there does, however, require some pretty energetic handwaving :-)

By: Craig

Craig — Wed, 21 Feb 2007 21:38:35 +0000

Hi Jon,
What about a “universal file format metawrapper”. Such that the wrapped files can only be opened by applications that support the format and treat metadata nicely. The format as having a header with metadata about the file type it contains for OS file typing, a unique identifier(to solve your photo tagging dump in a directory issues) and with other metadata that users add to the file. Applications not in the know wouldn’t be able to read the files and corrupt the metadata because of the wrapper.

While it’s not a solution for existing application file types, as that would likely have to be done at file system level with an API, I believe it would cater for future usage.

Operating systems of the future(and upgrades to existing ones) could natively support this metawrapper such that legacy applications could read and write the files. Redundancy could be achieved for legacy apps on native metawrapper OSs by storing the metadata in the existing file formats and in the metawrapper. The OS backing up known filetype metadata. Metawrapper plugins could exist to extend that. When there’s a change the user could be alerted by the OS to take action. New formats that people create would use the metawrapper. The metawrapper having redundancy in the form of a metadata update history.

And maybe if we plugged this into web services, we could annote URIs with metadata using a standardised ReSTful metawrapper API and build a data web.

I hope I’m not missing something obvious.

By: John Roberts

John Roberts — Wed, 21 Feb 2007 15:35:26 +0000

Another wrinkle to consider: my backup scheme involves writing the directories containing my digital pictures to a CD-R, and performing a diff to ensure everything copied OK. Later on just before I write the next backup set, I also do a diff to ensure the images haven’t been corrupted on the hard disk since I wrote the original backup. If tags I create after writing the first backup land in the image files, then the diff I execute can’t be relied upon to show me “corrupted files”. So perhaps this suggests another option: put the metadata in a separate (XML?) file (in the same directory as the images?). Then the image files can be left pristine, the metadata is easy to see and backup and migrate to other systems, and also easy for a system like OS X/Spotlight or Vista to access and update.

By: Jon Udell

Jon Udell — Wed, 21 Feb 2007 13:34:46 +0000

“not holding my breath”

I am. Turning kinda blue, though…