Ad
Ad
Ad
Pages: [1]   Bottom of Page
Print
Author Topic: Why does LR hate derivatives?  (Read 2949 times)
smahn
Full Member
***
Offline Offline

Posts: 127


« on: December 01, 2010, 01:37:05 PM »
ReplyReply

I get that LR is primarily geared toward RAW file management, where image characteristics like Bit Depth, File Size, Color Profile, Width, Height, etc, are largely academic. But if it's going to include support for derivatives and legacy files it really needs to do a better job in allowing us to manage them.

Why do I need to go to Bridge to sort, filter, smart collect, and thumbnail display such basic image characteristics? And then if I need to move them I'm doing so from Bridge and outside of my Lightroom catalog (a no no). And if a person doesn't have Bridge they need to go to a different vendor altogether?

Adobe obviously has the know-how to allow this (as witnessed in Bridge) so why on earth would it be precluded in LR, which is ostensibly supposed to be my photo management catalog? Is it time for a Lightroom Pro edition?
Logged
NikoJorj
Sr. Member
****
Offline Offline

Posts: 1063


WWW
« Reply #1 on: December 01, 2010, 01:53:00 PM »
ReplyReply

Errrr... sorry, but...  Embarrassed
Could you explain what is your problem?  Huh
Logged

Nicolas from Grenoble
A small gallery
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #2 on: December 01, 2010, 02:09:14 PM »
ReplyReply

Could you explain what is your problem?  Huh


Thank you for requiring me to be more clear, something I'm not always good at.

My problem is that Lightroom wont allow me to utilize the file attributes of Bit Depth, File Size, Color Profile, Height or Width to: sort, filter, or smart collect images. Doing so would allow me to do a better job of managing TIF/PDS/JPEG images.

Presently I need to go to Bridge to do it, and I don't quite get why Adobe wouldn't include the same functionality in Lightroom, which is presumably designed to be my photo (not just RAW) catalog and organizational tool.
Logged
NikoJorj
Sr. Member
****
Offline Offline

Posts: 1063


WWW
« Reply #3 on: December 01, 2010, 02:30:39 PM »
ReplyReply

My problem is that Lightroom wont allow me to utilize the file attributes of Bit Depth, File Size, Color Profile, Height or Width to: sort, filter, or smart collect images. Doing so would allow me to do a better job of managing TIF/PDS/JPEG images.
OK, now I understand better (please take no offense, I'm blonde) and generally, that seems a very sensible feature request to add more metadata fields to the sort/filter queries.
Logged

Nicolas from Grenoble
A small gallery
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #4 on: December 01, 2010, 02:45:29 PM »
ReplyReply

For instance, lets take a hypothetical.

Imagine a person has a fussy client who will ultimately want a retouched image provided in different formats, sizes, depths and color profiles. Imagine too that in the process of getting to the final master image, the client needs to be presented variations to choose from; perhaps a conservative rendering, normal and edgy. And perhaps it takes a couple more rounds of iterations/variations to nail it. Once nailed we go to the differing sizes, outputs, color spaces etc.

All told, one could end up with 20+ derivations differing, in size, bit depth, color profile, etc. And what if said client requires this of 10 different images 10 times per year?

If one is not meticulous in their naming, metadata-ing and organizing along the way there can be quite a mess to clean up later. Lets assume at times that degree of meticulousness has not been present. Assuming all the images are cataloged in LR, should LR be an aid making sense of the mess or not?

Again, all hypothetical, but sometimes reality is even stranger than fiction.  Shocked
Logged
madmanchan
Sr. Member
****
Offline Offline

Posts: 2101


« Reply #5 on: December 01, 2010, 04:08:11 PM »
ReplyReply

All of this can be handled with virtual copies/snapshots, export presets, and smart collections (i.e., existing tools). The virtual copies let you do variations. The snapshots/history let you do iterations (same style, but additional work based on client feedback). The export presets take care of the file formats, naming conventions, color spaces, image sizes, export locations, etc., so you don't have to worry about getting it wrong. You have the option of adding the exported image back to the catalog immediately, if you want to keep track of it. The smart collections make it possible for you to find images automatically, without your having to maintain them, as long as you have the criteria clearly defined.

If you have a couple of concrete workflow examples to describe, perhaps we can drill down and figure out exactly how to set up the various tools in LR to carry them out.
Logged

john beardsworth
Sr. Member
****
Offline Offline

Posts: 2670



WWW
« Reply #6 on: December 01, 2010, 04:16:41 PM »
ReplyReply

You (smahn) are rather conflating two issues here. I've always argued that LR should allow all data in the database to be searched, and without the use of plug-ins, so I agree about your color space, bit depth etc.

However, you overstate your case here:
If one is not meticulous in their naming, metadata-ing and organizing along the way there can be quite a mess to clean up later. Lets assume at times that degree of meticulousness has not been present. Assuming all the images are cataloged in LR, should LR be an aid making sense of the mess or not?
Simply by being a catalogue, with built-in cross folder views, LR's already overcoming Bridge's folder-centric view and users' wonderful ways of sticking stuff all over their hard drive. Finding those x images is much easier - simply sort by capture time. If you've some elements of a filename structure, LR can search for all images with "123456" somewhere in the filename significantly faster than Bridge searching through how many tens of thousands of pictures in how many folders / drives (some of which are offline). Keep repeating those searches, as you do when you're bringing order out of chaos, and the advantages stack up even more. Sure, you can pick up deficiencies (eg inability to move more than one folder at a time) but the ability to manage and process large quantities of work in one app is a pretty compelling case.

John
Logged

smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #7 on: December 01, 2010, 04:49:59 PM »
ReplyReply

All of this can be handled with virtual copies/snapshots, export presets, and smart collections (i.e., existing tools). The virtual copies let you do variations. The snapshots/history let you do iterations (same style, but additional work based on client feedback). The export presets take care of the file formats, naming conventions, color spaces, image sizes, export locations, etc., so you don't have to worry about getting it wrong. You have the option of adding the exported image back to the catalog immediately, if you want to keep track of it. The smart collections make it possible for you to find images automatically, without your having to maintain them, as long as you have the criteria clearly defined.

Eric, there's a couple of essential problems in this.

1) LR can not do the variety of iterations that PS can. How about a variation with the cow in the shot and one without? Give me a pen tool, layers with adjustable masks and blend modes, a viable clone/healing solution, cut and paste, etc, and we can begin to compare, but not until.

2) There's no failsafe. You have to have an absolutely impeccable workflow, with no slipups, and no legacy files or it falls apart. What you are essentially saying is that if you are incredibly organized, not prone to errors and are a LR master, then, and only then, LR can help maintain what you already know to do.

The problem is, if you're not "there yet," or drop the ball from time to time, LR can't well be used to clean things up and "get there."

So rather than allowing the program to read basic characteristics of a PSD/TIF/JPEG, and sort, filter and smart collect along those lines (like Bridge can,) users are out in the cold and need to come into LR as advanced users with their PSD/TIF/JPEGs already sorted, maintained, encoded and organized.

Quote
If you have a couple of concrete workflow examples to describe, perhaps we can drill down and figure out exactly how to set up the various tools in LR to carry them out.

I would like to address this but I think it's best as a separate thread.
Logged
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #8 on: December 01, 2010, 05:07:49 PM »
ReplyReply

You (smahn) are rather conflating two issues here. I've always argued that LR should allow all data in the database to be searched, and without the use of plug-ins, so I agree about your color space, bit depth etc.

However, you overstate your case here:Simply by being a catalogue, with built-in cross folder views, LR's already overcoming Bridge's folder-centric view and users' wonderful ways of sticking stuff all over their hard drive. Finding those x images is much easier - simply sort by capture time. If you've some elements of a filename structure, LR can search for all images with "123456" somewhere in the filename significantly faster than Bridge searching through how many tens of thousands of pictures in how many folders / drives (some of which are offline). Keep repeating those searches, as you do when you're bringing order out of chaos, and the advantages stack up even more. Sure, you can pick up deficiencies (eg inability to move more than one folder at a time) but the ability to manage and process large quantities of work in one app is a pretty compelling case.

John

John, I think you are getting territorial, as if this is a "Who's better: Bridge or Lightroom?" showdown.

Forget Bridge, I only mention it to explain that Adobe already possesses the know-how, so the implementation shouldn't be so difficult or easily dismissed.

With that out of the way, yes or no: Should a user in LR be able to make a Smart Collection targeting 16-bit files, and then be able to sort/filter that collection by, say, Size or Color Profile? Should a user be able to make an Adobe RGB Smart Collection, and then sort/filter by Bit Depth? If a LR user searches on image DSC_0001, and comes up with 20 matches of various file types, should they then be able to sort/filter those 20 finds by Color Profile, Bit Depth, Size, etc, or not?

And if not, how about the option of displaying that info on thumbnails?

Why not provide the tools to let users make sense of their PSD/TIF/JPEG after the fact?
« Last Edit: December 01, 2010, 05:11:28 PM by smahn » Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 8636



WWW
« Reply #9 on: December 01, 2010, 05:08:46 PM »
ReplyReply

My problem is that Lightroom wont allow me to utilize the file attributes of Bit Depth, File Size, Color Profile, Height or Width to: sort, filter, or smart collect images. Doing so would allow me to do a better job of managing TIF/PDS/JPEG images.

I totally agree in terms of this part of your request. There seems no reason why I can’t for example, find all rendered documents in Adobe RGB (1998), its existing metadata. Or all 16-bit files. For those who use LR to catalog rendered images, the existing search functionality or Smart Collection functionality needs more work.

In terms of iterations, I don’t know if this is totally valid since you do have Virtual Copies you can use. If you have a version with the cow and one without that you produced in Photoshop, LR can easily store those changes as you move from LR to PS and back.

Quote
Give me a pen tool, layers with adjustable masks and blend modes, a viable clone/healing solution, cut and paste, etc, and we can begin to compare, but not until.

You are going to have to do that work in a pixel editor. I don’t expect nor would I want the same functionality in LR that exists in PS even if that were possible (again, LR is a metadata editor). But assuming you use PS for the tasks above, you should be able to catalog this easily if you start from the original (or iteration) in LR, use the Edit in Photoshop command and then save back into LR that rendered iteration if I understand your request.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #10 on: December 01, 2010, 05:16:39 PM »
ReplyReply

Andrew, thanks for (partially) getting where I'm coming from.

Can we just simplify this to the point where my future work in LR can be bettered, but my past (and possible future) mistakes need to be cleaned up, and that LR should provide the tools to do so?

I'm having a hard time believing I'm the first user who has a mess of PSD/TIF/JPEGs to make sense of.
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 8636



WWW
« Reply #11 on: December 01, 2010, 05:23:49 PM »
ReplyReply

Again, I can’t see why any existing metadata (and I’m pretty sure nearly everything on your list fits this category) should not be accessible for a Smart Collection and for the Library Filters. Hopefully we’ll see this in version 4. Doesn’t seem to be big engineering.
Quote
I'm having a hard time believing I'm the first user who has a mess of PSD/TIF/JPEGs to make sense of.

Well part of this can probably be done today. The Library filters will provide searching for JPEG, TIFF and PSD. I have a group of smart collections that search for JPEGs, CRWs, DNGs, PSDs etc. But JPEGs in sRGB, or TIFFs in 16-bit, nope. Or TIFFs over 10mb (or with a long axis over 1000 pixels). That would be useful.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #12 on: December 01, 2010, 05:24:10 PM »
ReplyReply

And if the attitude from Adobe is that good metadata is less relevant than workflow, can they at least tell their blogger friends to stop promoting the use of "One Big Folder and then sort it all out in LR" approach? You're not providing the tools to do so.
Logged
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #13 on: December 01, 2010, 05:28:27 PM »
ReplyReply

Well part of this can probably be done today. The Library filters will provide searching for JPEG, TIFF and PSD. I have a group of smart collections that search for JPEGs, CRWs, DNGs, PSDs etc. But JPEGs in sRGB, or TIFFs in 16-bit, nope. Or TIFFs over 10mb (or with a long axis over 1000 pixels). That would be useful.

What is the point of a Smart Folder of, say, 5000 PSDs that can't be sorted or filtered by other useful file characteristics, like bit depth, size, color profile, etc?

It's a rhetorical question, but jeez, we need to be able to narrow the field more than that to be useful.
Logged
JRSmit
Sr. Member
****
Offline Offline

Posts: 358


WWW
« Reply #14 on: December 02, 2010, 12:04:10 AM »
ReplyReply

For instance, lets take a hypothetical.

Imagine a person has a fussy client who will ultimately want a retouched image provided in different formats, sizes, depths and color profiles. Imagine too that in the process of getting to the final master image, the client needs to be presented variations to choose from; perhaps a conservative rendering, normal and edgy. And perhaps it takes a couple more rounds of iterations/variations to nail it. Once nailed we go to the differing sizes, outputs, color spaces etc.

All told, one could end up with 20+ derivations differing, in size, bit depth, color profile, etc. And what if said client requires this of 10 different images 10 times per year?

If one is not meticulous in their naming, metadata-ing and organizing along the way there can be quite a mess to clean up later. Lets assume at times that degree of meticulousness has not been present. Assuming all the images are cataloged in LR, should LR be an aid making sense of the mess or not?

Again, all hypothetical, but sometimes reality is even stranger than fiction.  Shocked

How in your way of working before using LR would you manage such a case?
Logged

Fine art photography: www.janrsmit.com
Courses and workshops: www.centrumbeeldbeleving.nl

Jan R. Smit
NikoJorj
Sr. Member
****
Offline Offline

Posts: 1063


WWW
« Reply #15 on: December 02, 2010, 06:17:11 AM »
ReplyReply

1) LR can not do the variety of iterations that PS can. How about a variation with the cow in the shot and one without? Give me a pen tool, layers with adjustable masks and blend modes, a viable clone/healing solution, cut and paste, etc, and we can begin to compare, but not until.
Dead easy : edit in PS, and back in LR set a keyword relevant to that mod like "without cow".
I doubt these kind of pixel-editing functions could be available in LR (and personally don't hope so as I don't need them).

Quote
2) There's no failsafe. [...]
So rather than allowing the program to read basic characteristics of a PSD/TIF/JPEG, and sort, filter and smart collect along those lines (like Bridge can,) users are out in the cold and need to come into LR as advanced users with their PSD/TIF/JPEGs already sorted, maintained, encoded and organized.
I respectfully but strongly disagree.
For the kind of need you presented, you DO need to organise your files a minimum, at least with some basic keywording, because you won't be able to tell  the "subtle" development from the "punchy" one otherwise.
Doing that is a little time investment (and it's quite easy to automate) that earns bigger time savings afterwards.

But as said, I fully agree to the need for more metadata-based querying, so that this basic work of keywording doesn't have to be redundant (eg keywording "8bit" the 8-bit files).
Logged

Nicolas from Grenoble
A small gallery
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #16 on: December 02, 2010, 10:41:49 AM »
ReplyReply

How in your way of working before using LR would you manage such a case?


Using Bridge. It can sort/filter/smartcollect/display more relevant metadata for PSD/TIF/JPEGs.
Logged
smahn
Full Member
***
Offline Offline

Posts: 127


« Reply #17 on: December 02, 2010, 11:01:37 AM »
ReplyReply

I doubt these kind of pixel-editing functions could be available in LR (and personally don't hope so as I don't need them).

And I'm not asking LR to be PS, I'm simply refuting Eric's suggestion that VCs obviate MY need for multiple PS renderings. (understanding it may for others).

My one processing feature request for LR, though, would be the ability to import PS masks/selections/paths. I don't expect it to let me make them as well as PS, but it would be great if I could import existing ones.

But as said, I fully agree to the need for more metadata-based querying, so that this basic work of keywording doesn't have to be redundant (eg keywording "8bit" the 8-bit files).

Exactly. Should I really have to key word files by bit depth, color profile, size, height, etc?
« Last Edit: December 02, 2010, 11:03:31 AM by smahn » Logged
Pages: [1]   Top of Page
Print
Jump to:  

Ad
Ad
Ad