# Stacks, why bother?



## tspear (Nov 30, 2021)

Question, after using Lr for a while and seeing the stacks auto created for merged images, I have come to the question. Why bother?
Basically, stacks are only useful in the unfiltered views for all photos or a specific album. So they only help when scrolling through images, not very useful when managing 20K images. 

As a result I created this issue over on Adobe: https://community.adobe.com/t5/ligh...deas/p-search-filter-on-stacks/idi-p/12558985
However, now I wonder. Was I hasty? Am I missing something?

Tim


----------



## Linwood Ferguson (Nov 30, 2021)

I agree that the current stack implementation is often (maybe mostly) more trouble than it is worth.  I pretty much stopped doing it after screwing up changes (metadata especially) due to how they are applied differently whether selected stack collapsed or expanded.  I now use them only temporarily, e.g. as a way to group players in team action shots so I can review how many of each, then I unstack before doing anything else. 

I am not sure if your recommendations are adequate to make them fully useful, but I absolutely agree that stacks, as implemented, are badly done and more dangerous than useful.   

The one area I might still use (and know I have some of) are things like HDR groups.  Not that it works well there (again, metadata changes being a good example), but it seems the only good way to maintain that grouping especially if intermixed (over time say) with individual shots of the same subject.


----------



## clee01l (Nov 30, 2021)

I too have found little benefit from stacks. And often people come here complaining about missing photos only to discover with a little prompting that their missing photos are buried in a stack.

Stacks could be useful for focus stacks, Panoramas and HDR. I would like to see an option to auto-expand stacks with a mouse over. The present method for identifying stacks is not noticeable enough to recognizes the photo that you might be looking for is in a stack hidden behind the the cover photo.


Sent from my iPad using Tapatalk


----------



## Victoria Bampton (Nov 30, 2021)

If there were global stacks for HDR/pano elements, those would be useful for keeping all the "bits" together. But the current implementation... yeah, not ideal.


----------



## Linwood Ferguson (Nov 30, 2021)

clee01l said:


> Stacks could be useful for focus stacks, Panoramas and HDR. I would like to see an option to auto-expand stacks with a mouse over. The present method for identifying stacks is not noticeable enough to recognizes the photo that you might be looking for is in a stack hidden behind the the cover photo.


My main complaints lie not in the UI, but in what happens when you are not specifically looking at a stack.  A search to find something, control-A, a change in metadata, a mass delete, a move to a collection... almost all of these end up doing the wrong thing (I admit that doing the opposite thing could also be construed as wrong, but I think what it does now is more wrong [and if this phrase makes you think of a suspension bridge you watched the Big Bang theory too often]).


----------



## tspear (Nov 30, 2021)

BBT rocks. 

So it is not just me. Now, how do we get Adobe's attention to fix it!


----------



## Linwood Ferguson (Nov 30, 2021)

tspear said:


> BBT rocks.
> 
> So it is not just me. Now, how do we get Adobe's attention to fix it!


You stand a better chance of having Sheldon take up mud wrestling in a new BBT season.   

I think stacks are baked into the paradigm, they would be very scared of changing it and breaking people's workflow (not to mention they are always reluctant to change anything that is not their own idea - they have 10 year old bugs they show no interest in addressing).


----------



## tspear (Nov 30, 2021)

For Lr,  not Classic. No one has baked workflows. I asked for months, even from our own @Victoria Bampton  to have a solid workflow to use with Lr. I pestered multiple people at Adobe and on multiple forums. No one had one. I had to invent one, and at this point I consider it only parboiled and would gladly change things to fix the fricking stacks.


----------



## Linwood Ferguson (Nov 30, 2021)

Ah... my apologies, I did not realize I was in Cloudy.  I'm not even sure my comments applied (though I guess they rang true). 

Hey... Cloudy is for you kids with cell phones.  They don't need no stinking workflow, it has the word "work" in it.


----------



## tspear (Nov 30, 2021)

Linwood Ferguson said:


> Ah... my apologies, I did not realize I was in Cloudy.  I'm not even sure my comments applied (though I guess they rang true).
> 
> Hey... Cloudy is for you kids with cell phones.  They don't need no stinking workflow, it has the word "work" in it.


lol, well i am still working and will not likely see anything I put in for the past 33 years or the next 15.  Since my elders will have spent us into oblivion. So who would want to work with that incentive? 

Tim


----------



## Victoria Bampton (Dec 3, 2021)

tspear said:


> For Lr,  not Classic. No one has baked workflows. I asked for months, even from our own @Victoria Bampton  to have a solid workflow to use with Lr. I pestered multiple people at Adobe and on multiple forums. No one had one.



I think that's simply because there is no one-size-fits-all solution. Everyone's needs are different. What everyone wants to accomplish is different. And with the number of devices involved with the cloud, that has even more permutations than workflow ever did with Classic. That's why we aim to teach principles and methods rather than a fixed workflow.


----------



## tspear (Dec 3, 2021)

@Victoria Bampton 

I disagree.  Image management is obviously an after thought in Lr. Even as much as I like your _Edit Like A Pro_ book, you also only walk users through a very simplistic sequence, take photo, put in some meta-data, edit image, and post it somewhere. 

The number of device types supported by Lr not only increase traditional UX issues, it also very likely broadens the reach of the application to a larger user base. The result is greater complexity, but this is just an excuse. Of the items I list below, only stacks (the subject of this thread) is actually is actually difficult from a UX perspective.

The reality is there are only a few functions in Classic that do not exist in Lr which are used for image management. 
1. Color Labels
2. Smart Collections
3. Better stack/group management

Pretty much everything else is just noise.


----------



## Jimmsp (Dec 3, 2021)

Victoria Bampton said:


> I think that's simply because there is no one-size-fits-all solution. Everyone's needs are different. What everyone wants to accomplish is different. .....


If you have ever tried to teach a LR Classic course to a group of photographers, then this hits the nail on the head. I can just work on instructing on the library module, and your sentences are a perfect description of my experiences. And it is almost at its worst when an experienced photographer decides to transition to LR Classic, and he brings all his previous ways of doing things with him.
BTW, I primarily use stacks for my hdrs, panos, and focus stacks. They are useful to me, even with a shortcoming or two, and I want them to stay.


----------



## PhilBurton (Dec 4, 2021)

Victoria Bampton said:


> If there were global stacks for HDR/pano elements, those would be useful for keeping all the "bits" together. But the current implementation... yeah, not ideal.


I've been frustrated more than once (second time, shame on me ...) because a stack implemented in one collection does not carry over to any other collections or to the actual physical files on disk.    Regular, "dumb" drag and drop collections, not smart collections.

I find stacks useful when photographing a baseball game, because there are plays and then pauses between plays.  I might shoot the play at 9 fps in order not to miss a key moment, but I want to review all the photos of that play as a group.

It would also be nice if stacks could be named.


----------



## Victoria Bampton (Dec 6, 2021)

tspear said:


> Even as much as I like your _Edit Like A Pro_ book, you also only walk users through a very simplistic sequence, take photo, put in some meta-data, edit image, and post it somewhere.


I'll be honest, I'm still not quite clear on what other bits of workflow are you looking to include in this "ideal workflow", in addition to taking photos, adding metadata, editing and sharing?  


tspear said:


> Image management is obviously an after thought in Lr.


That is, of course, a different issue entirely. It's not so much as an after thought as much as simply different priorities. Not having to manage photos is one of their main sales points for the ecosystem.


----------



## Jimmsp (Dec 6, 2021)

Victoria Bampton said:


> That is, of course, a different issue entirely. It's not so much as an after thought as much as simply different priorities. Not having to manage photos is one of their main sales points for the ecosystem.


As you may know, there are other forums out there where a number of photographers vent their severe displeasure for Adobe and Lightroom Classic because they are "forced" to use a catalog. LR cloudy, in some way, is a response to that market segment.


----------



## Colin Grant (Dec 7, 2021)

Jimmsp said:


> As you may know, there are other forums out there where a number of photographers vent their severe displeasure for Adobe and Lightroom Classic because they are "forced" to use a catalog. LR cloudy, in some way, is a response to that market segment.


Are there any DAMs (as oppose to glorified file managers) that do not use a catalogue? C1 does have Sessions as well but still offers a catalogue.


----------



## Rob_Cullen (Dec 7, 2021)

IMO-  File managers (file browsers) are not DAMs. (The computer operating system is the 'manager')
And DAM apps cannot operate without a Database (catalog) of some kind (that I can know!).


----------



## Colin Grant (Dec 7, 2021)

Rob_Cullen said:


> IMO-  File managers (file browsers) are not DAMs. (The computer operating system is the 'manager')
> And DAM apps cannot operate without a Database (catalog) of some kind (that I can know!).


That is exactly man point! I said DAMs "as oppose to"


----------



## clee01l (Dec 7, 2021)

Rob_Cullen said:


> IMO-  File managers (file browsers) are not DAMs. (The computer operating system is the 'manager')
> And DAM apps cannot operate without a Database (catalog) of some kind (that I can know!).


Before I started using Lightroom, I used Bibble as a non destructive Image editor.  IIRC it has some collection capabilities but used the filesystem for main organization the Bible work including collection membership was kept in sidecar files.  Corel bought Bubble in 2009 and turned it into AfterShot.


----------



## Jimmsp (Dec 8, 2021)

Colin Grant said:


> Are there any DAMs ...... that do not use a catalogue? C1 does have Sessions as well but still offers a catalogue.


A catalog is a DAM . It is a Digital Asset Manager. It does not necessarily have the ability to process the files that it manages.
I am guessing that you meant - are there any photo processing applications that do not require a catalog or DAM in order to open and find a photo which it will then post process.  There are lots of them. In the Adobe world, Photoshop Elements  and Photoshop can directly open a file without having it pass through a catalog. Photoshop Elements has a catalog as part of its over system. C1 needs to have a file incorporated into a session (at a minimum) in order to open it.  Other software like ACDSee can, as I recall, also open a file directly for post processing. It also has DAM capabilities using a file manager as its basic engine.


----------



## Colin Grant (Dec 8, 2021)

Jimmsp said:


> A catalog is a DAM . It is a Digital Asset Manager. It does not necessarily have the ability to process the files that it manages.
> I am guessing that you meant - are there any photo processing applications that do not require a catalog or DAM in order to open and find a photo which it will then post process.  There are lots of them. In the Adobe world, Photoshop Elements  and Photoshop can directly open a file without having it pass through a catalog. Photoshop Elements has a catalog as part of its over system. C1 needs to have a file incorporated into a session (at a minimum) in order to open it.  Other software like ACDSee can, as I recall, also open a file directly for post processing. It also has DAM capabilities using a file manager as its basic engine.


No I am saying a DAM needs a catalogue. I am saying that if you want the searching capability of the likes of PhotoMechanic, Lr, C1 et al then there will be a catalogue. Even ON1 needs a catalogue if you are going to use the more advanced feature of the Library, the same applies to DxO PhotoLab. The likes of Luminar of course do not have a dam they just have an image browser attached. Now, whether there is any sense in the likes of Lr giving the user the option to turn off the catalogue and related functionality is probably a question not  worth asking as it will never happen.


----------



## tspear (Dec 8, 2021)

Victoria Bampton said:


> I'll be honest, I'm still not quite clear on what other bits of workflow are you looking to include in this "ideal workflow", in addition to taking photos, adding metadata, editing and sharing?
> 
> That is, of course, a different issue entirely. It's not so much as an after thought as much as simply different priorities. Not having to manage photos is one of their main sales points for the ecosystem.


Go on a trip where you cannot readily connect to the net. Take a thousand or more images; and load them in Lr.
Go to the next location, and start taking photos.
How do you manage the photos? How do you know which you have added, which you have posted online....
The take pic, meta-data, edit, post, file flow works in a cell phone with just a few images, or for someone super aggressive about editing and posting on the fly with a connection always or every night when you get back to the hotel.
But for most of us, I doubt many of us actually manage to get through all the images we take every single day.

It's the same basis for John Beardswoth smart workflow.


----------



## Jimmsp (Dec 9, 2021)

tspear said:


> Go on a trip where you cannot readily connect to the net. Take a thousand or more images; ......
> Go to the next location, and start taking photos.
> How do you manage the photos? ....


Adobe has provided me the solution to this - I bring a laptop with me, and use Lightroom Classic.


----------



## tspear (Dec 9, 2021)

Jimmsp said:


> Adobe has provided me the solution to this - I bring a laptop with me, and use Lightroom Classic.


lmao. Well played. 
I have designed a flow that works in the cloud version. I had to effectively go old school and base it around folders (oops, I mean albums).  I have used it for a few months now (ok, I did it in parallel with Classic for a few months first), and it works well. Makes swapping between devices very easy, I even occasionally manage to work on images on my phone while traveling and waiting in lines.  I recently had started to make some minor tweaks to it, my original version was really geared more to working the images post trip.  now I eliminated a couple steps, and I think I will eliminate a few more over the next year as I get better about working images on the fly no matter where I am.


----------



## tspear (Nov 30, 2021)

Question, after using Lr for a while and seeing the stacks auto created for merged images, I have come to the question. Why bother?
Basically, stacks are only useful in the unfiltered views for all photos or a specific album. So they only help when scrolling through images, not very useful when managing 20K images. 

As a result I created this issue over on Adobe: https://community.adobe.com/t5/ligh...deas/p-search-filter-on-stacks/idi-p/12558985
However, now I wonder. Was I hasty? Am I missing something?

Tim


----------



## Victoria Bampton (Dec 10, 2021)

tspear said:


> Go on a trip where you cannot readily connect to the net.


Months before the cloud version's release, I did exactly that as a test case. 6042 photos to be exact. The workflow outline on pages 5-10 of Edit Like a Pro and the order of the book was decided on that trip, except the sync waited till I got home as the hotel wifi was awful and I was on vacation so didn't want to spend every night sorting out photos! It was before version 1, so there weren't as many features as there are now, and there were a lot more bugs!

Everything got imported every night or two. Everything from that vacation dropped into an album, or I could have used an album per day. I did a quick skim through and flagged my favorites and rejected the duds. I added odd keywords in bulk to remember names of locations. Filtered just the flagged ones and did rough edits and dropped them in a shared album for friends/family back home. If I shared on social, I added a keyword to remind me. If there were photos that needed merging (this was before LR had merge), they went into an album called @Merge. That's it. 

When I got home, I started back at the beginning of the workflow, with the exception of needing to add the photos. Everything synced to the cloud. Anything that didn't have a star rating was yet to be assessed, any keepers either needed editing or their edits needed tweaking on a better monitor. Simple as that.

Everyone will have their own preferences. Some people might prefer to only use flags, whereas I prefer flags for first pass and stars for second pass. I rarely bother to add Titles or Captions, except for the 4-5 star photos, and I don't add a lot of keywords. My album organization is fairly limited, but I do keep a few workflow albums starting with (e.g. @To Edit, @To Photoshop, @To HDR Merge etc.) for when I'm working on my phone/tablet, to remind me of things I want to do back at a desktop. 

Most people coming to LR Cloudy are not coming from a Classic background, and don't want that level of having to "manage photos", but for those who do, I would suggest keeping it simple, and probably basing it around albums and folders. That would be easier to do if we some day get saved searches.


----------



## PhilBurton (Dec 11, 2021)

Colin Grant said:


> . Now, whether there is any sense in the likes of Lr giving the user the option to turn off the catalogue and related functionality is probably a question not  worth asking as it will never happen.


Lightroom uses its catalog to store keywords, collections, and all DEVELOP settings.  Also books, etc.

I doubt that any non-destructive photo editor can work without some sort of catalog.


----------



## tspear (Dec 11, 2021)

@Victoria Bampton 

You give a very good description of the tools, and what steps should be there on pages 5-10. However, I do not see a well defined sample workflow. 
Or I might just be obtuse


----------



## tspear (Dec 11, 2021)

PhilBurton said:


> Lightroom uses its catalog to store keywords, collections, and all DEVELOP settings.  Also books, etc.
> 
> I doubt that any non-destructive photo editor can work without some sort of catalog.


DarkRoom can run sort of run without a catalog or database. 
If you desire to set it up this way, DarkRoom can store all information in XML side car files, and on startup generate the database (which by default is an in memory database only). This method is great for portability, but you take a massive performance hit since nothing is cached from session to session. (I used DarkRoom for a bit looking to replace Lr, ran into some missing features which is why I never made the jump).


----------



## Colin Grant (Dec 11, 2021)

PhilBurton said:


> Lightroom uses its catalog to store keywords, collections, and all DEVELOP settings.  Also books, etc.
> 
> I doubt that any non-destructive photo editor can work without some sort of catalog.


ON1 gives users the option to catalogue or not,  and DxO PhotoLab does similar. Certain functionality is lost as a result of course but for those who just want a file browser rather that a DAM the option is there.  That said I reckon there must still be some sort of database management at play.

Still, if there are users who do not like the idea of a DAM in Lr why not just use Bridge, or similar, and Ps. Camera Raw functionality is still available.


----------



## PhilBurton (Dec 11, 2021)

Stepping back a bit, why is the concern about use of a catalog?

The "Adobe lockin" comes from using the DEVELOP module, not the catalog itself.


----------



## Colin Grant (Dec 11, 2021)

PhilBurton said:


> Stepping back a bit, why is the concern about use of a catalog?
> 
> The "Adobe lockin" comes from using the DEVELOP module, not the catalog itself.


It is just something mentioned earlier in this thread - some people not being happy with Lr pushing them into a catalogue. Never understood the problem myself but there are many who are hung up on it. Have heard that particular moan on many occasions.


----------



## PhilBurton (Dec 12, 2021)

Colin Grant said:


> It is just something mentioned earlier in this thread - some people not being happy with Lr pushing them into a catalogue. Never understood the problem myself but there are many who are hung up on it. Have heard that particular moan on many occasions.


I know, but I just don't understand the hangup.  What if that Lightroom file were called the "database?"  Email always uses a database.  So do personal finance programs.  And FireFox.  https://www.sqlite.org/famous.html


----------



## Hal P Anderson (Dec 12, 2021)

I think some people simply don't want to keep LRC's kind of track of their images. They just want to choose an image and go straight to editing it without the hassle of importing it into a catalogue. 

I couldn't work that way. I _need _the DAM aspects of the application.


----------



## Jimmsp (Dec 12, 2021)

Hal P Anderson said:


> I think some people simply don't want to keep LRC's kind of track of their images. They just want to choose an image and go straight to editing it without the hassle of importing it into a catalogue.


Exactly. It is also a easy excuse to avoid Adobe and Lightroom.


Hal P Anderson said:


> I couldn't work that way. I _need _the DAM aspects of the application.


As do I.  I am constantly moving back and forth between the Develop and Library modules.


----------



## PhilBurton (Dec 12, 2021)

Hal P Anderson said:


> I think some people simply don't want to keep LRC's kind of track of their images. They just want to choose an image and go straight to editing it without the hassle of importing it into a catalogue.
> 
> I couldn't work that way. I _need _the DAM aspects of the application.


Hal,

We are in very strong agreement.  An import-free alternative to Lightroom is Adobe Camera RAW, but not for me.  

Phil Burton


----------



## Colin Grant (Dec 12, 2021)

I need the DAM too, without doubt. Interestingly a while ago I was reading sometghing about Exposure X and the fact that it does not have a catalogue thus one does not have to import. Well yes, but no really as it indexes the images in the background.


----------



## PhilBurton (Dec 13, 2021)

Colin Grant said:


> I need the DAM too, without doubt. Interestingly a while ago I was reading sometghing about Exposure X and the fact that it does not have a catalogue thus one does not have to import. Well yes, but no really as it indexes the images in the background.


So when is a database not a database?  or a catalog?


----------



## Colin Grant (Dec 13, 2021)

PhilBurton said:


> So when is a database not a database?  or a catalog?


When you do not have to physically import the images a la Lr?  IMO the moans in the main come from those looking for a reason to go Adobe bashing. That particular "sport" is becoming so boring.


----------

