Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
Latest posts of: Dale
The DAM Forum
Welcome, Guest. Please login or register.
October 28, 2020, 10:55:59 AM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
  Show Posts
Pages: [1] 2 3
1  DAM Stuff / Hardware Discussions / Re: Notebooks for Road Workflow on: July 21, 2011, 03:49:26 PM
Thanks. I already got a laptop about 3 weeks ago that unfortunately has a glossy screen. I have found a 15" screen about right. It's hard to edit photos on a screen smaller, and 17" is too large to travel with if you fly much--otherwise it would be the choice. However the 15.6" widescreen that I got is not nearly as good as the old 15" closer-to-square format because it gives us valuable height.
2  DAM Stuff / Hardware Discussions / Notebooks for Road Workflow on: May 01, 2011, 11:20:50 PM
I need to replace my notebook computer. Normally I edit photos on the desktop, but at times when I'm overseas for several months I must edit on the notebook computer. That caused me to ask what are the most important criteria for a laptop that you may incorporate into a road workflow. Here are my thoughts in order of importance.

  • A non-glossy screen may be the most important (though hard to find).
  • Size and weight are important for airline travel.
  • Larger hard drives are a plus, though portable drives can substitute.
  • A good graphics card for when an external monitor is available.

Thoughts on these criteria? On machines that best fit the criteria?

Dale
3  DAM Stuff / Keywords and Controlled Vocabulary / Re: Uniquely Identifying People on: January 04, 2011, 09:34:40 AM
Quote
Should I document the people in the photo in the caption/description (e.g. "From Left to Right: Mary (Jones) Smith, Jim Smith, Robert Jones taken in Boise, Idaho ca. 1920")?

Generally I'd say dates and places are not necessary in the description because you have metadata fields for the place and date. And, if you have a lot of photos taken at one time and place, it can get tedious. However because you're wanting to document it within the photo for genealogy purposes, and may share a single photo with someone, I think you're right on track to put more information in the description.

I always identify people in a L-R, F-B order so I don't have to put that in the description. However if you're concerned about someone looking at it later and not knowing that's your standard, I'd use (L-R) or (L-R/F-B) to be a little less obtrusive. Whatever you're comfortable with.

For genealogy photos, if there is a story that goes along with it, I'd put it in the description. Chances are, whoever you share the photo with in that case is interested in the story.

You could put your genealogy database numbers in the caption to identify the people, e.g. Jim Smith (1145), but personally I wouldn't because they won't mean anything to anyone else. I'd do that with a tag instead.

If you have information that you'd like to become part of the photo record, but don't necessarily want it to print in a caption or description, I've found the Instructions field a good field to hijack for that purpose.

Dale
4  DAM Stuff / Backup Strategies and Tools / Backup, Versioning, Mirroring on: November 14, 2010, 10:35:06 PM
I have a question about backup of working files. Here's the situation, which is pretty much Figure 6.24 in the book...

  • P Drive is main drive for working files (external)
  • E Drive is physical internal hard drive (2nd drive) holding backup of working files from P drive
  • T Drive is rotational external hard drive holding backup of working files from P drive

I am using SyncBack Pro and verifying the copies. I like the fact that it keeps the files in native format so corrupted proprietary files are not an issue.

Question One
Should the P->E and P->T be backups, versioned, or mirrored?

The figure in the book shows mirrored, and my preference is mirrored. One reason is simplicity which is highly important. When I rename a file or move it on P, I have a clean copy of what's on P. Another reason is that it keeps the backups from filling up. A third reason is that if you had to do a complete restore you wouldn't have to go through and weed out old files.

My fear is this. I once synced a directory between my computer and my son's (using the precursor of Windows Live Sync if I recall right). One of the hard drives crashed; it thought all the files were deleted from the drive; therefore it deleted them off the other drive as well. It put them all in the recycle bin so they were recoverable, and I had a backup anyway. But if the backup is a mirror, then I'm concerned about propagating a failure if the P or E drive crashes.

Dale
5  General / General Discussion / Re: Field for Slide Mount Information on: October 19, 2010, 05:58:27 AM
John,

Yes, I missed it earlier but now that you pointed out that it is on the Advanced tab, I see it.

Since LR won't display or allow searching or filtering on custom fields, it diminishes the value of creating them. On the other hand IDImager will display and allow edits and searches on it, so there is some value in it. I'm considering using the Instructions field for things like genealogy notes, people's names, etc. that I'd like to have readily accessible in LR, and use the custom fields for cross-reference data that I would work with in IDI, but I haven't decided for sure yet.

I would be interested in seeing it in its own panel, and it's probably time I dug into XML anyway. Fire away.

Am I correct in thinking that your plug-in allows creation of custom fields but that LR won't allow them to be written to XMP? That raises a question. If custom fields are already created, say in IDI, and written into the image, would your plug-in allow them to be seen in LR?

Dale
6  General / General Discussion / Re: Field for Slide Mount Information on: October 18, 2010, 02:07:10 PM
I created a set of custom fields in IDimager -- very easy to do once you have instructions. I then populated them for an image and saved the metadata to the image. I was able to edit it and search on it in IDI.

I opened the image in PS CS5 and viewed the photo information. The custom metadata showed up under the Raw Data tab, but nowhere else that I could find.

I was not able to find the metadata showing up in either Bridge or LR3.

Peter's idea of separating the data into individual fields seems to be the desired solution. It raises the question, though, that if LR won't see custom fields, then that approach might require hijacking unused fields. I would have thought that LR would have recognized the fields.

Dale

7  General / General Discussion / Re: Field for Slide Mount Information on: October 14, 2010, 08:42:42 PM
I wasn't too precise on that last post. Sorry. When I said I didn't know how to do it with existing fields, what I meant is that I'd need to hijack several existing fields as I've done with the instruction field, and it's not clear how to go about finding the best ones. Maybe it doesn't matter just so long as I'm not using them for what they're intended.

Re-reading Peter's comments, though, gave me the thought that creating custom fields would be perfect. A quick google led me to the conclusion that this might not be possible with LR3. It is supposed to be possible to create a custom schema and fields with IDImager--while I haven't yet gotten it working, I think it's a matter of finding the documentation to understand a setting I probably got wrong. The basic process seems fairly easy. It also appeared that Beardsworth has a plug-in that seems like it would do it.

Dale
8  General / General Discussion / Re: Field for Slide Mount Information on: October 13, 2010, 09:33:11 AM
Quote
Keeping the singular data segregated into individual fields makes the data more useful. Even if, at a later date, you need to move it somewhere else.
I meant to add also that your thought here makes sense to me. I'm just not sure how to do it with existing fields, unless you're talking about something like putting the data in a field like instructions but using a separator character.

Dale
9  General / General Discussion / Re: Field for Slide Mount Information on: October 13, 2010, 09:27:23 AM
Here's the data I'm looking at.


Technical Data:

First, aperture, shutter speed and camera model where I recorded them. LR3 and IDImager don't seem to edit those XMP fields. Even if they could you have multiple data to contend with -- the original camera information, and the information from the camera or scanner that did the scan. Right now I'm putting aperture and shutter speed into the instruction field. Camera model is in my head, not written on the slide, so I haven't done anything with it yet.

Second, when I download images I append KChr to the file name to identify Kodachrome originals. Where a scanner was used rather than a camera scan, I use an identifier like ROC to identify  automation like Reconstruction of Color. Later when I catalog them, I apply catalog labels for them, then do a bulk rename to remove the appendages from the file name. Since it's done bulk there's virtually no time involved.


Serial Numbers:

The most prevalent data is the original slide serial number which lets me find the original again when needed. Example: 80BA36 = 1980, November, Roll 10, Slide 36. This appears on almost every slide. I'm putting it in the instructions field.


Identifying Information:

Notes written on the mount as to who the people are or what the scene is, or where it was taken. For location data, the location fields seem to be fine. For other data, I am putting it in the instructions field because I want to write the description field without compromising the original data.


Sequencing Information:

In a few rarer cases I want to keep the slide processing number (e.g. JUN 81C6 in red or black letters). Mostly I don't see why I'd need it. I has been helpful where I need to sequence slides from an old overseas trip. In some cases I pulled three or four slides out of a trip set of 3,000 and neglected to write a serial number on them so it's not always clear where they belong. In some cases I shot part of roll A, then needed higher speed film, so I took roll A out, and replaced it with roll B, then later reinserted roll A to finish it (back in those days I couldn't afford to waste half a roll of film) -- things like that. I'm only capturing it in those rare instance where it may be helpful inr econstructing sequecing.


Original Copyright Date

No problem here since the copyright fields are available.


There may be something I'm forgetting, but that's probably 99% of it. I didn't do any keywords or stock placement in those days, so that is not an issue.

I'm open to other suggestions.

Dale

10  Software Discussions / Lightroom / Re: Lightroom Catalog in External HDD Workflow on: October 11, 2010, 02:23:37 PM
I would say it is less risky to keep it on the main system for two reasons: (1) theft, (2) accidental damage. Having said that, though, I don't know how much more significant the risk is, especially if you have multiple backups.

The other problem is that the catalog changes frequently, so backups are best handled differently, which I recall Peter mentioning in the book also. Given that, though with a good backup program you can still back up the catalog and working files differently.

I like your approach for not having to trade changes. But then if the working photos plus archives outgrow the HDD and I go to multiple ones, that creates another level of complexity if the catalog is on one of the HDDs. I have a 1T portable external, but I'm scanning a lot of old slides and negatives and at 12Mpxl for newer shots it adds up. Also I keep some derivative photos on my laptop for use in newsletters, slide shows, etc., that I don't need anywhere else. Ultimately, though, simplicity has a lot to say for itself.

I didn't think Acronis did native file backups. I insist on that. I once had another program and needed to recover a file. Only after it read in 17 DVDs (which should have been unnecessary) did it tell me that the 18th was corrupt, so even thought the file, which was on the 19th, might have been fine, it wouldn't let me go any farther. After that it was only native file backup for critical data. Acronis may not have that problem, though, I don't know. I do use cloning software (ShadowProtect Desktop) to backup the OS should that drive crash.

Dale
11  Software Discussions / Lightroom / Re: Lightroom Catalog in External HDD Workflow on: October 11, 2010, 08:53:49 AM
Quote
I keep a backup of the pics and catalog on a second external HD.
What software do you use to mirror the hard drive?

Quote
Seems to me that Dale's approach is simpler than having to sync two different catalogues.
That's actually part of what I'm trying to decide...Peter has a method on p333 of trading changes that I've looked at since he believes that it's dangerous to keep a catalog on an external drive. It doesn't sound too difficult, though it is one more thing to remember. On the other hand it sounds like Drayken has had no problem with keeping his catalog on the external drive. The other alternative to Peter's approach would be to simply sync the catalog on a given machine to the external drive each time you mounted it on that computer. I don't know how time-consuming that would be, and it, too, is another thing to remember.

Dale
12  General / General Discussion / Re: Field for Slide Mount Information on: September 24, 2010, 07:00:45 AM
John,

Quote
Which program are you using? If you're using iView/ExMedia, then I would set up a custom field. If Lightroom, maybe look up my Bog Note plug-in.
For ingestion and initial metadata entry I use IDImager. For rendering and catalog management I use LR3. (Actually I'm still undecided on using IDI vs LR3 for catalog management, but since the hierarchical keywords are compatible I've been able to postpone the decision.)

I looked up Big Note and I think if LR ever permits a plug-in to write to XMP, it would be exactly what I need. I would like this information to be permanently stored with the image.

Quote
Or you could just misuse another field - Instructions?
That may be the best option for now. I looked up the description of that field, and since I'm not using it, and if I stretch things a bit, what I'm needing to store is loosely related, I may start there.

Thanks for your suggestions!

Dale
13  General / General Discussion / Field for Slide Mount Information on: September 21, 2010, 06:37:43 PM
As I scan old slides I put the information written on the slide mount (including but not limited to serial number) in the description field in angle brackets to provide a permanent record of what was on the mount.

The description field is not the best place for it. Does anyone know what field is best suited for this?

Dale
14  General / General Discussion / Re: Defining Archives on: September 20, 2010, 03:12:06 PM
Becky,

Quote
As the book uses the terms, they are not interchangeable. "Archive" refers to images which have been through ingestion and the Working pipeline and have been moved to their permanent home. After being put in the Archive, the files will not be physically moved again (until you upgrade storage.) It's not a backup. "Archive" is opposed to "Working" files, which are still moving through the Workflow pipeline (getting metadata and ratings added.) When an image has moved through all the steps of the Working pipeline, it moves into the next available bucket in the Archive and isn't in the Workflow pipeline anymore. Thanks to magic cataloging software, the metadata you added remains associated with it.

"Backup" is a duplication of your files so they can be recovered if lost or stolen. You want a Backup of Working files and also Archive files, since that represents your entire inventory of images.
I think the light bulb just came on. An archive is nothing more than an image in its permanent home. Therefore you only have two archives -- The RAW archives for non-destructively edited images, and the derivative archives for derivative images. in essence any image, original or derivative, appears in only one of three places -- working folder, RAW archive, or derivative archive.

The original camera raw file is backed up, but never archived.

Rereading the book with that in view is enlightening. It also makes thinking about the whole backup process much simpler.

Quote
The Virgin Download backup and/or pre-workflow backup is a separate issue. The ingestion moment is a vulnerable one, since the images aren't backed up anywhere yet and you are "touching" them when you do the transfer from the media card. If you want an extra layer of protection as you are downloading from the media card, you can have your ingestion tool do the download to two places -- into your Working folder to start the pipeline, and a Virgin Backup folder somewhere else, ideally on a separate drive in case something goes wrong with your computer holding the Working folder structure.
Thinking about this is much easier now, realizing this is a backup, not an archive.

Thanks for jumping in with just the clarification I needed!

Dale
15  Software Discussions / Lightroom / Lightroom Catalog in External HDD Workflow on: September 18, 2010, 11:23:18 AM
I typically work on photos at the desktop (better monitor, faster computer), but I occasionally need to work on them, or use them in slideshows on my laptop. Therefore I'm thinking that the best approach is to keep them on an external portable HDD, being sure that the backup is amply robust.

I had intended to put the Lightroom catalog on that HD as well, thinking that either desktop or laptop could then use it. However after reading what Peter said about that in the book, I've reconsidered. It seems like separate catalogs residing on each machine may be a better solution, keeping them in sync as he described.

That raises two questions:

  • If the archive and working files are kept on the external HDD, I'm thinking that the best place to keep the LR catalog is in a folder like \Catalogs\Lightroom under the root directory on each machine. The backup would then have to be separately managed from the working files backup on the external HDD.
  • Have any of you used the system Peter describes successfully and do you have any additional advice in that regard?

Dale

Pages: [1] 2 3
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!