Bone-Headedness
Microsoft Will Eat Yahoo, But...
2008-02-03
That's my take on the Yahoo/Microsoft takeover. The original image was stolen from The Fail Blog who claim to have stolen it from Fark.
Yes it will go through. Yes the Yahoos will hate it. Yes the results will not be pretty. It's a huge opportunity for all the other players in their respective spaces to welcome customers and their money with open arms and great products. Google still has the small issue of creating new products that generate income to deal with, but it will be good for them. Apple will keep focusing great products on the customer.
Fake Steve sums it up best.
|
Send Your Photos To The Fail Blog
2008-01-31
The Fail Blog consists of pictures of things gone wrong and the word FAIL added. Some are set up, some are likely fake (as above), but most are real situations that just ooze failure of one sort of another.
Aperture: Recover Images With File Juicer
2007-12-28
File Juicer is a small Mac OS X application that extracts images, movies, text, and other useful data from practically anything. It's useful to Aperture users in two important ways: it can recover usable images from the library if the masters are lost and and can scrounge deleted images from memory cards.
One of the hazards of working with referenced image masters is that their management is the responsibility of the owner. Accidental deletions are not that uncommon, and if that happens then while Aperture can display the images, it cannot export or otherwise use any of the versions that are based on the lost masters. If the masters are truly lost -- no back ups, nothing in the trash -- then whatever images can be found become valuable.
If high resolution previews were generated, then these can be extracted from the Aperture library by simply selecting the thumbnail images in the browser and dragging them to the desktop. They will be in JPEG format and at a size and resolution that depends on the settings in Aperture's preferences:
If there are no previews, then attention turns to the thumbnail files that Aperture stores in each project. It is these images that are used to display the on-screen thumbnails in the browser pane and as placeholder images in the viewer while Aperture processes the RAW image. The files that contain the thumbnails are called AP.Tinies, AP.Minis, and AP.Thumbnails and contain images at 32, 256, and 1024 pixel sizes respectively. They are also present in exported projects, but not in vaults.
To get to the thumbnails, I control-click on the library and select Show Package Contents. Then I navigate down to the project of interest and open that with a control-click and Show Package Contents:
The AP.Thumbnails file is one big chunk of binary data, but inside there are complete JPEG images. File Juicer will go into it and locate and extract the JPEGs without knowing the format of the file.
I launch File Juicer and check that the preferences are set to include JPEG images (at least):
I also make sure that the extracted files will be stored somewhere sensible, such as on the desktop, because I don't want the extracted images put inside my Aperture library:
With the selections I have made, File Juicer will put each image type into a separate folder and create a parent folder for those. It will also get an HTML index file for easy browsing. To start scanning for images, I drop the AP.Thumbnails file from my project onto the main File Juicer window and wait for it to process:
After processing I get a new folder on my desktop containing the images:
And I can either open the jpg folder and browse the image icons in the Finder (or watch a slide show), or click on the index.html icon and see all the images in a browser window as a panoramic display:
Now my images have been extracted, I can reimport them into Aperture and sort through them. They will be smaller then the originals -- only up to 1024 pixels on a side-- and there will be one image per version. So a single lost master will result in five recovered JPEGs if it had five versions in that project. This is good because I get my adjusted images, albeit at low resolution.
Since File Juicer is scavenging for JPEGs rather than following any information that Aperture provides, there are some side-effects. The first is that there may be old images or possibly corrupted images in the folder of JPEGs. The second is that the names of the images are sequential and bear no relationship to the order in which they were taken or anything else. The third is that there is no EXIF or other metadata in the JPEGs, so all the keywords, camera and shooting data are lost.
File Juicer will also recover RAW and other images that have been deleted from camera cards, so if masters have been lost it is possible that they can be obtained that way. The process is very similar to the thumbnail recovery described here, except that there is an extra step at the beginning where File Juicer creates a disk image of the card and scans that.
The File Juicer web site has a page dedicated to its use with Aperture, and one about RAW image formats.
Aperture: How Do I Restore A Single Image From A Vault?
2007-12-13
Yes, single images can be retrieved from vaults. By navigating down into the vault or by searching, the image can be located and copied out using the Finder. Once copied, it can be imported back into Aperture. This will lose all versions and adjustments, and any metadata that is not part of the original master file.
But first, check for the image in the trash. Images in Aperture that are deleted are put into the trash in a folder called Aperture. Inside that is another folder with the name of the project the image was in. Inside that is the images deleted from that project.
I'll find and restore a deleted image from a vault. The organization of a vault is very similar to that of the library, so delving into the vault is very similar to delving into the library. Since in this case I know that the name of the deleted image included the number 2486, I can search on that. First I open the vault using control-click and Show Package Contents:
Then by typing the part of the name I know into the Finder's search box, I can quickly locate the image:
I can use the slideshow and other features of the Finder window to examine my image. Once located, I option-drag the image out of the Finder window to copy it to the desktop, then drag it onto a project in Aperture to import it again.
If I had not already known part of the name of the image, then I would have had to do more work. By typing JPG into the search box (since I know that my master image was a JPG) I can find all the images and then browse through them:
This will of course work for other file name extensions such as CR2 or NEF. Selecting a image in the Finder window shows the full path at the bottom and double-clicking a folder in that list will open the folder for further examination. Control-click can be used to open projects that show up the path by selecting Show Package Contents. As before I can option-drag image masters out to copy them and restore them to Aperture.
If the deleted image is not in the trash and also not in the vault, there is one last place it may be. Images deleted from vaults by a vault update are not removed entirely, but they are not put into the trash. Instead the folder that holds the vault contains a folder with Deleted Images in its name. Inside that is a folder named for the date and time of the vault sync that removed the image from the vault. Inside that are folders for the deleted images and the masters:
My image is now available for reimporting into Aperture. The techniques I show here can also be used to find out if the image really was deleted from the Library in the first place.
Aperture: Hazards of Referenced Masters -- Bone-Headedness Part 4
2007-07-19
This is the last in a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?
From the Finder I select the top-level folder of the folder structure to protect and press command I to bring up the Info window. I open up the permissions part at the bottom, and it looks like this:
By changing the Details pop-ups to Read Only and applying it to all enclosed items, the settings are propagated to all the files and folders:
Now if I try to modify a file, I get a dialog like this:
I get an opportunity to override by authenticating, but usually I would not want to, just accepting the OK button. If I drag a file to the trash, I get the same dialog.
To change everything back, I use the same procedure, this time setting the permissions to Read and Write for myself.
Part 4: Write Protect
For maximum paranoia against accidental modification or deletion, write protect the master image files. This can be easily achieved from the Finder.From the Finder I select the top-level folder of the folder structure to protect and press command I to bring up the Info window. I open up the permissions part at the bottom, and it looks like this:
By changing the Details pop-ups to Read Only and applying it to all enclosed items, the settings are propagated to all the files and folders:
Now if I try to modify a file, I get a dialog like this:
I get an opportunity to override by authenticating, but usually I would not want to, just accepting the OK button. If I drag a file to the trash, I get the same dialog.
To change everything back, I use the same procedure, this time setting the permissions to Read and Write for myself.
Aperture: Hazards of Referenced Masters -- Bone-Headedness Part 3
2007-07-14
This is a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?
But when they are relocated, where should they be put? Everyone has a different system for doing this. Often that system arose from a need to either find images or process them, but these are requirements that Aperture does not have of disk storage: the library and its tools take over that organizational role.
What is left to organize? There must be some logic to the folder structure. My answer is to organize around change and minimize risk. What can change?
If you are storing referenced masters primarily chronologically, say by month, then you add a new drive and all the new images get put on the new drive and the old ones stay on the old drive. It's a quick upgrade and you are unlikely to accidently delete or damage anything. Further, you can stop backing up the old drive: it will never change. Just keep the old off-site back up until you get rid of the smaller drive a few years from now. One small catch is that the addition of the new drive will happen mid-month. So do you have two July folders, one on each disk, or move the July folder to the new disk and then continue adding to it? I recommend the latter, and will be looking at how that can be achieved in this article.
If you are not storing referenced masters primarily chronologically, then the approach is different. Masters organized by client and then by project cannot be handled the same way as the strictly chronological system because any client could ask for another project and overrun an already-full disk. In this case it makes sense to copy everything over and stop using the old disk. Copying between disks can take a little while, even with fast disks -- about an hour per 100GB -- so this is something that may take some planning. The catch with this method of storage expansion is that backing up will need to include both drives now, so don't forget to change your settings or procedures to do that.
Both method of adding storage require copying, and Aperture can do it for you. In fact you should always use Aperture to do the copying. In that way Aperture always knows where its library masters are at all times and reconnecting is never needed.
To move referenced masters to another drive using Aperture, relocate them using exactly the same system of organization that was in use on the old drive. You already have a preset for this because the current organization or referenced masters was built with it.
I described one folder systems based primarily on date, and another based on client and project. But there are others. Which one is best? In my mind the best folder system is one that Aperture can create and maintain and that can be adequately backed up incrementally.
That may sound restrictive because you may not want to look at a library organized that way, but remember that the folder organization on the disk does not have to follow the library organization at all. For instance your library may be organized by client and then city (both using blue folders) and then by project because your work involves travel to different locations for each client to shoot vacation accommodation. But since renovation is common, you almost never need access to images that are more than three years old. So you organize your referenced masters on the disk by year and project (using Finder folders) and archive a whole year at a time to DVDs or a hard drive each time you start a new year. Note that the library still contains the thumbnails and the metadata for all images, allowing you to view, tag, and find those other images at any time.
Organize masters to reflect how you archive images and manage storage. Organize the library to reflect how you find and work with images.
Part 4 has been posted.
Part 3: Organize Masters For Growth
Relocating and renaming masters imported into Aperture helps to ensure that they will not be accidently altered, misplaced, or deleted as referenced files.But when they are relocated, where should they be put? Everyone has a different system for doing this. Often that system arose from a need to either find images or process them, but these are requirements that Aperture does not have of disk storage: the library and its tools take over that organizational role.
What is left to organize? There must be some logic to the folder structure. My answer is to organize around change and minimize risk. What can change?
Adding Storage
The first thing that changes is that the disk fills up and more is needed. Unless you have a RAID system that can be transparently expanded, you must either add a new disk to your computer and split the masters across both, or replace the old disk with the new one and copy everything over. Which is the better approach depends on how the masters have been organized, so ideally your master organization is planned according to your plans for expansion. Do you have any plans for expansion?If you are storing referenced masters primarily chronologically, say by month, then you add a new drive and all the new images get put on the new drive and the old ones stay on the old drive. It's a quick upgrade and you are unlikely to accidently delete or damage anything. Further, you can stop backing up the old drive: it will never change. Just keep the old off-site back up until you get rid of the smaller drive a few years from now. One small catch is that the addition of the new drive will happen mid-month. So do you have two July folders, one on each disk, or move the July folder to the new disk and then continue adding to it? I recommend the latter, and will be looking at how that can be achieved in this article.
If you are not storing referenced masters primarily chronologically, then the approach is different. Masters organized by client and then by project cannot be handled the same way as the strictly chronological system because any client could ask for another project and overrun an already-full disk. In this case it makes sense to copy everything over and stop using the old disk. Copying between disks can take a little while, even with fast disks -- about an hour per 100GB -- so this is something that may take some planning. The catch with this method of storage expansion is that backing up will need to include both drives now, so don't forget to change your settings or procedures to do that.
Both method of adding storage require copying, and Aperture can do it for you. In fact you should always use Aperture to do the copying. In that way Aperture always knows where its library masters are at all times and reconnecting is never needed.
To move referenced masters to another drive using Aperture, relocate them using exactly the same system of organization that was in use on the old drive. You already have a preset for this because the current organization or referenced masters was built with it.
Archiving
In deciding how to organize referenced masters there is more to consider than just storage expansion. The other change that occurs is that archiving is needed: some images no longer need to be at-hand and can be stored more cheaply or in a place that is not immediately available. These are not back-ups (copies stored short-term as insurance that you hope to never need) -- they are archives (originals stored long-term with the expectation that they will be needed).I described one folder systems based primarily on date, and another based on client and project. But there are others. Which one is best? In my mind the best folder system is one that Aperture can create and maintain and that can be adequately backed up incrementally.
That may sound restrictive because you may not want to look at a library organized that way, but remember that the folder organization on the disk does not have to follow the library organization at all. For instance your library may be organized by client and then city (both using blue folders) and then by project because your work involves travel to different locations for each client to shoot vacation accommodation. But since renovation is common, you almost never need access to images that are more than three years old. So you organize your referenced masters on the disk by year and project (using Finder folders) and archive a whole year at a time to DVDs or a hard drive each time you start a new year. Note that the library still contains the thumbnails and the metadata for all images, allowing you to view, tag, and find those other images at any time.
Organize masters to reflect how you archive images and manage storage. Organize the library to reflect how you find and work with images.
Part 4 has been posted.
Aperture: Hazards of Referenced Masters -- Bone-Headedness Part 2
2007-07-10
This is a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?
You can relocate masters in two ways: either by selecting individual images and from the File menu going to Relocate Masters For Library... or by control-clicking on a project and selecting Relocate Masters for Project to relocate an entire project full of images at once:
Relocating the masters also has the ability to rename as it moves. To relocate and rename at the same time, set up a new Name Format preset from the Relocate masters sheet:
By clicking on the Name Format drop-down and selecting Edit... Give the new name format a name and set it up something like this:
Then select that new name format and do the relocate. As the files are moved, the names will be changed. Here is a referenced master on the disk after it was relocated (I used a slightly different prefix than above in this example to show this image is referenced, omitting the dash):
The original image was called 6830-1.JPG. Importing added MAS-2005-04-20 and relocating added REF.
Why work this way? This workflow keeps all the images that are still being worked on in one place so they can easily be found with a smart album that shows only managed masters. This workflow means that if it's managed, then you're not done with it. The library becomes a staging area. Once relocated and renamed, the master files are immediately identified as being referenced from their name and you know that they have already been processed and so are ready for use or to be archived. And, since importing into the library makes a copy, the originals are still on the card or disk they came from and another layer of corruption insurance has been created.
Creating a smart album to show only managed files is straight forward. Create a new smart album by clicking on the magnifying glass next to the library (so it will apply globally) and add a File Status filter:
Then filter on Managed status and check the Ignore stack groupings box so that stacks don't hide any images:
Part 3 has been posted.
Part 2: Manage, then Relocate
Always import new images into the library as managed masters as a first step. Then edit, cull, rate, tag, stack as usual. Then finally move the masters out of the library using the Relocate command to a reserved area of your disk and add another prefix to show that they are referenced, such as "REF". Finally, possibly much later, delete the rejects.You can relocate masters in two ways: either by selecting individual images and from the File menu going to Relocate Masters For Library... or by control-clicking on a project and selecting Relocate Masters for Project to relocate an entire project full of images at once:
Relocating the masters also has the ability to rename as it moves. To relocate and rename at the same time, set up a new Name Format preset from the Relocate masters sheet:
By clicking on the Name Format drop-down and selecting Edit... Give the new name format a name and set it up something like this:
Then select that new name format and do the relocate. As the files are moved, the names will be changed. Here is a referenced master on the disk after it was relocated (I used a slightly different prefix than above in this example to show this image is referenced, omitting the dash):
The original image was called 6830-1.JPG. Importing added MAS-2005-04-20 and relocating added REF.
Why work this way? This workflow keeps all the images that are still being worked on in one place so they can easily be found with a smart album that shows only managed masters. This workflow means that if it's managed, then you're not done with it. The library becomes a staging area. Once relocated and renamed, the master files are immediately identified as being referenced from their name and you know that they have already been processed and so are ready for use or to be archived. And, since importing into the library makes a copy, the originals are still on the card or disk they came from and another layer of corruption insurance has been created.
Creating a smart album to show only managed files is straight forward. Create a new smart album by clicking on the magnifying glass next to the library (so it will apply globally) and add a File Status filter:
Then filter on Managed status and check the Ignore stack groupings box so that stacks don't hide any images:
Part 3 has been posted.
Aperture: Hazards of Referenced Masters -- Bone-Headedness Part 1
2007-07-06
Hello, I stumbled onto your page looking for help with Aperture., I'm new to digital photography and I think I accidentally moved my, master files to a removable hard drive and then deleted them, thinking, that they were saved in a vault somewhere else. Obviously I don't know, what I'm doing, but is there anyway to get aperture to let me work, with the library images that it has on my hard drive? All of my, pictures are there, in good enough resolution, but aperture won't let, me do anything with them because I don't have the masters. No, exporting, no emailing, no editing, nothing., Am I stuck with looking at these pictures forever and that is it?, Thanks a bunch for any help.
I see a quite a few postings on message boards and get emails from Aperture users who have done disastrous things to their referenced masters because they didn't realize that the files were still part of their Aperture library. Referenced masters are master image files stored outside the Aperture library. This feature allows a small internal hard drive, such as on a laptop, to maintain a very large image library where the originals are stored on a separate removable drive or central storage system. In the other kind of master storage, managed masters, the masters live inside the Aperture library itself. While not impossible, damaging managed masters takes some persistence and the barrier formed by the library protects them against most bone-headed errors.
That referenced masters live outside the library leaves them prone to several kinds of abuse. Moving them by hand is harmless, unless the move goes to another volume. That will break the connection with the library and require a reconnect. Aperture's Referenced File Manager does this well, but it is very fussy about restoring the connection. If the image has been edited, for instance, it will likely not reconnect. If the pixel dimensions have changed, it will not reconnect. If the file size has changed, it will not reconnect. And this is where the big problems start. Since Aperture only checks these things when reconnecting, problems can go undetected for a very long time. A reconnect is needed and suddenly many masters (and hence their versions) are effectively lost.
The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?
This the first of a four-part series on protecting referenced masters.
The input screen allows a selection for the version name and can optionally rename the masters:
Above that setting is a block of information that gives confirmation of the change if an image is selected:
Another recommendation is to rename the masters in such a way that all of them have unique names. For instance, add the current date to the name given by the camera. This will ensure that as the camera or card numbering rolls over, the images still have unique names. While not critical, this defensive step may help in the future when it is necessary to list or index all of the images. Ensuring unique naming now will obviate managing duplicates and messing with hierarchies later on.
At the bottom of the Version Name drop-down the Edit... option allows the naming schemes to be edited. Here is how MAS prefix used above is defined:
Part 2 has been posted.
I see a quite a few postings on message boards and get emails from Aperture users who have done disastrous things to their referenced masters because they didn't realize that the files were still part of their Aperture library. Referenced masters are master image files stored outside the Aperture library. This feature allows a small internal hard drive, such as on a laptop, to maintain a very large image library where the originals are stored on a separate removable drive or central storage system. In the other kind of master storage, managed masters, the masters live inside the Aperture library itself. While not impossible, damaging managed masters takes some persistence and the barrier formed by the library protects them against most bone-headed errors.
That referenced masters live outside the library leaves them prone to several kinds of abuse. Moving them by hand is harmless, unless the move goes to another volume. That will break the connection with the library and require a reconnect. Aperture's Referenced File Manager does this well, but it is very fussy about restoring the connection. If the image has been edited, for instance, it will likely not reconnect. If the pixel dimensions have changed, it will not reconnect. If the file size has changed, it will not reconnect. And this is where the big problems start. Since Aperture only checks these things when reconnecting, problems can go undetected for a very long time. A reconnect is needed and suddenly many masters (and hence their versions) are effectively lost.
The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?
This the first of a four-part series on protecting referenced masters.
Part 1: Name Defensively
When you import, rename the masters in such a way that all of them can be seen to be masters. Prefixing with "MAS" or an equivalent short word will make masters instantly recognizable and you will no longer feel compelled to trash them in haste.The input screen allows a selection for the version name and can optionally rename the masters:
Above that setting is a block of information that gives confirmation of the change if an image is selected:
Another recommendation is to rename the masters in such a way that all of them have unique names. For instance, add the current date to the name given by the camera. This will ensure that as the camera or card numbering rolls over, the images still have unique names. While not critical, this defensive step may help in the future when it is necessary to list or index all of the images. Ensuring unique naming now will obviate managing duplicates and messing with hierarchies later on.
At the bottom of the Version Name drop-down the Edit... option allows the naming schemes to be edited. Here is how MAS prefix used above is defined:
Part 2 has been posted.
The Bagelturf site welcomes Donations of any size