Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[marko]

Building a Media Center image library. - This is long, and complex and might not be for you. The next couple of paragraphs may help you decide whether or not you wish to read any further...

I'm just your average family guy, with a wife, 3 kids and a dog! I have a relatively cheap digital camera. It's a Canon Digital Ixus 700. It produces either .jpg files or .avi files, and that's it, no RAW support.
At the time of writing, my knowledge regarding working with digital image files is what I'd describe as 'very basic'. I take way too many photos. Always an extra one, in case that on doesn't look quite right!! I delete many of them, but keep way more than I delete. For a long time (years) I've struggled to keep some form of control over my digital photos with very little success, always struggling to find "THAT" picture quckly. I've trialled umpteen different flavours of photo catalogue software, every one of which promised to be the answer to all my digital image problems, and for me, they all turned out to be empty promises. One came close, real close, but in the end, that failed me too...

I spent several months using Adobe Photoshop Elements before deciding that, despite having a few features that I really liked, it still wasn't doing a good enough job for me, so, once again, I turned my attention to a program that made no such promises, just that I could have it "my way". This proved to be true for my audio files, so, how about my image files? I'd tried, and failed, a few times in the past already. Two of the main features that drew me to Elements, and kept me there as long as it did, were version tracking, and image stacking. They are very simple concepts that Elements maintains itself, and makes it easy for us to manage. While I wanted Media Center to do similar things plus a lot more too, I decided that if it could at least handle stacks and version sets, I might move to using it for my images, full-time.

The Media Center developement path is not something that's publically available, so we generally cross our fingers and hope for the best which can often be extremely frustrating. As v11.1 developed, and database expressions were made available in new areas of the program, namely panes, thumbnail text areas and custom library fields, it slowly began to dawn on me that it might just be possible to get Media Center to take care of stacks and version sets, and in turn, make image management using Media Center a viable option.
First of all, for those that have never heard of them, a few words about stacks and version sets:

Stacks:
About stacks
You can create stacks  to visually group a set of similar photos together, making them easy to manage. Stacks are useful for keeping multiple photos of the same subject in one place, and they reduce clutter in the Photo Browser.
For instance, create a stack to group together multiple photos of your family taken with the same pose; or for photos taken at a sports event using your camera’s burst mode or auto-bracket feature. Generally, when you take photos this way, you end up with many similar variations of the same photo, but only really want the best one to appear in the Photo Browser. Stacking the photos lets you easily access them all in one place instead of scattered across rows of thumbnails.
Stacking photos saves space and keeps related photos together

Version Sets
A version set  is a type of stack that contains one original photo and its edited versions. Version sets make it easy to find both the edited versions of an image and the original, because they are visually stacked together instead of scattered throughout the Photo Browser.

When you edit the photo by choosing Edit > Auto Smart Fix, the Organizer automatically puts the photo and its edited copy together in a version set. When you edit the photo in Standard Edit or Quick Fix, and choose File > Save As, you can select the Save In Version Set With Original option to put the photo and its edited copy together in a version set.
If you edit a photo that’s already in a stack, the photo and its edited copy are put in a version set that is nested in the original stack. If you edit a photo that’s already in a version set, the edited copy is placed at the top of the existing version set. Photoshop Elements does not nest version sets within version sets—a version set can contain only one original and its edited versions.
Get the idea?
Now, without some help from the developement team, there's no way Media Center could handle everything as smoothly, but, I wondered, how close could it get?
What follows is really, a major project. It involves manipulating filenames en-masse plus extended use of database expressions, and when all's said and done, I'm still left asking if it's all really necessary. I mean, why bother? Why not just delete the files rather than hide them? I don't have an answer for that yet.

What I do know is this:
For the time being, I want to keep everything, and I want everything to be available in my Media Center catalogue. I don't[/i] want everything showing up by default though.
Another thing that may or may not apply to you with regards to the tagging tasks is the two very specific tagging stages. Stage 1 being the probably massive task of tagging the many thousands of existing images you have in your library, followed by the ongoing task of tagging newly aquired images. I find that the two stages require subtley different view schemes. I treated the schemes I used for stage 1 a bit like scaffolding, and removed them once the task was complete.

What can be done with Media center to mimic the features? Stacks are simple sets of photos, and can so can be grouped in Media Center using a simple custom field, like a custom [album] field, only called [stack] instead. version sets, are similar, but, I want minimum user workload, so I looked for a way to have the newly saved, edited file, be part of the [version set] as soon as it was saved and imported, this is also important as the new file might not have any tags, a major point that only the dev team could help with.

I guess, if you're still reading, you're still interested, so let's get busy...
Laying the foundations
Step 1: Filenames
There are several approaches possible here, but, for better or worse, I chose to build off the filename. I found that for me, image filenames really don't mean much at all. I identify an image by its thumbnail, not its filename, so, I figured that's an unused rescource that could be leveredged.
My current camera saves files using the format IMG_0001, IMG_0002, IMG_0003 etc. etc.. When creating a version set, Elements keeps the filename, and appends _edited-1, _edited-2 etc. to it. This means that all files in a version set have the same 1st 8 characters in their names, and this is where I kicked off from.

Now, the above theory is great for my current camera, but not so great for any other images previously aquired that don't follow the same naming format. Enter, stage left, KingSparta, with a plugin called Replace Master. This tool will allow you to manipulate your filenames in just about any way you fancy, without losing any existing database tags.
I used it to set filenames on all my existing images following the format used by my current camera. I chose to use the first three letters as an identifier:
IMG_ = canon camera
KOD_ = kodak camera
MUM_ = photos from my Mum
DAN_ = photos from my brother
WAL_ = wallpaper pictures
VAR_ = received via email, or other miscellaneous sources

[marko]

Step 2: Library fields
The system requires a few new library fields:

• A list type field called editing
• A standard string field called stack
• A standard string field called top image. I gave this a keywords value of ti=
• A calculated field called version set using the template: mid([filename (name)],0,8). I gave this a keywords value of vs=

* keyword values are entirely optional, they are handy for speeding up typing of smartlist/search rules.
* Note re. [version set]: I used the first 8 characters as this is a constant generated by my current camera, replace the 8 in the string to match the filename template you decide upon.
* You will need to make sure that MC is set to save any image tags you decide to use inside the file. Without that, the system won't be reliable.
* The 4 fields above are used to make stacks and version sets work. I created several more for general tagging use, which is discussed later.

Step 3: building viewschemes & tagging
I strongly recommend you follow these tips. You don't need to, but they will almost certainly help you in the long run. If you chose not to, read them anyway to get a feel for how this all works, then decide what might work best for you.

1st, have a look at this old screenshot of my tree:


You see the familiar Audio, image and video entries there, and beneath those you see "workshop". When I expand the workshop, I see other Audio, image and video view schemes, and each of those has related, task based view shemes inside them.
The theory is that the 'top level' media type schemes that you already have are kept purely for playback and pleasure, while any 'work' related stuff is kept out of harms way in the workshop.
To create your own workshop, follow Alexb's walk-through, here, from steps 1-3, naming it Workshop instead of All Media (if you like)
Follow steps 4,5, & 6, but here, instead of creating a cd database view scheme, you will be creating an images workshop, so step 4 of the dialogue would only contain [media type]=image. Step 1 can contain anything you like. Each entry will be a pane, choose what suits you best, remember, changing it later is a simple process.
You would then right click on this second new viewscheme, called images, and add the following view schemes:

workshop>images>
workshop>images>editing
workshop>images>incoming
workshop>images>stacks
workshop>images>tagging
workshop>images>version sets

Now, I did not create these schemes in one go. They were created over time, as they became needed. Starting an image library from scratch is, apart from being a bit of a headache, is, for me at least, a two pronged affair. On the one hand, you have to manouvre all of your existing images into line and get them tagged, and on the other, you need to deal with newly aquired images as you aquire them, else you'll never catch up with yourself. With this in mind, you'll want to make the tagging and incoming viewschemes first, and then get tagging.

Before creating the viewschemes, spend a little time to consider what they will actually contain. You need to devise a tagging system that will work for you, and keep on working for the forseeable future. This might not be as easy as it sounds, and you may make a few false starts, I've found there are very few similarities between tagging images and tagging music. Music naturally falls into groups, namely albums, tracks have names and artists. All very linear, and easy to build a library around. I've found that some pictures will fall naturally into 'album' groups, but not all, and struggled a bit coming up with a tagging system that covered all the bases. Media Center comes with some default fields, such as [people], [places] and [events], and very handy they are too, I found more was needed though. Think about later on, when you're using Media Center to show slideshows to friends and family. You can configure the slideshow to display a single string of text, called a 'caption' with each slide in the show. This is not to be confused with the IPTC caption field, which is something different entirely. The slideshow caption can be anything you choose, and can be built using library fields and/or database expressions. Very neat things can be achieved with this, and I'll touch on them later. The reason I mention it now, is that decisions you make with regard to your tagging system could impact on the effectiveness of the slideshow caption, and you wouldn't want to discover that after spending days/weeks tagging your images. Unassigned or unknown are pants when they pop up in a slideshow caption, so to avoid that, there needs to be a starting point, a tag that is set for every image in the library. I called mine [subject]. I needed to create it, and made it a list type field.

Other list type fields I created were [pets] and [animals]. "Animals" is one of the [subject] entries, and to begin with, I used the keywords field to store the breeds, but over time, I felt that it was getting a little unwieldy, so made a specific field, [animals] and moved the info in there instead. My library is still very young, and I'm sure my tagging system will experience other subtle changes as it grows, but for now, I think the basic foundations are sound. After a little trial and error, I've decided to use the following system:



[source] is an expression based field that parses the filenames and then lists the sources as described earlier. This helped me break the task of tagging my existing images into more manageable chunks.
[subject] is the base tag that every image must contain. Try to be as general as possible to keep the subject list from becoming to long. I have things like, people, animals, landscape, plants, and eventually, after running out of inspiration, the probably obligatory "miscellaneous"!!
[people] - default field
[places] - default field
[events] - default field
[pets] - custom, list type field
[animals] - custom, list type field
[keywords] - default field
[stack] - custom, standard field
[top image] - custom, standard field
[needs editing] - custom, list type field. (now called simply "editing")
[caption] - custom, standard field (if you plan on upgrading to v12, this field is highly recommended)

99.99% of the time, you will be in thumbnail view when working with images, so the sorting rules are probably more important than column selection, I found that sorting by date worked best for me.
Next, we need to use thumbnail text to display some useful information beneath each image.
I've found the following to be quite helpful:

[version set]  [file type], [file size], [dimensions]
if(isequal([filename (name)],edited,8),edited,original)if(isempty([stack]),,/ | ±)if(isempty([stack]),if(isequal([filename (name)],edited,8),if(isempty([top image]),/ | top image,),),if(isempty([top image]),/ | top image,))
if(isequal([date],25//12//,8),Christmas Day 'formatdate([date,0],yy),formatdate([date,0],dd MMMM yyyy)) - if(isempty([subject]),not tagged,tagged)

[marko]

Using 'stacks' and the 'top image' fields:
Later, we will set rules to exclude an image if its [top image] field is populated. Have another look at the otter snaps above...
While tagging, I came across these. There are 14 of them in all and I chose to 'stack' them. To do that, I simply select them all, and give them a stack value. So far, I've not fully investigated what's possible using stack values, opting instead to just use numbers for now. Once the [stack] has been set, keep the file selection. look at the pictures and decide which one will be the 'top image'.
Once decided, ctrl+click on the chosen image, then, for the remaining selection of files, set the [top image] field as 'no'. You should see the thumbnail text update to reflect the changes made, showing you at a glance what you have done.

More to follow, questions and/or discussion here.

[marko]

I need to start this again, I think. It's all working wonderfully well for me, but I get tied up in words, using page after page to try and describe something that on the surface, appears to be very simple, then doing the digital equivalent of tearing the sheet off, screwing it into a ball, and lobbing it into the waste paper basket.
The new version will make a few assumptions that will be listed at the start. They'll be things like:
you already know how to:
create a new root entry in the tree
add custom fields
create view schemes
add external applications to send to

Also, the workflow is not really viable using MC11.1. It needs MC12 and its auto-import feature.
I've not abandoned the tutorial, just hit a block is all, and looking for a way forward.

As I've not given up, I'll lock this again. Use the link in the post above, if you wish to comment.
thanks for your patience 
-marko.

Added December 2007:

* Easy ability to 'Edit image' which should create a copy of the file, call it [filename]_edited and send it to my pre-set default editor (photoshop). This should be configurable in options as to how the backed up image will be dealt with (ie whether to create an 'edited' or to just directly edit original)
* Version stacking playing on above feature request.

You might find this interesting. First, I'll step through what I do, then follow it up with some elements that might help if you want to try emulating the system.
I've tried, and failed, to get a satisfactory write up of this out there twice already. It's not for everyone and probably not the easiest to follow, have a read, see what you think...


The theory
I use MC's "Send To.. > External" command to send a file to a bat file that makes a copy of the image called [filename]_edited_1 and then opens it in photoshop.
By the time I'm done editing, MC's auto import has imported the file and all it's tags, which allows me to easily see both files side by side in MC. It's important to have MC set to save image related tags in the file so that they also get copied with the file, and subsequently imported to the database by auto-import. When you hit "Save" in photoshop, MC's proprietry file tags are destroyed, so, if you're a photoshop speed-demon, be careful not to beat the auto-import tool otherwise, important tags could go missing!!

I have a custom field called [top image]. The file I would like to see day to day has an empty [top image] tag. The original's [top image] field is tagged No and so is hidden from general image view schemes by the rule [top image]=[]

If the [filename] contains "edited" I place a small flag in the thumbnail text area to let me know the image has been edited.

All my images follow the same naming convention... ABC_1234
"ABC" indicates the image source, so, IMG_ is from my canon camera, SCN_ indicates scanned images, and so on, and the 4 numbers are just an incremental file count.
I chose this system as it's the one used by my camera, which is where 90% of my images come from, which equal less work for me!

This means that an edited file takes the name ABC_1234_edited_1 (still with me?)
This means that the first eight characters of the filename of the original and the edited file will always be the same.
I created a library field that pulls the first eight characters from the filename and then created a view scheme that lists all the dupes of that field. This give me version sets of edited files.
When generally browsing images, if I see the "edited" flag in the thumbnail text and wish to see the original and edited together, I right click and choose, "locate > advanced > version set" and MC will show me all associated files (usually just two) together.

For photos I want to stack, I created a standard field called [stack] and just apply numbers to sets of files I want stacked. Stack 1, stack 2, stack 3... etc. etc. After deciding which image should be top of the stack, I select all the other images in the stack and set their [top image] field to "No"
If an image is part of a stack, I set a flag in the thumbnail text area to tell me this, and if I wish to view all images in the stack, "right click, locate, advanced, stack" does the job.

It's all a bit complicated to read, but works very well for me as a work around while we wait for MC to take care of these things for us natively!


Required elements

1. Library Fields
Tools > Options > Library and Folders > User Fields > Add Field
[Stack]
Name: Stack
Type: String

[Top Image]
Name: Top Image
Type: String
Keyword: ti=

[Version Set]
Name: Version Set
Type: Calculated Data
Template: mid([filename (name)],0,8)
keyword: vs=

Note re. [version set]
For the system to work, you must decide upon a standard naming template for all of your images. It makes sense to adopt the naming template used by your camera, whatever that may be. Once decided, adjust the number 8 in the template to match the number of characters you will be using to name your original images. If your existing images need to be renamed to fall into line with this naming system, MC can handle this with ease...
List any images that need to be renamed and ensure that you can see the [filename (name)] field either in a column or in the tag window.
select the first 9 images.
Click to edit the [filename (name)] field and enter: =Basename_000counter(1) and press enter

select images 10 to 99 and repeat above using: =Basename_00counter(10) and press enter

select images 100 to 999 and repeat above using: =Basename_0counter(100) and press enter.

2. The .bat file
Copy the text below into a new text file (adjust the path to photoshop as needed) and save it as a .bat file somewhere safe out of the way. I put mine in MC's Plugins directory and called it photoshop.bat

Code: [Select]

@echo off
copy %1 "%~dp1%~n1_edited_1%~x1"
start /D"C:\Program Files\Adobe\Adobe Photoshop CS3\" Photoshop.exe "%~dp1%~n1_edited_1%~x1"
Back in MC...
Click: "Tools > Send To... > External > Add/edit programs"
Click the "Add" button. Name it "Send copy to photoshop", enter the path to the .bat file you saved earlier and press OK, then press the Exit button.

3. Thumbnail Text
Thumbnail text is configured using the "customise current view" dialogue available via the "View > View Settings" menu.

One of my 3 lines of text is set up like so: [version set]if(isequal([filename (name)],edited,8),/ °,) if(isempty([stack]),,/ ±) [dimensions]
[version set] gives me the base filename,
"°" indicates that the image has been edited,
"±" indicates that the image is part of a stack.


4. Create/edit view schemes to make use of/manage the system