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: Doug Pardee
The DAM Forum
Welcome, Guest. Please login or register.
December 03, 2020, 04:16:56 PM

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
1  General / General Discussion / Re: Renaming long-sequence numerical files? on: June 05, 2009, 08:37:13 PM
If you're using a PC, you can do the file renaming using idImager. But it's not something that you'll easily find in the manual. You'd be best off asking on the idImager forums for some help with rearranging the file names. There are some folks on there who are real experts on this stuff.

I suspect that you'd be able to translate the filename date into the various other dates, too, but again that would be something to ask on their forums.

-- Doug
2  General / General Discussion / Re: New User--searched forum, still have questions on: May 28, 2009, 06:48:05 AM
Yep, that's it (as I see it, anyway).

I'd add that naming folders chronologically isn't a necessary component. You might very well have some non-chronological names for your "in-process" folders. Eventually your image files will finish your workflow and be moved into their (reasonably) final resting place folders. The names of those folders are not significant—your DAM software should always know where to find the file—but it is very common to use names that include the date and possibly an identifier for the particular shoot.

I'd also add that when you say "add keywords", that would be a shorthand for "add keywords, tags, catalog labels, etc.". The specific tools available depend on which DAM software you're using.

-- Doug
3  General / General Discussion / Re: New User--searched forum, still have questions on: May 27, 2009, 10:36:52 PM
My opinion:

The hardest part about going to a "real" DAM system is the part about forsaking folder names and file names.

You have to go cold turkey, and it ain't easy.

Make a full and clean break. Folder names and file names will never again be used for finding image content. That's what your DAM cataloguing system (ExpressionMedia in your case) is for.

Folders still have their uses for workflow organization. But not for finding photos.

File names are still used for finding photos by (duh!) file name, but not by image content. File names for your "originals" should, ideally, be cast in stone at a very early point in your workflow so that henceforth you'll always be able to locate the image by that name. If the files never leave your possession it's not such a big deal, but if someday somebody asks you for a different crop of J47-KR26.JPG, you don't want to have to try to figure out what the heck that file got renamed to a few years back. If you happen to have a bunch of "original" files all named IMG_0003.JPG distinguished only by which folder they're in, then it might be reasonable to rename them to make their file names unique. But don't rename your files just to make the naming system somehow "consistent". As long as the file names are reasonably unique, I say leave 'em alone.

File names for your derived images should reflect the file names of the originals, just so you can easily tell which file goes with which.

So sez I, anyway.

-- Doug
4  General / General Discussion / Re: Questions from "The DAM Book" 2nd Edition on: May 09, 2009, 03:52:37 PM
4) Any software yet using the 2008 IPTC extensions (what about IIP?)?  Can I see these with Bridge, including my PLUS ID's?

idImager supports the 2008 extensions including PLUS (since idImager version 4.2).

Be aware, though, that IPTC says that they plan to release an updated specification next month that will change a couple of the field names in the Extensions section. They had misspelled "ProviceState" which affects the two extended location fields (LocationShown and LocationCreated), and they will be correcting the spelling to "ProvinceState". Also, they have decided that the field name "DigitalSourcefileType" was misleading and are planning to rename it "DigitalSourceType". Use those fields with caution.

No planned changes in PLUS that I know of.

-- Doug
5  Software Discussions / Bridge/ Camera Raw / Re: Renaming RAW files on: January 31, 2007, 09:51:31 AM
I believe that the .rws is the RawShooter sidecar file.
6  DAM Stuff / DNG / Re: Are things this simple or is it me ? on: November 07, 2006, 12:21:46 PM
but could Nikon encrypt the NEF !!!!!!!!!!  ie force the use of capture even though it would be bad marketing & publicity ?

After the white balance encryption hulabaloo, Nikon agreed to cooperate with Adobe. So presumably if Nikon encrypted its NEF files, they would still tell Adobe how to unencrypt them. Of course, there's no guarantee that this cooperation will continue forever.

Bear in mind that Adobe is also the one who makes the NEF-to-DNG converter, so if Nikon should ever actually decide to thumb its nose at Adobe, you wouldn't be able to produce DNGs from the new NEF files. Unless someone else produced a NEF-to-DNG converter that could handle it.

Quote
So is a DNG a generic Adobe RAW file with added features like XMP ?  If so then can you still use RSP, lightroom or bible to convert from the DNG RAW to say TIF ?

Not all software supports DNG the same. As Peter Krogh already noted, Bibble only supports DNG for cameras that produce DNG natively. RSP only supports DNG for cameras that it supports in Raw form. Which means that RSP can't handle a DNG made from a D80 NEF file.

Quote
I feel I am missing something here or is it really just this simple ?  Same data just in a different format

A small but important detail is that unlike NEF files, DNG files also contain the camera's color profile. This allows programs to render the Raw data in a DNG even if they never heard of the camera. SilkyPix can do this, but RSP wasn't programmed to use that data (which is why RawShooter can't handle D80 DNGs).

That color profile has to come from somewhere. For now, for cameras that don't natively generate DNG, it comes from Adobe's measurements of some test cameras. It's possible that Canon and Nikon are reluctant to release their official color profiles to the public.
7  Software Discussions / iView MediaPro / Re: iView Exit Strategy (Hypothetical...no issues) on: September 27, 2006, 10:11:33 PM
what is the current thinking or general consensus on synching iView metadata directly to NEF?  (If it matters, I mostly use a D2H and have some legacy D100/D70 NEFs.)  Is it generally a "safe" exercise?

I can't say for sure about iView, but if you let idImager write metadata to NEF files rather than sidecars, Nikon Capture won't have anything to do with the modified NEFs. The files are okay and can be opened in Adobe Camera Raw, and I imagine that they can be converted to DNG, but Nikon Capture turns up its nose at them.

I suspect that it'd be the same with iView.
8  Software Discussions / Choosing Software/Other DAM Applications / Re: Are cheaper alternatives to Photoshop CS2/Bridge/ACR any good for DAM? on: September 21, 2006, 10:28:09 AM
Just a short note to add that idImager Lite is free of charge, and you can't get much better bang for the buck than that. Unfortunately, idImager is not an option for Mac users; it's a Windows-only program.
9  DAM Stuff / Migration Issues / Re: JPEG Originals and folder dates on: September 21, 2006, 10:06:05 AM
As a (now) JPEG shooter and idImager user, here are my thoughts:

[I've combined questions from multiple postings here.]

Before I began the DAM process, I used to confirm my JPEG as original by comparing the file date against the created date. When I began adding "unrated" labels using IDimager Lite, I noticed that the file date changed. Is this file with different date still considered as an original? I could not find this info in the DAM book. Is this how it's supposed to be or is there a way to add metadata and still keep the original created date?

This is a big leap. Or more correctly, a decision whether to leap or not.

There are two different ways of thinking of an original. One is the "bit-for-bit exactly as it came from the camera" file, and the other is "a reference file containing the original image data". Peter Krogh's workflow is clearly based on the latter—he even discards his original Raw files.

Making the leap mainly requires faith in your tools not to destroy the original image data while changing the file containing that data. To get there, you pretty much need to have a workflow which involves making temporary backups of the camera files, backups which you will discard only after you've finished adding metadata to your originals and verified that the image data is still intact. Note that this implies that for originals all embedded metadata will be added in a very short timespan and the original will remain untouched thereafter. In my case I just leave the camera files on the CF card until I'm satisfied that the original file is good.

Separately filing original and derivative files is also a big help once you start modifying the original files. Then you don't have to worry about the file dates and whether you can tell if it's an original or not.

If you're not ready to make the leap, you'll need to store your "embedded" metadata separately. I'm pretty sure that idImager will store the XMP/IPTC metadata in a .XMP sidecar file if the image file is marked read-only. If you use idImager downloader, there's an option to make all ingested files read-only; that would be the easy way around it.

Another approach is to redate your originals. idImager has a "redate" feature (I think it's under Collections>Operations) which can be used to do a number of different things to both metadata dates and file dates on any collection of image files. The Downloader also has an option to reset the file dates to the EXIF dates during ingestion.

If you aren't using Downloader for ingestion, you're missing much of the power of idImager for DAM. Downloader handles all of the "bulk" operations in a single ingestion step. I'd used idImager for a couple of months before I looked at Downloader, and then realized I'd been wasting huge amounts of my time doing stuff by hand that could have been done automatically.

Quote
Wouldn't that mean my archived DVD contents (e.g. RAW_001_2005) will keep changing, possibly ending up with multiple versions of RAW_001_2005 DVDs?

As noted above, you should add all of the embedded metadata to your originals over a very short time span, and then they'll be left alone. So this shouldn't be a problem.

Quote
My old-style folder names contained dates. Would keeping the date info in the folder name cause problems?

As far as I know, you can arrange them however you want.

Quote
I guess I still want a way to quickly locate the photos using a file browser. Or, am I missing the whole point of DAM software?

Yes, you really need to "let go" of the folder/filename approach to locating photos. idImager will find them for you.

You can still use folders for a simple one-dimensional classification, but you should think of that as a little bonus, not as a key part of your filing system.
10  Software Discussions / RAW File Converters / Re: Converting the new Canon XTi RAW files?? on: September 19, 2006, 08:22:03 AM
Ouch. Adobe just released ACR 3.5 without the XTi/400D support.

Quote from: Thomas Knoll
No, this update does not support the Nikon D80 nor the Canon 400D [Rebel XTi] yet. We receieved these cameras too late in our development cycle to make the cut for this release. We understand there are a lot of users now getting these cameras who want support as soon as possible.

There are also a bunch of other cameras models likely to be announced at Photokina which will want to support as soon as possible.

Because of this demand, we are planning to make the time gap between the ACR 3.5 and 3.6 releases shorter than usual, so you will not have to wait all that long for support.

Also, we are nearing completion of the Beta 4 release of Lightroom. This will be released fairly soon (before the release of ACR 3.6).… Beta 4 of Lightroom will have preliminary support for both the Nikon D80 and the Canon 400D.
Quote

(Ref: http://www.adobeforums.com/cgi-bin/webx?13@@.3bb6a869.3bc1b01e/0)
11  Software Discussions / RAW File Converters / Re: Converting the new Canon XTi RAW files?? on: September 18, 2006, 10:26:27 PM
I hope Adobe doesn't bypass ACR 3.5 and simply require that we use Lightroom

I doubt that they would. There's apparently no technological reason that they would; an Adobe employee said, "Lightroom uses Adobe Camera Raw as the guts of its conversion engine". And I can't think of a marketing reason that they would.

But then, I haven't talked with Adobe for "a l-o-n-g time" and you have. Wink

I suspect that the next ACR will have support for a whole bunch of new cameras debuted for Photokina—D80, K10D, E-400 if they can get one, and maybe the M8, as well as the XTi/400D—so that's probably the delay. Photokina doesn't even start for another week, and another camera announcement or two are still possible.
12  DAM Stuff / Hardware Discussions / Re: CD or DVD, and please excuse my ignorance on: September 18, 2006, 10:12:05 PM
Basically you can treat DVD as being a high-capacity CD. However, with CD you only had two format choices—CD-R and CD-RW—and with DVD you have seven format choices, all with somewhat different capabilities, and that's not counting the new Blu-ray and HD-DVD stuff that's just coming over the horizon.

Krogh recommends (on p. 112) DVD-R or DVD+R, and I'd add to that the restriction to stick with ordinary single-layer media. Personally I like DVD+R because of the slightly better error recovery, but you'll also find people who think that DVD-R is superior. Either way, choose a good dye formulation and backing material. Some companies sell "archival" DVD blanks.

You might want to compare the cost of a DVD burner plus a stack of blank archival DVDs against the cost of an external hard drive. And consider how long it takes to burn a DVD versus how long it takes to copy files to an external hard drive. You might find the external hard drive to be the more practical and certainly more pleasant-to-use option.
13  Software Discussions / RAW File Converters / Re: Converting the new Canon XTi RAW files?? on: September 16, 2006, 06:48:53 PM
Appears that DPP doesn't even display camera EXIF meta

Control-I turns the EXIF display on (I presume that it's Command-I on a Mac). In the menu you'll find it under File>Info.

By the way, Canon's tutorials on DPP 2.1 can be found at http://photoworkshop.com/canon/dpp2/ - these are QuickTime videos  so you'll need to have Quicktime installed, and you'll also need audio capabilities.

Quote
Any chance there are other RAW reading options for such a new camera?
The other Raw options at the moment (to my knowledge) are: Canon's Raw Image Task within ZoomBrowser EX (Windows) or ImageBrowser (Mac), Ichikawa's SilkyPix, and just today Capture One 3.7.5 was released with XTi/400D support. However, initial user reports are that XTi/400D colors are seriously off in Capture One 3.7.5. I haven't tried it myself, just reporting what I've heard.

Or if you're up to it, dcraw has been updated.
14  General / General Discussion / Re: how to fill the buckets on: September 05, 2006, 01:02:23 PM
Unless I totally misunderstand (always a possibility):

The point of the buckets is that they are collections of files suitable for backup. Once a bucket is filled, it is backed up to the permanent archives and then "frozen". If the bucket data on disk is lost it can simply be restored from that archival backup. Restoring from the archive will not lose any work because nothing in the bucket is allowed to change—no editing of files, no renaming of files, no adding of files—after the archival backup is made.

There is no particular relationship between RAW buckets and DRV buckets. A particular Raw file might even have derivative files in more than one bucket, if those derivative files were created at different times. Obviously (at least I think that it's obvious), you rely on your cataloguing program to make this organization usable.
15  DAM Stuff / DNG / Re: Imbed RAW in DNG? Delete original RAW? on: August 30, 2006, 09:30:27 AM
I'm reticent to reply because it's really easy for this topic to become one of the many pointless arguments in the world: Mac vs. Windows, Raw vs. JPEG, Canon vs. Nikon, etc.

Please keep in mind that this is not about logic, it's about feelings. I'm not saying that I'm right and someone else is wrong. I'm just saying how I feel about the topic and why I feel that way.

I read the statement as lamenting the demise of the free RSE program, which was available to those who can't afford Adobe products.

Not really. It was lamenting the sudden removal from the market of the only two significant competitors to Adobe in the DNG Raw conversion market. With RSE and RSP on the market, DNG was something that people could use without committing to Adobe. The loss of those two products returned DNG to its earlier status as "camera manufacturer independent" but "software supplier dependent", which is just the flip side of using native Raw files.

As Michael noted, we're not talking logic here... we're talking feelings and personal impressions. And when the announcement came out that Adobe had bought RawShooter and had immediately terminated both products, the feeling I got was "Adobe is consolidating its monopoly". I feel about Adobe and PhotoShop the way that I imagine that many Mac users feel about Microsoft and Windows: a huge majority of other people might like the software but I don't, and I don't much appreciate the supplier's attempts to force me into their camp by using their vast war-chest to take away my alternatives.

I want to have a choice, and I don't mean a choice between Adobe products. Besides, in terminating RawShooter, Adobe said that their customers would only get confused if given any choices.

Quote
As to the "common man", well, anyone shooting RAW files has spent a minimum of a couple thousand dollars - at least - to provide this additional functionality that RAW file photography provides.

Have you checked the prices on cameras lately? A DSLR kit from companies like Pentax and Olympus can be had for less than the price of PhotoShop CS2. Canon is selling the Rebel XT kit for $799 (US) list, with street prices around $700. The Nikon D50 kit can be had for about the same price.

These are arguably not professional-grade cameras. But many cash-strapped enthusiasts are buying them and, yes, shooting Raw with them.

Quote
Once you have bought one of these programs once, upgrades should be within reach of anyone who has the cash to shell out for rapidly depreciating DSLRs, Computers, Hard drives, cards, monitors, printers and training.

This might be the part that galls me the most (remember, we're talking feelings here). The notion that someone saves for a year to buy a nice new camera, and because of that he/she is forced to buy a software upgrade because the software supplier intentionally makes the new camera support incompatible with prior product releases—and to add further insult, that software upgrade sometimes means that he/she needs to buy a new computer—it all reeks of crass opportunism.

I got my digital SLR because I wanted to take photos, not to become someone's guaranteed lifetime revenue stream. My 5-year-old computer works just fine processing my Raw files using software that I get free updates for. Obviously, I don't use Adobe software.

And as long as I don't use DNG, I can continue to happily not use Adobe software.

Quote
And what is the alternative?

Two alternatives were RawShooter Essentials and RawShooter Premium. Adobe fixed that.
Pages: [1] 2
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!