Sunday, April 4, 2010

Stacks and Keywords

The docs say that keywords applied to the top image of a stack will be applied to the images in the stack. This morning I was keywording a lot (2200) images I had previously grouped into stacks. After working through a number of stacks I saw that the keywords were only applying to the top image.



The workaround is to select the stack, press S to expand the stack, set the keyword(s), press S again to collapse the stack.



Is there a formal bug list for LR?
Stacks and Keywords
Where do the docs say that?
Stacks and Keywords
In the on-line Help docs.

Well the docs are wrong, as I am sure Lee Jay will come back and tell you, and why.



Don



Don Ricklin, MacBook 1.83Ghz Duo 2 Core running 10.4.9 %26amp; Win XP, Pentax *ist D

http://donricklin.blogspot.com/


LOL!



The whole point of a stack is to hide the images beneath the top one from operations. If you select a stack, then expand it, you'll see that the images in the stack beneath the top one are not selected. This isn't a bug in LR, it's a bug in the docs if you are indeed right about that.



Now, in pod cast 29 there was some discussion about changing this behavior. I'm not in favor of that. To me, consistency is a good thing and a stack should hide the images beneath the top one from all operations except moving the entire stack around. As you correctly pointed out, there is a very simple alternative way to apply operations to all images in stacks if that's what you want to do - just expand the stacks, apply your operations, and re-collapse them.

That's too bad. Grouping images into stacks is extremely handy for working with large numbers and being able to tap the stack to set keywords would be a neat workflow.

Lee,

I am, indeed, correct about the docs. See for yourself:



''Collapsed stack (top) and expanded stack (below)



Here are a few tips for working with stacks:



*

Any develop adjustments, ratings, flags, or color labels applied to a collapsed stack affect only the top photo.

*

Keyword tags applied to a collapsed stack are applied to all photos in the stack.

*

If you select a photo in a stack and add it to a Quick Collection or collection, only the selected photo is added, not the entire stack.

*

When you search for photos, the top photo in a stack appears with the number of photos in the stack in the upper left corner.''

A stack does not just hide frames - it says they all of the same subject. Keywords describe the subject. Therefore, when you apply keywords when they happen to be stacked, LR should be applying that keyword to them all. Lee Jay and I have discussed this ad nauseam in the feature requests forum and he is still wrong. He doesn't need DAM anyway.



John

%26gt; Keyword tags applied to a collapsed stack are applied to all photos in the stack.



Thanks for that. That's just wrong.

Lee,

Another thing - when I select the top image of a stack and expand it, as you describe, all the images within the stack are indeed selected. This is what made the workaround I described - well - work.



Apparently when the stack is collapsed only the top image is selectable and therefore affected.



I agree with the issues of consistency. I would favor the other direction, namely being able to apply edits and changes to a stack of images. But maybe I'm not using stacks the way they were envisioned. If the idea is to group bursts and multiple edits of the same image together then I see your point.



In my case I was using stacks to group participants in a sporting event. Once I had each participant in their own stack I went back to keyword them. This also make the whole shoot more manageable in the Grid view.

And I think Thomas Knoll (trying to remember who was talking during the pod cast) has the same opinion as John's and his opinion might count just a teeny bit more than mine does.

%26gt; Another thing - when I select the top image of a stack and expand it, as you describe, all the images within the stack are indeed selected.



They are? I definitely tried this and they are not. What I mean is, select all (or a whole bunch of images with some stacks) and then hit ''expand stacks''. The images below the stack are not selected, at least for me.

Lee,

You are correct about selecting multiple stacks.



But if you select a single stack and expand it all images in the stack become the selection. I may not have made that clear.



This would be a good distinction in the way keywords, for example, are applied.

Ah, I see now. See I was thinking that the workaround if you indeed want to apply keywords to all images in stacks is to hit control-A, expand all the stacks and then go-a-keyword'n. When you're done, control-A, contract all stacks.

It sounds like you are looking at the task as attempting to apply keywords to all images and I'm looking at applying keywords to images within a stack.



So it seems we have determined:

* the docs are wrong

* the process for keywording (or editing) images within a stack is as I described - click on the stack, expand it, perform actions on the selected images and collapse the stack.

No I was just saying you can expand all the stacks and go keywording after that. You can still apply keywords to all the images in a stack by selecting them all or stamping etc. Then, when you are all done, select all and recollapse all the stacks in one shot.

I would like to see keywords applied to all images within ONE stack. this is intuatuve for me.

%26gt; I would like to see keywords applied to all images within ONE stack. this is intuatuve for me.



What about ratings? Probably one at a time.



What about color labels? Hmmm...I use them to categorize types. All together?



What about flags? Just the top one, right?



Comments in metadata? One at a time or all together?



Image corrections? Should a stack act like autosync or one image a time?



What if I use keywords to describe why I didn't choose a particular image (blurry, OOF, DOF too shallow, DOF too deep, eyes closed, whatever)?

Lee,

Take a deep breath. A walk perhaps...

We've got 27mm of rain today, and it's still pouring with the wind above 10 meters per second (22 miles per hour).



I think I'll stay inside.

''What about ratings? Probably one at a time.''

Yes, bc the best is probably at the top, but still from the same place or the same style.



''What about color labels? Hmmm...I use them to categorize types. All together?''

As above



''What about flags? Just the top one, right? ''

All white flagged. If X'ed then not in the stack, just deleted.



''Comments in metadata? One at a time or all together?''

As per ratings



''Image corrections? Should a stack act like autosync or one image a time?''

Depend if the images are a burst or not



''What if I use keywords to describe why I didn't choose a particular image (blurry, OOF, DOF too shallow, DOF too deep, eyes closed, whatever)?''

Then its deleted, why waste space!



Can't beet a walk in the rain.

So, when I take a whole bunch of shots at a wedding, and I categorize them with color labels into categories like ''posed'', ''candids'', ''art shots'', and ''objects'', stacking similar shots together should prevent me from applying color labels and the categories that go with them down through the stack? That doesn't make sense to me if I can apply keywords down through the stack.



A walk in the rain is nice. A walk in the pouring rain at 35掳F and 20mph of wind is nothing but shear misery.

Ah, but then it feels so good to come in out of the rain..... :)



I try to keyword before making stacks, but then I'm not a big stacker. Consistency is a good thing, and I can see why applying keywords to all in an unexpanded stack might not be a good idea. But then, on the other hand.....



I'm getting too wordy. Good night.

After thinking about this a bit more it occurs to me that 'stacks' are being used in two ways:

* to organize sets of versions of the same shot

* to organize sets of images thematically linked



The first case seems to be the predominate one. In this situation it makes sense that the image on top is the preferred shot from the stack and, therefore, the single image any action should be applied to. (Keywords, edits, etc.)



The second case is where stacks are created to group images rapidly and make a large number of images workable. This is the one I happened upon. In this situation it is desirable to have actions apply to all images in the stack.



These two approaches are mutually exclusive yet useful. So I'd like to see it become a Preferences setting. Something like,

[ ] Actions %26amp; keywords applied to stacks affect top image only.

[ ] Actions %26amp; keywords applied to stacks affect all images in stack.



I do mainly events right now so I'd prefer the second. But if I start shooting fashion, for example, I'd like to group the images of a single model into stacks for each pose and put the best on top. Doing this work I'd set the first option.

Stacks are indeed used in different ways as you said:



- to organize sets of versions of the same shot

- to organize sets of images thematically linked



The first one seems to imply that all the images are of the same subject and thus should have the same keywords applied, but not the same ratings or pick flags, but perhaps the same color labels.



The second seems to imply that you are using stacks as collections (all my sunset images from Hawaii, for example). In that case, I'd think you'd want to apply different keywords to each image since you may have taken some sunset shots on Oahu, and some on Maui.



Anyway, I still don't see the need for a preference since you can still do either one (drive keywords to all images in the stack, or not) simply by leaving images in their stacks (you get only the top image, or expanding the stacks (keywords go to all selected).

%26gt; Anyway, I still don't see the need...



That is clear.



It's also why it is a appropriate to be an option. One can set it if it's useful and ignore it if it isn't.

And the fact that it can be done without an 'option' (as Lee jay points out) means it is unlikely to be implimented in the short run with so much else for them to do.



I am sure they have noted the request by now. Maybe it is time to move on.



Don



Don Ricklin, MacBook 1.83Ghz Duo 2 Core running 10.4.9 %26amp; Win XP, Pentax *ist D

http://donricklin.blogspot.com/


People should know the team is very averse to adding preferences unless absolutely necessary to reduce modality.

Lee,



Would you explain how adding stack preferences makes LR more modal? It's modal by design and it works that way. If I had my way, there would be a metadata module instead of cramming that into the Library module...



Jim

If you use LR on your machine with that preference set, and then on my machine with it not set, there's no way to see the difference without going to the preferences screen. That's modal (which ''mode'' the preference is set to). They prefer to keep preferences to a minimum and, where they are used, they are often for things you can either see (grid cell type and layout, for example) or that don't need to be seen (how often to discard 1:1 previews, for example). They'd prefer to minimize the number of ways you can change the behavior of the software through changing preferences. At least, this is my read of the group.

Which is a refrheshing change from PSCS with it five ways to heaven to st something and God forbid you did not unset a pref and go to do something else twith that brush on another pic on another day in a rush...



That's modal.. as apposed to modular ( a type of modality) which LR is in spades.



Don



Don Ricklin, MacBook 1.83Ghz Duo 2 Core running 10.4.9 %26amp; Win XP, Pentax *ist D

http://donricklin.blogspot.com/


I wonder if it might be possible to rig the interface so if (for example) one applied a keyword normally it would only affect the top image in the stack, and applied the keyword while holding down the ALT key (or some other key) it would be applied to the whole stack?

Or that modifier could work the other way round, ie apply keywords correctly.



There are plenty of ways this could be handled which would keep the clearsighted and the muddy thinkers happy. For example, bring on scripting! An OnKeyword event could trigger code - in this case the code might test if the images are stacked and then post the keyword to the other frames (assuming the current behaviour remains uncorrected).



John

%26gt;After thinking about this a bit more it occurs to me that 'stacks' are being used in two ways: (1) to organize sets of versions of the same shot (2) to organize sets of images thematically linked



Exactly, and that is why I think that Lightroom should start making a distinction between 'stacks' (for the second type) and 'versions' (for the first type). The functionality of either can then be optimized for its intended purpose.



Stacks would be purely a visual aid that helps to remove clutter. It can remain tool-agnostic as it is now. In other words, keywords and categories are only assigned to the active image. Versions can be implemented in a similar way to stacks, but would imply a much stronger link between the images.



For versions, the default behavior could be to assign keywords and collections to all versions at the same time, although, ideally, you should be able to every collection or keyword a 'content' or 'version' flag. With a 'content' flag, they are applied to all versions of an image, and with a 'version' flag they are version-specific. Ratings would be version specific as well...



For more details on a possbible implementation of versions, see
Simon Tindemans, ''Basic Version Management'' #6, 22 Apr 2007 2:27 am



Cheers,

Simon

''After thinking about this a bit more it occurs to me that 'stacks' are being used in two ways: (1) to organize sets of versions of the same shot (2) to organize sets of images thematically linked''



Exactly, and that is why stacks are not just a visual convenience. They hide clutter which arises only because of a number of frames of one subject. One subject, so keyword assignment needs to apply to each frame in the stack. For a looser thematic structure, we already have collections, keywords etc.



John

Why do you assume that everyone will use stacks only to group shots of the same subject or set of subjects? That's not how I create stacks of prints when I'm preparing to put them in an album.

Not assuming, but having observed people working, and further shown by the auto stack by capture time feature that you see in LR, Aperture, iView, Bridge.... I've no problem with both keyword assignment methods being available, but the default behaviour needs to follow the most common use.



John

I don't really see why anyone would stack virtually identical images (like from a burst) with the best one on top. It seems to me that that's what the rating stars and filters are for.



Both approaches are currently available, as you mention, but reversing the default behavior would making applying keywords to only the top image harder that it presently is to apply keywords to all the images in a stack. Currently, you just unstack and select all, of if a single stack, just select it and expand. If the default were to apply to all the images, you'd have to unstack and go through and select just the top images by hand which is much harder than either approach to doing what you want to do is currently.

Well, that's what people do - ask the marketing guys who do the fancy stacking video for Aperture. The best of all worlds would be to make it a preference.

Yeah...I saw that video. I guess I just don't think like Apple does. That's probably why I don't own any Apple products - I find them confusing, hard to use, and counter-intuitive.

''I don't really see why anyone would stack virtually identical images (like from a burst) with the best one on top.''



Well, thats not suitable for your workflow. But it is for me and i suspect many others. It is exactly what i do. Or, if i take a series of landscapes from a tripod with only exposure or ISO changes, i will also choose the best on top, not meaning that i will discard the others. Maybe one of those further down the stack is better suited to BW, which i may come to at a later date.



For me though, if i make a virtual copy specifically for a grayscale image, i would like the keyword ''grayscale'' to be automatically applied to the metadata. This makes it handy not to have to return to the library mode to apply this, in my opinion, essential keyword for separating black and white images.



Flexability is the keyword here!

Frankly, I'd like LR to automatically correct the word grayscale to black and white whenever the system encounters this utter obscenity. Who shoots ''grayscale''?

Who shoots black and white? You only need 1 bit per pixel to store it so that's a nice advantage.

Not advocating shooting b%26amp;w on a digital camera, but you never heard old Ansel shooting ''greyscale''. Now I wonder if there's a language file I could hack and erase that horrible word.

Have you looked at Jeffrey's Config Thingy? He'd be the one to know.



Don



Don Ricklin, MacBook 1.83Ghz Duo 2 Core running 10.4.9 %26amp; Win XP, Pentax *ist D

http://donricklin.blogspot.com/


I hadn't, instead I'd been opening odd files in text editors, but that's a good idea Don.



John

Ok, then 'black and white'. personally i also prefer this term, but the point was for auto keyword generation within the develop module.

No comments:

Post a Comment