Referenced images in catalogs use absolute paths to images
In a very old Image Quality Professor's Blog, the author--Niels Knudson--mentions in a comment to the article that the "links" or the paths to referenced files in the catalog are relative to the location of the catalog. This is clearly not true. It should be true and it would be nicer if it were true, but alas it is not. A simple experiment can prove this. I've done the experiment many times. Many posts in these forums suggest that many users experience problems moving images and especially folders. This comes up when doing a remote shoot and using a laptop on sight and bringing the images home or when backing up and restoring catalogs.
None of the posters see the underlying cause for the frustration. The cause is that the paths to referenced image files in a catalog are absolute--the path starts at the volume label for the storage medium and then leads to the file. This means you can't just move a catalog and its folders to another drive. The good news is that there is a quick and easy work-around. Just "locate" the highest level folder that contains "everything" on the new drive and everything beneath that folder will be instantly--and I do mean instantly--fixed. But, a work around would not be necessary if relative paths were used. Knudson says that the paths are relative though I can see no documentation provided by Phase One and no posts that confirm this. Knudson understands the concept but his post is the only one I can find that mentions this. His sole post and the many forum posts that describe problems--with the solution always being to re-LOCATE--suggests that his comment near the end of the blog post is not correct.
Here is my scenario and the experiment. (Note: I wrote this as a reply to the blog post, but the original post is from 2012 so the comment might not get published. I understand; it's ok.)
=========================
I am preparing for a bit of a photo expedition in which I will put catalogs/photos on a master external drive and have others as backups.
The structure is simple. An outer containing folder. Let's call it "outer". Inside outer, at its top level, create the catalog db, call it "catdb". Add images via import image from SD card to subfolders inside "outer". Now, it is easy to move everything simply by moving or copying the folder "outer".
I have recently discovered several inconveniences with this because C1 (v. 9) does NOT use relative links as you state. Sadly--and mistakenly I believe--it uses absolute links.
This is very easy to verify. Connect a USB drive. Create a folder. Create a new catalog inside the folder. Import images to the catalog and save the images in folders (1 or more) inside the original folder. Close C1.
Copy this entire folder onto the local drive of the machine. Eject the USB drive. Start C1 with some other catalog that is located on the local drive (perhaps this is your master catalog). Import the catalog db, "catdb" in the folder, "outer", you copied from the USB drive. All of the images will appear as offline. Choosing show parent folder in library will show the folder from the now offline volume.
You can fix this quickly by locating the outer containing folder as the copy on the local drive. Now C1 adjusts all links and everything is online.
But, if it were *true*, as you indicated, that the links from the catalog to the images were truly relative this step would not be needed. Please try this simple experiment. Either you are describing what is reasonable (for sure) but not true or there is a pretty big bug.
I have done this experiment several times. Even though the physical images are clearly present, the "links" (paths) in the catalog point to the offline volume. Maybe there is a technical reason that C1 developers can point to. But, it seems unfortunate and it would be better if it really did work as you describe.
======================
If you understand what is going on and you've structured the outer folder, the catalog, and the folders containing referenced images in a strict hierarchical or "contained" structure, the fix is easy with no side effects. The end result is what you (probably) wanted.
If you are not quite clear about the catalog and folder relationships then things can get frustrating leading to much gnashing of teeth, catalog hate, and preference for sessions. But, sessions and catalogs are very close cousins. Much of the catalog frustration could be at least partially reduced by using relative paths.
Does Phase One consider this a bug? I'd assume not because the software has worked this way for a long time and the developers certainly know the difference between absolute and relative file paths. So, this is "by design." I'd like to humbly submit that this is not a good design and C1 should seriously consider changing to relative paths to referenced images. It may seem like there would be problems but some carefully diagramming of the many cases will prove that every case that works with absolute paths will also work with relative paths and many additional scenarios that break with absolute paths will work with relative paths. The only tricky case that absolute paths handles well is the case of multiple physical volumes connected to one machine with a catalog containing referenced images across the various volumes. But, relative paths created correctly would map this out--the paths would look absolute.
In any case, I have a fine solution for my needs but I can't help thinking that many people's frustrations would be solved with relative paths. A little documentation of file structure would go A LONG WAY. The "cookbooks" on offer try to make things seem simple, but a user is left mystified when something unexpected happens. The sessions/catalog dichotomy is not as strong as people think. Both are good options and the added flexibility is good--and would be better yet if made clearer.
Thanks!
None of the posters see the underlying cause for the frustration. The cause is that the paths to referenced image files in a catalog are absolute--the path starts at the volume label for the storage medium and then leads to the file. This means you can't just move a catalog and its folders to another drive. The good news is that there is a quick and easy work-around. Just "locate" the highest level folder that contains "everything" on the new drive and everything beneath that folder will be instantly--and I do mean instantly--fixed. But, a work around would not be necessary if relative paths were used. Knudson says that the paths are relative though I can see no documentation provided by Phase One and no posts that confirm this. Knudson understands the concept but his post is the only one I can find that mentions this. His sole post and the many forum posts that describe problems--with the solution always being to re-LOCATE--suggests that his comment near the end of the blog post is not correct.
Here is my scenario and the experiment. (Note: I wrote this as a reply to the blog post, but the original post is from 2012 so the comment might not get published. I understand; it's ok.)
=========================
I am preparing for a bit of a photo expedition in which I will put catalogs/photos on a master external drive and have others as backups.
The structure is simple. An outer containing folder. Let's call it "outer". Inside outer, at its top level, create the catalog db, call it "catdb". Add images via import image from SD card to subfolders inside "outer". Now, it is easy to move everything simply by moving or copying the folder "outer".
I have recently discovered several inconveniences with this because C1 (v. 9) does NOT use relative links as you state. Sadly--and mistakenly I believe--it uses absolute links.
This is very easy to verify. Connect a USB drive. Create a folder. Create a new catalog inside the folder. Import images to the catalog and save the images in folders (1 or more) inside the original folder. Close C1.
Copy this entire folder onto the local drive of the machine. Eject the USB drive. Start C1 with some other catalog that is located on the local drive (perhaps this is your master catalog). Import the catalog db, "catdb" in the folder, "outer", you copied from the USB drive. All of the images will appear as offline. Choosing show parent folder in library will show the folder from the now offline volume.
You can fix this quickly by locating the outer containing folder as the copy on the local drive. Now C1 adjusts all links and everything is online.
But, if it were *true*, as you indicated, that the links from the catalog to the images were truly relative this step would not be needed. Please try this simple experiment. Either you are describing what is reasonable (for sure) but not true or there is a pretty big bug.
I have done this experiment several times. Even though the physical images are clearly present, the "links" (paths) in the catalog point to the offline volume. Maybe there is a technical reason that C1 developers can point to. But, it seems unfortunate and it would be better if it really did work as you describe.
======================
If you understand what is going on and you've structured the outer folder, the catalog, and the folders containing referenced images in a strict hierarchical or "contained" structure, the fix is easy with no side effects. The end result is what you (probably) wanted.
If you are not quite clear about the catalog and folder relationships then things can get frustrating leading to much gnashing of teeth, catalog hate, and preference for sessions. But, sessions and catalogs are very close cousins. Much of the catalog frustration could be at least partially reduced by using relative paths.
Does Phase One consider this a bug? I'd assume not because the software has worked this way for a long time and the developers certainly know the difference between absolute and relative file paths. So, this is "by design." I'd like to humbly submit that this is not a good design and C1 should seriously consider changing to relative paths to referenced images. It may seem like there would be problems but some carefully diagramming of the many cases will prove that every case that works with absolute paths will also work with relative paths and many additional scenarios that break with absolute paths will work with relative paths. The only tricky case that absolute paths handles well is the case of multiple physical volumes connected to one machine with a catalog containing referenced images across the various volumes. But, relative paths created correctly would map this out--the paths would look absolute.
In any case, I have a fine solution for my needs but I can't help thinking that many people's frustrations would be solved with relative paths. A little documentation of file structure would go A LONG WAY. The "cookbooks" on offer try to make things seem simple, but a user is left mystified when something unexpected happens. The sessions/catalog dichotomy is not as strong as people think. Both are good options and the added flexibility is good--and would be better yet if made clearer.
Thanks!
0
Post is closed for comments.
Comments
0 comments