• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

DAM and Aperture

David Burnette

New member
I've read Peter's DAM book and have adopted much of the workflow presented there using iView Media Pro. I'm still on the front end of organizing my image files and have really taken to Aperture since the 1.1 upgrade.

I see little in the DAM forum of Peter's regarding the new and improved Aperture and how to adapt it to his practices. Is anyone here using Aperture as their total workflow? One of my chief concerns is how to organize files to allow for the inevitable ugrade of Aperture to allow mulit disk libraries.

Thanks/Dave Burnette
 

Robert Edwards

New member
Hi Dave,

The reason I don't use/recommend Aperture is that there is no easy way to get your metadata out of its database. Plus it doesn't work on my Windows machines, nor probably ever will. It's sort of like a Swiss Army Knife, convenient, versatile, but ever tried fixing anything with one?

Aperture has a sexy GUI and streamline workflow. If it works for you, and you sign the prenup agreeing to stay with Aperture, for better or worse, then stick with it.

Otherwise iView works for me. FWIW I'm C of E :)
 

JohanElzenga

New member
iView can read Aperture Libraries, so you can use a combo of Aperture and iView if you want. Just drag and drop the library on an iView catalog window.
 

Stan Jirman

New member
The metadata in Aperture is stored in XML files along with each image file; I don't know how much easier or more portable one can make access to the data than that :)
 
Stan Jirman said:
The metadata in Aperture is stored in XML files along with each image file; I don't know how much easier or more portable one can make access to the data than that :)
Try embedding the metadata in the raw or dng file.

Do you seriously expect most users to use XML files to migrate from Aperture?

John
 

Stan Jirman

New member
I didn't hear anything about "most users" in the original post/question. I heard something about "ease". For truly large scale applications, that's a very practical way of doing it. After all, one doesn't see all that many people complaining about PS using its little sidecar files. Or C1 or other apps for that matter.

The Aperture designers have repeatedly said that there was one absolute rule in the design of the app: never, ever touch the original file. Like all categorical claims / stakes, it has its pros and cons; however, it at least is a very clear answer and takes any guesswork out of the equation.

There's an "Export as [TIFF/PSD]" feature, which will embed all the data, plus you can get the XML file if you want to build an automated workflow. The raw file is the "digital negative" and thus sacred to Aperture - like it or not.

Given that Aperture hasn't been out that long yet, and that this behavior was always communicated VERY loudly by Apple, I don't think that one should be all too surprised, or impacted by migrating from it (you have most likely not accumulated terabytes yet, and if you did without checking for "key" limitations then I have little sympathy). Like with all software, there will be something that you like and something you don't; it's your choice not to use it.
 
Ease / most users - what's the difference? DAM solutions don't last forever, even "One Ring..." ones, and you need your escape route to be a whole lot easier than XML-based sidecars. If you can't easily get your data out with your files, you've not got a solid DAM solution. So whatever its virtues, that's why there's little discussion of Aperture in the context of DAM.

John
 

Robert Edwards

New member
Hi Stan,

After all, one doesn't see all that many people complaining about PS using its little sidecar files. Or C1 or other apps for that matter

This little birdy does, and often. When DNG files were able to have sidecars embedded simply by re-processing them, it was like DNGs second coming.

Sidecar files are a PITA. And every manufacturer uses their own system. Yes some are based on open formats such as XML. How many photographers know what XML is? Granted you are right, XML it is one way out. There should be easier options.

YMMV :).
 

Dierk Haasis

pro member
robertedwards said:
This little birdy does, and often.

Me too, started with Canon's CRW/THM combo and didn't stop with other sidecar files (i.e. RAWShooter's, Bibble's and now XML). As long as there is no standard implementation on OS-level for linking the contents file and the sidecar, they are unusable. And a PIA for developers.
 

Dierk Haasis

pro member
Cem said:
Did you mean API (Application Program Interface) when you wrote PIA?

No, API should be provided by OS or program for other application's developers to get access - simplest example is the command line (or console).

PIA is an acronym for 'Pain in the Bottom' [guess you can figure that out if you have learned British English].

The problem is that a program like MediaPro or Portfolio or iMatch have to keep track of existing and newly developed sidecars.
 

Cem_Usakligil

Well-known member
LOL, now I get it ;)

When you wrote:
As long as there is no standard implementation on OS-level for linking the contents file and the sidecar, they are unusable. And a PIA for developers.
I read this as: a standard implementation on OS-level is needed as well as a PIA. Hence my confusion whether you meant API.

Regards,
Cem
 

Asher Kelman

OPF Owner/Editor-in-Chief
John Beardsworth said:
Ease / most users - what's the difference? DAM solutions don't last forever, even "One Ring..." ones, and you need your escape route to be a whole lot easier than XML-based sidecars. If you can't easily get your data out with your files, you've not got a solid DAM solution. So whatever its virtues, that's why there's little discussion of Aperture in the context of DAM.

John
John,

What am I missing in my comprehension of Jan's explanation of Aperture and ability to transfer metadata?

You think it lacks "ease" or you just don't like it?

Asher
 
Hi Asher

Let's say you've put a load of metadata and your raw files into Aperture (or a number of other programs) and then decide you don't want to use Apple-brand computers any more. Stan's solution was to export all the metadata as XML files:

There's an "Export as [TIFF/PSD]" feature, which will embed all the data, plus you can get the XML file if you want to build an automated workflow. The raw file is the "digital negative" and thus sacred to Aperture - like it or not.

Well obviously the first TIFF/PSD isn't acceptable for xx,000 raw files, and I'm sure Stan didn't mean it that way, so I'll pass over that one.

The second is the export of an XML file. Feel free to correct me, anyone, but that's one XML sidecar per raw file, isn't it? But as Robert said, how many photographers have the skills to extract the metadata from them and get it into Adobe Lightroom, Microsoft iView etc? Even if it's a single file, you'll certainly need to automate the transfer process (partly because these things rarely work first time). How many photographers have experience of data migration or the disciplines and skill set you need to be sure you've migrated the data correctly?

Stan's third sentence is about the sacrosanct nature of the raw file. I also find that unsatisfying, but firstly I should say I use the DNG which is a safer format to which to write metadata, not just IPTC and other standard fields but also metadata that might be specific to you such as client order numbers, species, stock library terms etc etc. But back to raw files. Why should a program not write metadata to a raw file if it can do so with a high degree of certainty, in some cases by using the camera maker's libraries? A prudent user would keep a virgin copy of the file to guard against file corruption (nothing is 100% reliable). With your metadata embedded in the file, you've a prenup that leaves you free to move to another program with minimal fuss. If Aperture allowed that, its DAM features would be taken more seriously but for now it's more workflow than DAM.

Unless you truly believe in "One Ring to bind them them all..." solutions, DAM is about planning for the long term and the reality that you'll be changing your photograph management solution.

John
 

Stan Jirman

New member
Dear John,

I have often mentioned in my posts, and will do so here again, that not every application may be for everyone. By no means do I try to make Aperture to something that it is not. For instance, I will be the first one to point out its sheer memory, CPU and GPU requirements before it can be even remotely useful.

My original post in this thread was directed at the 2nd post in this thread, by Robert Edwards, who states that there isn't an easy way to get the metadata out of the database. This, and solely this, is what I meant to address: METADATA out of the DATABASE. To me, and I would say to many people, the word DATABASE has something mystical, closed, propriatery, even scary on it. Something that you can't approach; that you can't just open up and see what's in it. Something that you need a specialized tool to read it. Something that will be totally useless if your application of choice were to go away, for whatever reason. Now, indeed, Aperture has such a DATABASE - one per library. In addition, however, it has one side file for every master image, and this file is in a publicly readable format - the OS (without Aperture) even ships with an app that can show you the contents. Not much difficulty about that.

It was about getting the metadata out of the database. Nothing more, nothing less. It is trivial.

Now, it indeed may be the case that this may not be of much value to the user. I would wager to say that it is about of the same value to the user as Photoshop's idecar files, assuming the same scenario that suddenly Adobe would go out of business or stop supporting PS. About as likely as with Aperture, but that's just my opinion.

As for not modifying the original files: I was hoping that I made it clear that it was a design decision, one that was very clearly broadcast, and that is considered to be a feature. As such, it should not be a suprise, and if this is a hurdle for entry, then by all means, do not enter. However, like with all absolute statements, there's little point in arguing it. Like with a religion, join it or ignore it or fight it.

For the record, the general case of writing out metadata without destroying other metadata is impossible to solve without intimate knowledge of what the manufacturer puts there. Again, I am saying the GENERAL case, not one special case that may be easy. But once again, because data integrity was the prime directive with the design of Aperture, since the GENERAL case can't be guaranteed to be loss-free, writing of metadata into original files was not included.

I hope this time I was clear about the scope of what I meant to say, and it is free to everyone to judge if they like it or not, and to use it or not. I am merely trying to explain the reasons.
 

Robert Edwards

New member
Hi Stan,

My ears were burning so I thought I'd check in ;).

I stand by my statement that Aperture doesn't make it easy for photographers to migrate your metadata. IIRC it was also a common complaint in reviews. Databases are scary when they're proprietary. Portfolio, Cumulus, and Fotoware also make life more difficult. iView have a history of making it easy with several options, including XML. It's new owners Microsoft most definately do not have a good track record!

IMatch is the best example of a DAM application that does make it easy to import and export your database. When I moved to iView it was simply a matter of pointing it to the images. My colleagues and I are script ignoramuses. XM what?

Stan I think it's important we declare our true colours here. For full disclosure I am an iView affiliate meaning I offer discounts on their software at seminars, as well as other competing applications like Photo Mechanic. I do this because I believe in their products.
 

Robert Edwards

New member
Hi Stan,

I use C1 for raw processing and a home written app for "DAM"

Great. There was a recent post on the iView forum about an open source DAM. I've never seen one, but surely now is the time for such a project?
 

John_Nevill

New member
What an interesting thread, It makes me think that if Adobe get it right then lightroom "could" be a sidecar panacea for cross platform RAW editing.
 
John_Nevill said:
What an interesting thread, It makes me think that if Adobe get it right then lightroom "could" be a sidecar panacea for cross platform RAW editing.

John

Sidecar Hell is only one issue, but a panacea for it already is to use the DNG format and store both the informational metadata and the editing metadata in the extensible XMP. There's no real reason why, just as Adobe stores its camera raw settings in the XMP, workflow processors like Aperture, Lightroom, LightZone, and Capture NX (there be more) shouldn't do the same. Then your editing instructions aren't hidden from other programs and at least some of your input, like setting WB, will be readable elsewhere. We shouldn't expect all the editing instructions to be meaningful, but if I develop a film in Ilford chemistry then why shouldn't I be able to do print in in Agfa (what if Apple went bust?). Just as it would be crazy for informational metadata to be readable only with the camera makers' software, so in the age of the workflow processors we should expect our editing instructions - our work - to be our property. It's a whole lot easier to commit yourself if a program offers a prenup guaranteeing you can leave with what's yours.

John
 
Top