Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: hassiman on October 09, 2015, 01:07:56 pm
-
I loaded the latest LR CC 2015 update only to find that one of the most important features of the program seems to have had the rug pulled out from beneath it, and me as a user.
What the hell were they thinking... or were they?
I hope to God they re-think this.... maybe have a "Training Wheels" import module option for users... but the current update just seems to have come out of nowhere. Not something I can use... but I have many 1,000 of images in my current LR catalog so I'm kind of cooked.
-
It is true that this is a very bad sign of things to come for several reasons. First off, it is a bad design, failing to satisfy current users and failing to meet its objective of making it easier for new users. Second it removes key functionality, ruining existing user workflows. Third, the immediate Adobe reaction is that going back is not an option, showing an arrogant and intransigent attitude. Fourth, the poor, dumbed down design does not bode well for the future of lightroom.
However, your contention that lightroom is no longer a functional DAM may be a bit hyperbolic. You can still import, but you now have to do more work inside the library module. If the current LR import does not work for you, you can use a third party product like Photo Mechanic. The DAM isn't broken (yet) but your workflow probably was.
-
Lightroom is fine as a DAM if you use it with Photo Mechanic to ingest, select, keyword, etc, before adding to Lightroom. It's an extra step, but PM is a fast pro tool.
-
How does Photo Mechanic work with Lightroom? And I hate the new import...
You copy the selects to a destination folder and then use the lightroom import to add the images to the catalog. Metadata is included automatically. PM has some nifty tools to automatically create folders, rename files and bulk add metadata.
-
You copy the selects to a destination folder and then use the lightroom import to add the images to the catalog. Metadata is included automatically. PM has some nifty tools to automatically create folders, rename files and bulk add metadata.
That's exactly the workflow I use, but with Chris Breeze's Downloader Pro and Breezebrowser, which are also fast and configurable.
Photo Mechanic does much the same, but I have been using Breezebrowser since long before Lightroom came on the scene, and I have seen no need to change my workflow.
I don't like having my images stored only in a system which requires me to use one particular piece of software (LR) to do anything with them. My camera-plus-date folder system lets me use any program I want to see the raw images, without having to go into LR.
I still do it this way, even though 98% of my processing takes place in LR (but not either of the two new "downgrades.")
-
Lightroom is fine as a DAM if you use it with Photo Mechanic to ingest, select, keyword, etc, before adding to Lightroom. It's an extra step, but PM is a fast pro tool.
It's still a DAM if you choose to do your imports all from within LR. The culling of your images will have to be done within the library module after import. That does not in any way limit LR's ability to manage your photos once imported. I've never used those advanced import features and I still get the photo management out of LR.
-
I don't like having my images stored only in a system which requires me to use one particular piece of software (LR) to do anything with them. My camera-plus-date folder system lets me use any program I want to see the raw images, without having to go into LR.
This is also how I do it. Relying on specialized tools -- in this case, a dedicated importer -- can mean a more efficient, reliable workflow with respect to file organization, file naming, and backup. This is especially true when dealing with more than one camera or multiple memory cards.
-
Sorry guys - got to ask. In the context of this discussion, what is a DAM?
-
Sorry guys - got to ask. In the context of this discussion, what is a DAM?
Digital Assets Management - any application or system designed to manage large volume of digital files or "assets"
-
The single thing IMHO that has hampered new users coming to grips with this product is the name. "Photoshop" needs to be removed, Lightroom is not even remotely like Photoshop, particularly in the way it functions.
-
The single thing IMHO that has hampered new users coming to grips with this product is the name. "Photoshop" needs to be removed, Lightroom is not even remotely like Photoshop, particularly in the way it functions.
And why is that?
Both in Lr and PS the actual image files (RAW/JPEG/PSD/TIFF) exist on a flat file structure on the HD. These files are directly accessible by the OS, or any other application familiar with them.
One can load/import/move files from a camera/flash card into a HD with many methods, like simple OS copy or other copy/organizer programs. Both PS or Lr can access these files.
Lr's Import control/function is primarily its way to register the image filename/location/metadata in Lr's database. The image data itself does NOT reside in a database.
The only thing Lr does not do (like PS does) is to open a file directly before registering it (via Import) into its database. But it could do that with minor added code, as all the processing functionality is there.
Lr is essentially Camera Raw from an image processing perspective.
-
...The only thing Lr does not do (like PS does) is to open a file directly before registering it (via Import) into its database. But it could do that with minor added code, as all the processing functionality is there....
That would completely break its design philosophy as a parametric editor.
The image needs to be imported (so the database is aware of the image) and this allows all the edit instructions to then also be stored in the database.
Database = catalog.
Tony Jay
-
That would completely break its design philosophy as a parametric editor.
The image needs to be imported (so the database is aware of the image) and this allows all the edit instructions to then also be stored in the database.
Database = catalog.
Tony Jay
Not really. All the parametric data can be stored in a xmp sidecar. Not saying this should happen in LR, but your assertion that the DB is required to be a parametric editor is incorrect.
-
Not really. All the parametric data can be stored in a xmp sidecar. Not saying this should happen in LR, but your assertion that the DB is required to be a parametric editor is incorrect.
Fine, but that requires obligatory creation of XMP sidecars.
Something that the current situation in Lightroom allows as a decision of discretion.
Also not all of the metadata stored in the catalog is replicated in XMP sidecar files (although all the Develop module edits are).
And finally, if someone wants that kind of workflow, just use ACR - thats how it always worked!!
Tony Jay
-
Not really. All the parametric data can be stored in a xmp sidecar. Not saying this should happen in LR, but your assertion that the DB is required to be a parametric editor is incorrect.
Precisely.
-
Fine, but that requires obligatory creation of XMP sidecars.
Something that the current situation in Lightroom allows as a decision of discretion.
Yep ... and the past, automatically writing XMP to files, was ticked on by default. Even if you prefer the database approach, having the sidecar file is an additional level of backup of your work.
Also not all of the metadata stored in the catalog is replicated in XMP sidecar files (although all the Develop module edits are).
True, but you can survive without history states much more easily than if you would lose Develop settings in a catastrophic failure of the catalog file and/or your backup of same.
And finally, if someone wants that kind of workflow, just use ACR - thats how it always worked!!
Isn't that a bit crass? This does not have to be a all or nothing, zero sum outcome. Users can have both a database catalog AND XMP sidecars. One need not be exclusive over the other.
-
Yep ... and the past, automatically writing XMP to files, was ticked on by default. Even if you prefer the database approach, having the sidecar file is an additional level of backup of your work.
True, but you can survive without history states much more easily than if you would lose Develop settings in a catastrophic failure of the catalog file and/or your backup of same.
Isn't that a bit crass? This does not have to be a all or nothing, zero sum outcome. Users can have both a database catalog AND XMP sidecars. One need not be exclusive over the other.
As far as I m aware "automatically writing to XMP" was never a default option. Lightroom's default option is writing and reading from the Catalog file. This is the main reason I use Lightroom "no XMP and no DNG" period.
-
As far as I m aware "automatically writing to XMP" was never a default option. Lightroom's default option is writing and reading from the Catalog file. This is the main reason I use Lightroom "no XMP and no DNG" period.
Lr always writes to the Catalog whether you have "automatically write to XMP" on or off .... it's not an either or situation for the catalog.
Back about version 2 (may have been in a public beta version) IIRC ... though, it was short-lived and updated quickly to be off by default because many users were experiencing performance hits. Adobe was offering a bit of a failsafe option for end users.
That's the beauty of Lr (at least prior to v6.2) it is full of options to please a broad user base. Most everyone can tailor their workflow to their own needs and tastes. Using XMP sidecars or DNG is neither right or wrong, merely a personal subjective preference.
-
Butch I think you misunderstand a couple of things.
As Dennis points out saving to XMP sidecar files has never been a default in Lightroom.
It has, however, always been an option.
None of these facts, from my perspective, has ever been an issue.
The point of my post regarding using ACR is simple. Adias does not want to import images into Lightroom rather he just wants to use the application and save changes to XMP sidecar files. My point is this: ACR offers that workflow and always has. If that is what you want to do, use ACR. Don't force Lightroom to work in a way it was never designed to do.
Tony Jay
-
Quote "Lr always writes to the Catalog whether you have "automatically write to XMP" on or off .... it's not an either or situation for the catalog."
Yes ButchM I am well aware of this. Writing to xmp has its uses and I use it when I need to share files and info with someone. For my personal workflow I know where my info is, in the Catalog file which I keep secure and backed up.
-
Yes, why putz with xmp files if you aren't doing dng format?
-
Yes, why putz with xmp files if you aren't doing dng format?
Which is why it is optional.
-
Yes ButchM I am well aware of this. Writing to xmp has its uses and I use it when I need to share files and info with someone. For my personal workflow I know where my info is, in the Catalog file which I keep secure and backed up.
OK ... I think you need to go back to the beginning of your effort to set me straight. There was indeed a point back in the early formation of Lightroom where the Write XMP metadata to files was indeed on by default, I then corrected my assertion to point out that it likely may have been in one of the early public beta builds ... I recall because there was a huge kerfuffle on the Adobe Labs discussion forum as the function was causing issues with many users seeing a larger than normal performance hit due to the extra effort of writing XMP on the fly. Just like the performance hits folks were experiencing with the current v6.2 Import dialog splash screen.
I NEVER once recommended or was trying to sell you on the idea of incorporating XMP sidecar files into your workflow. I was simply pointing out that the option to use or not to use the feature is not a zero sum choice.
-
I NEVER once recommended or was trying to sell you on the idea of incorporating XMP sidecar files into your workflow. I was simply pointing out that the option to use or not to use the feature is not a zero sum choice.
And that is a fair point.
Tony Jay