Posts tagged with DAM
It’s amazing how often some Lightroom users still assert that a disadvantage of the DNG file format is that any time the metadata changes in the DNG file, you have to backup the whole DNG file again (and again). This isn’t a disadvantage of DNG – it’s a failure to re-assess and think through your backup strategy.
So as it’s now pantomime season, a deep intake of breath please, and after me – OH NO YOU DON’T!
To explain, I don’t dismiss the need to back up your work. Backup is good, of course, but you have to think it through and ensure it is appropriate.
A false sense of security
Let’s say that you did decide to back up the DNG any time the metadata changes. One obvious downside is that repeatedly backing up the image is going to put a strain on your backup resources.
But the more fundamental problem is that these more…
Why do you rename your source images?
Why does the second copy upon import go into a folder called “Imported on November-11-13” and not into a folder named to match the folder on the hard disk that was set as the Destination for the import?
If you have a Nikon D800 – possibly any recent Nikon DSLR – avoid using OLD VERSIONS OF Nikon Transfer to copy files from your flash cards.
UPDATE: Nikon confirm problem and recommend proper practice
I honestly don’t understand why a Lightroom user would ever use Nikon Transfer, but some do so. And what they’ve discovered is that it makes the D800 raw files unreadable – and not just in Adobe software.
See this thread about D800 corruption and this too. What’s more, it’s not a new problem and relates to standalone versions of Nikon Transfer – ie before it became part of View NX.
Without digging into more detail than I think it’s worth, it’s hard to tell what’s happening. For all I know, maybe Exiftools or some other utility can resolve the problem by deleting any metadata added by Nikon Transfer. I don’t know if that’s possible though.
While I am surprised LR/ACR more…
Q Why are raw processors trying to be like the DAM/Library/Image managers?
Q I just upgraded to Lightroom 4 and something happened with my flags in collections: they are gone! Where the xxxx are they?
A Well, they are not completely gone. But they are very hidden indeed.
As background, in Lightroom versions 1-3 the Pick and Reject flags were local to the folder or collection of pictures. So in one collection of pictures you could mark an image as a Pick, while in another collection it could be marked as a Reject. While many found this useful, many found it unnecessary and confusing – and I think it’s important to acknowledge both sides here.
So in Lightroom 4 Adobe made these flags global, but they did so without letting you save flag data out to XMP or do anything which might have made the change more palatable. Potential compatibility with other apps remains just pie in the sky.
Because of the change to global flags, more…
While I’m a long-time fan of DNG and welcome its latest developments, you’ve got to be very cautious about saving pictures with the new lossy option. The workflow benefits aren’t enough to outweigh the very significant risks.
On Adobe’s Lightroom 4 Beta forum, one of the most contentious topics has been the omission of automated facial recognition or facial detection feature.
Flags are now global, not local. But stacks have gone local. How do these work together?
Barry Pearson writes about Seven years of writing about Digital Negative Format and other tales of the life and advantages of the DNG format:
When Adobe launched DNG on 27 September 2004, it was obvious to me that this was addressing a significant need. I knew from my career in helping to develop complicated multi-vendor computing systems that it is very important to structure a system into components linked by documented common interfaces.
I spent about 2 weeks examining the available documentation about DNG, including the specification, before concluding that it was a credible proposal. On 10 October 2004 I began to use DNG for all my raw images.
I had been reading and contributing to newsgroups for many years. Misleading and/or inaccurate statements about DNG began to be posted about 3 October 2004. (This has been a continuing trend all over the web).
I wasn’t that early an adopter, but almost. For me it was the release of Photoshop CS2 more…
David Marx’s Professional-Grade Backup Plans is worth reading.
My one point of minor difference is that people spend too much time thinking about their backups, making sure everything is backed up – but don’t spend time ensuring they know how to use their backup software’s restore features.
Too often people only try to figure out how to restore data when they’ve just experienced a catastrophe. Do a dry run.
There’s been no change to LR’s handling of custom XMP since version 1 – I’d characterise it as “preserving” custom XMP data.
So LR does read the data from imported files and stores it in a database field. It never displays the information and it isn’t editable even through the SDK. But at least Lightroom doesn’t do any damage. When you save metadata back to the original files (sidecars or directly into the file) it does not overwrite any custom XMP it encounters, and it does write the custom XMP to any exported files.
It is possible to use a plug-in that calls an external library (exiftools) to read and write custom XMP. I have one working for myself, but I judged the area’s complexity and potential for damage to be so great that I’ve chosen not to develop it for wider use. I’d make far too many enemies!
If you save metadata back to a DNG, doesn’t it mean that every time a change is made the whole large file needs to be backed up?
Not really. It obviously makes no sense to keep backing up big DNG files after every change, but that’s a straw man argument against the format. Instead you simply backup the DNGs upon their creation, and routinely backup your catalogue. If you were to hit a catastrophe, you can reconstruct the exact state of your work by restoring these virgin DNGs and your catalogue. Sidecars don’t contain all your Lightroom work.
How do I move my images to a new hard drive?
In most cases, it’s actually quite simple:
In your Lightroom catalogue, in the Folders panel’s header, click the + and choose Add Folder. You should see a dialog box headed “Choose or Create New Folder”.
Navigate to the new drive and click the New Folder button to add a new, empty folder. Select it and close the dialog box. The new folder and the new drive should now be shown in Lightroom’s Folders panel.
You can now simply drag folders from your existing hard drive and drop them onto the new drive.
Now, if I needed to move a large number of images – a complete migration from one drive to another – I might take extra steps. For instance, I would review my backup procedures and make sure that more…
While Extensis is good at exporting all metadata, importing data into Lightroom is liable to be the problem. Lightroom has no built-in tool to import text data, though there is a plug-in called LRTransporter, and I have ListView.
Even with these plug-ins, you require a fair amount of skill and patience, and will have to deal with text file formats (encoding) and glitches caused by non-English characters. Also the metadata itself may have no corresponding place in Lightroom. For example, if you have a multiple value custom field in Extensis, what does that become in Lightroom? Lightroom doesn’t provide custom fields, so you’d be reliant on a plug-in, but even plug-in custom fields can’t have multiple value. So you’d probably want to make your Extensis multiple values into Lightroom keywords.
If you have JPEGs and TIFs, making Portfolio embed the metadata in the files may be the easiest approach for most folk. more…
Here’s a quick tip for managing panorama frames.
My own long-term practice has been to assign the green label to originals which are intended to be the component frames of panoramas, HDR, or other multi-frame techniques.I also stack them.
I do this as soon as possible after importing the files from the card. The risk I’m trying to avoid is that I might review one of these frames on its own and decide it’s a dud – badly composed/exposed – and delete it.
Green warns me that the frame is actually destined for stitching or whatever. That colour then carries over to the combined image, so I can then do smart collections by label and file type.
Last year PhaseOne finally acquired – “liberated” may be a better word – Expression Media from Microsoft and gave it back its old name, MediaPro. I say “finally” because they had tried to add the original iView MediaPro cataloguing program to their CaptureOne raw conversion products back in 2006, and also because in those five years the post processing and cataloguing landscape has been transformed with the introduction of two major programs that combine those once-separate activities. To give an idea of how completely things have changed, I remember announcing Microsoft’s takeover to a trade show at Manchester United’s stadium, and since 2006 oil money has transformed City from a long-running joke into a pumped-up monster which might no longer need to call in Channel 4’s Time Team archaeologists to find any trophies (oh for the Arab spring to sweep away Abu Dhabi’s feudal rulers – that would be so more…
CaptureTime to Exif is my latest Lightroom 3 plug-in. Essentially it’s an in-Lightroom interface for Exiftool:
Initially it was for Lightroom users whose catalogue contains scanned images and who wanted to make the scans’ Date Time Original EXIF field correspond to when the pictures were originally taken rather than when they were scanned. But people said they wanted to add the camera model, or the aperture details from their tatty old notebooks….
So the plug-in also lets you write other EXIF and IPTC information. One idea was to add extra boxes for specific fields, but I could never please everyone – not without a lot of work. I’m also hesitant to make writing EXIF so easy that it’ll attract people who should be kept away from it for their own good, and I reckon those who know about such stuff would appreciate a “bare back” style. So I’ve chosen to add a more…
It was no secret that it was on the way, but my friend Peter Krogh’s The DAM Book has now been listed on Amazon US and Amazon UK. The original book was immediately unusual in its cover not being emblazoned with “Photoshop CS2” or focussing on the image processing side of the pixel mountain. Peter rightly saw that the management and safeguarding of digital photos was digital photography’s dangerously-neglected aspect, and this understanding of the real needs meant the book’s shelf life extended across software release cycles and remained applicable after entirely new programs were introduced. But even long-lasting underlying principles eventually need dusting off, and this new version of the book is a complete rewrite. Thanks Peter for asking me to tech edit a couple of chapters – I look forward to my signed copy!
And now for some of my own reflections… (or alternatively). When you look back more…
It’s not specifically a Lightroom thing, and I say the same about Aperture and Expression Media 2. And I admit that I am a bit out on a limb here in holding these opinions….. But I find hierarchical keywords to be an utter pain, and simply not worth the effort.
It doesn’t matter how much I try, how disciplined my working practices, how well I understand Lightroom. The trouble with hierarchical keywords is I always end up with child keywords somehow re-appearing at the top level. This can happen, for instance, when I re-import a picture that’s been processed in another app. Or I notice that a group of child keywords has managed to become duplicated in more than one part of the hierarchy. Usually this is because I’ve done something like change the hierarchy at some point and imported an older file, or more often that I changed the hierarchy more…