Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: Bob Rockefeller on August 08, 2014, 12:14:56 pm
-
I've just finished Peter Krogh's excellent book Organizing Your Photos with Lightroom 5. In it, he suggests that the "storage layer" of your library be a hierarchy of folders organized by date. So there'd be folders for year and in them folders for months and in them folders for days.
I'm moving over from Aperture where my arrangement was by location, instead of by date; I figured the EXIF data already had the date, but it didn't have the location. So I have folder groups like Mexico > Cozumel > Beaches or Georgia > Atlanta > Georgia Aquarium. And now my Lightroom catalog has that same folder organization.
For those with more Lightroom catalog experience, is that a bad thing or a potential dead end? How?
-
First off, Peter's book is a must read. For one, you can get ideas and season to taste. But don't feel you must follow his steps precisely and instead use suggestions based on what works best for you. For example, the idea of a well organized folder structure is super important IMHO (so you can find stuff outside of LR, don't depend fully on it). For me, dates don't work well at all. I'm not a date person. Plus I can always filter folders by date using the Finder. I'm more of a 'place' or 'subject' kind of guy. I can't recall the two dates, even years I went to Sydney AU but I know that if I want to find those images outside LR, a folder named Sydney will have those images. Sydney with a date doesn't help me one bit. So my point is, build your organization based on what works best for you. If you recall dates, work with dates. If you recall person/place/thing, name folders that way.
Peter's suggestion works well for him, it would confuse the heck out of me. I can't recall what I ate for breakfast day before yesterday.
So I have folder groups like Mexico > Cozumel > Beaches or Georgia > Atlanta > Georgia Aquarium.
Exactly as I do. If you find that a better way to locate images outside of LR (which suggest you'd find it a better way to locate them inside LR), stick with that.
-
This gets back to the age old question of how to organize photos -- try to create a hierarchical folder structure by subject, or just throw them in one big folder (by date, say), and use keywords to find specific images.
For me, the main issue with creating the subject-based folders is what happens when an image or set of images can go into more than one folder. What do you do then? If I have, for example, a folder of Students and a folder of Professors, where do I put the photo of a professor and a student together? Create a new folder called Professors and Students? At some point the level of granularity starts to get ridiculous, especially when I can just have multiple keywords (professor, student) and the images will come up if I search "professor AND student" and also when I am just looking for either prof or student shots.
That said, there is nothing wrong with organizing your photos in any way that makes sense to you, as long as you can find them again. I would suggest using a robust set of keywords on each image, if only because they can get separated from their original folder structure. I use full captions, too, but most photographers think that's too much work.
-
If you can adequately categorise your photos with that geographical structure, that may be fine for you going forward. But as an ex-Aperture guy surely you'd be sympathetic to Peter's view (and mine - I tech edited his DAM book) that categorising your photos with folders is a very limited method. What I mean here is that we can categorise our photos in many ways, not just by geography. For instance, let's say you also shoot airplanes, so where do you put that photo of a Mustang with NY in the background - or is it really a picture of NY, with a little speck that happens to be a Mustang? Put it in the NY folder, or in another folder structure for aircraft? Then you have family pictures in the same location, so that might be another folder structure. THe one thing that is immutable and objective is the date.
In the long run you're better off avoiding trying to use your folder system to categorise your photos, and I'd recommend you simply adopt LR's date-based folders and put the effort into adding keywords, IPTC location fields and other metadata. Think too about our conversation here about Lightroom and Aperture's internal folder structure. Folders are for physical storage, not categorising.
There's no reason why you shouldn't leave the ex-Aperture structure as it is, and import new files in a LR date-based method. Or if you want a single folder system, you might reimport everything with the Move option and allow LR to create a date-based folder system. You would then use the IPTC location fields for slicing and dicing geographically.
-
At the risk of sounding like a salesperson for the Luminous landscape tutorial videos, I would suggest that Bob buys and views the "Where are my pictures" series. My own organization is by:
1-Camera (odd, but it works for my partner and my type of photography; helps with my workflow in developing Leica, Canon or Panasonic files).
2- Date -- so e.g: Leica / 2014 / 2014-01-31
3- Collections and Smart Collections based on projects and keywords, and those collect from any folder.
Keywording and Smart collections are a very powerful tool for organizing the images.
Jean-Michel
-
I really don't have any trouble deciding on which folder an image goes in. I know the answer to the question of where was I when I shot it. If I was in Newark, NJ when I took the picture of the Mustang, I'd save the image in the New Jersey > Newark folder. Even a folder structure using dates is categorizing the images by date; you can't use a folder structure and not categorize by something (unless you're good at random folder name generation).
After that, there are many ways to think about the image and those ways get keywords; perhaps Airplane, Mustang, and New York. Just as there is one date, there is one place. And since the EXIF data already has the date, putting the image in a folder-by-date structure seems like a duplication.
I see two possible problems with my structure:
- If I outgrow my hard drive (or SSD) space, then it might be hard to figure out where to cut off one drive and start on the other. With dates, it's obvious.
- If I end up with a lot of pictures in one place, that folder can get pretty full. But maybe Lightroom doesn't care, or slow down, if there are many files.
Are there other problems I'm missing? Or will one of those undo me in the end?
As Andrew mentioned, there may be some value in being able to find an image completely independently of whatever DAM software I may be using. Filing by location in the Finder could help with that.
-
Hi again,
LR does not care where the images live in order to see the preview images, and it does not slow down at all. The preview images live in a folder called "preview Lightroom 4 Catalog Previews.lrdata". And that lives in your main drive. The drive where the files are of course has to be connected in order to work on the images. if it is not connected you still see the preview and simply have to connect the drive with the files in order to do work on them. The previews do not take very much space: I have over 80,000 images,, and the preview folder is barely over one gigabytes.
Jean-Michel
-
The DAM book advice isn't really about dates - it's about using your folder system purely in terms of storage (hard drive space, backup, ease of restoration) and only using metadata and virtual containers (projects, collections etc) to categorise your pictures.
A date-based folder system isn't at all about categorising by dates but is simply using an immutable and objective way of dividing images between folders which you can then eyeball. Dates are not arbitrary like your using NJ, while others would use NY, and dates don't get redrawn like borders can (less so in the US).
You should certainly consider what to do without a DAM system. If you create geographical categories, you can find images easier outside a DAM system only if you are searching geographically, but that's less useful when you're looking for images by other criteria such as aircraft pictures, family etc. TBH You're always going to have some kind of DAM software, and even Finder searches.
And as you note, date-based folder systems scale better too.
-
This gets back to the age old question of how to organize photos -- try to create a hierarchical folder structure by subject, or just throw them in one big folder (by date, say), and use keywords to find specific images.
Throwing them in a big folder is a bad idea IMHO (I've heard Kelby recommend it, he's usually more interested in doing something super easy now, not thinking about the results later). As I said, the biggest reason I think having a well organized folder structure is to aid in finding my data outside any DAM, using just the Finder or Explorer. Doesn't hurt one bit inside either. Often I need to find an image without having to resort to even launching LR. And if I migrate from LR or something goes south, or they go subscription or I find a better product, I want a belt and suspenders approach so I don't get stuck. Proprietary solutions are less flexibile and why I rarely use dumb collections but do use Smart Collections which are based on metadata that lives within the data itself.
It doesn't matter a lick IMHO if you use dates, names, whatever, just as long as you can find the images. There are no rules in how to do this for images, your overall data stored on a computer or the paper file cabinets which store your records. It has to make sense to you (or someone else if they are doing the searching).
Folder dates are totally meaningless to me. A folder called "Dogs" or "Epson Print Academy" makes perfect sense to me and I suspect anyone else who might stumble on said folders.
For me, the main issue with creating the subject-based folders is what happens when an image or set of images can go into more than one folder. What do you do then?
Sub folders or use what the DAM does well; find by keywords, with smart collections (I rarely every have dumb collections), by file name (using Dogs in the file name along with putting them in the dog folder again provides me with additional means of finding images without having to resort to LR.
If I have, for example, a folder of Students and a folder of Professors, where do I put the photo of a professor and a student together? Create a new folder called Professors and Students?
It doesn't matter, just pick which method makes more sense to you and most importantly, consistently move forward with that process. For example, I have a folder called Epson print Academy. Within that are sub folders from each event, nearly a dozen. Each folder's name has the location of the event. If I click on the main Epson print Academy. folder in LR, I see all those images and if I only want to see the images from Atlanta, I can click on just that folder alone. Same if I'm searching outside of LR! If you put a gun to my head, I couldn't tell you the date of the Atlanta Print Academy but if I know I need an image from that event, I know easily how to find the folder (or do a search) for Atlanta, or Epson Print Academy Atlanta. If you find working with dates is better for you, use that. I don't.
You could have a folder called "School" and two sub folders called Students and Professors. Or one of just each: Student and Professors and divde up via keywords. Your call. With the main "School" folder, you could select that root within LR and see both groups OR select just the one folder to see only those Professor images. You could also have a keyword for each which I think is a very good idea. Or you could build a Smart Collection (Name contains Professor).
At some point the level of granularity starts to get ridiculous, especially when I can just have multiple keywords (professor, student) and the images will come up if I search "professor AND student" and also when I am just looking for either prof or student shots.
The search could contain one but not the other. But again, with separate folders for each, pretty easy to find one versus the other or both.
The bottom line in this disucssion is, what to name the folders indicating that you'll attempt to find images using that process alone (otherwise, if you're in LR, use can use keywords or smart collections or search by file name etc). As such, sorting by date is easy despite any name you give to the folder. The folder name just allows you to drill down outside the DAM.
Further, there's a really neat file naming template in LR that builds upon the folder name! Genius for my approach. The image name should match the folder name in part. I have a folder named "Dogs" guess what kind of images you'll find inside? Example of a filename is: Dogs_10June12_018-2.dng. First part of the name tells me what the subject is based on the folder (which is based on the subject), plus there's a date! If I move images from one folder to the other for whatever reason, the template will quickly rename the images based on that folder. Student and Professor are somehow mixed up. Or you import a dozen images of Professors into the Student folder. Move offending images into correct folder from with in LR, use the template, boom, the file name is now fixed with a single command. You want to search for students outside of LR? You can navigate to the folder you yourself built and named Student. You could use the 'Find' command or Spotlight outside LR and find them via the name (it contains Student).
That said, there is nothing wrong with organizing your photos in any way that makes sense to you, as long as you can find them again. I would suggest using a robust set of keywords on each image, if only because they can get separated from their original folder structure. I use full captions, too, but most photographers think that's too much work.
Exactly! The idea that you're better off avoiding trying to use your folder system to categorise your photos doesn't wash for some of us. There's no reason I can think of for not naming folders that give me a clue what's inside! The use of a folder system to categorize means you are not depending on the DAM to find your images or other files. In my experience with the way I work, it's actually quite critical. But again, there are no right answers or methods if they cause you difficulty finding what you're looking for. Anyone who tells you it's wrong probably doesn't think the same way you do. And not thinking the same way make finding your stuff, be it images, a receipt for your accountant or a text file you wrote 10 years ago difficult and frustrating.
-
The only reason to have a well organized folder structure is to be able to find data outside your DAM as Andrew suggest. Other than that, I find it much superior to use the DAM capabilities with metadata. I find the folder structure very limiting, especially when an image can belong to different groups such as the example of the airplane in NY mentioned earlier.
-
The only reason to have a well organized folder structure is to be able to find data outside your DAM as Andrew suggest. Other than that, I find it much superior to use the DAM capabilities with metadata. I find the folder structure very limiting, especially when an image can belong to different groups such as the example of the airplane in NY mentioned earlier.
No argument (the later part about the DAM being better overall). I'll add, you have to name the folders in any case. Might as well name them to aid in finding your images outside the DAM. If you find this to be true, then the mimic of the folders seen in LR will aid you too. Putting all images into one folder then expecting to find them later is again, a really bad idea IMHO. Putting them into two is only slightly better. So you have to ask yourself, how much effort do you want to go through to name folders and organize them alone, all the other work within the DAM still should be done (keywords, smart collections etc).
-
Folders, and folder structure have a place within DAM, however folders should never be the prime organisational approach.
For one, most images cannot sit simply in a single folder as a means of categorisation because they could, and should, be categorised in several different ways. Duplication of image files to sit in several folders is a big, big no-no in DAM.
(For what it is worth I have a date-based folder system - it scales well as John Beardsworth has mentioned - but I also add locational information as part of the folder name and filenames of image files that belong in that folder. That way I can tell if an image has been misplaced. Location only makes sense for me because I am an outdoor photographer and wouldn't apply for other genres necessarily.)
Keywording and metadata acquisition are really the only ways to adequately organise one's images. Once this is done images can be searched for in multiple ways and categorised in multiple ways. In Lightroom a single image may end up as part of the population of many Smart collections.
For those who need more flexibility with metadata and keywording both John Beardsworth and Jeffrey Friedl have plug-ins that can allow access to metadata that Lightroom doesn't as well as interesting ways to organise images that Lightroom does not currently provide.
In summary, a scalable folder system is an indispensable first step in DAM, but the road is along one never completed in a single step.
Tony Jay
-
The only reason to have a well organized folder structure is to be able to find data outside your DAM as Andrew suggest. Other than that, I find it much superior to use the DAM capabilities with metadata. I find the folder structure very limiting, especially when an image can belong to different groups such as the example of the airplane in NY mentioned earlier.
The reason why dates is the most sensible and easiest way to organise your file location is that when it comes to organising an image can only go in one possible date folder with no thinking needed, which is always handy when organising file location. Particularly as all pictures can be imported into LR by date in the universally useful yyyy-mm-dd format.
Note I use the term location here in the sense of where images are on your hard drive, they have to be somewhere, so why not do it in a way that is actually useful/usable via Explorer/Finder/other programmes or OSs. This I would call your Primary organisation as it's the first step in your cataloguing.
I do also add a description to the date and may subdivide a long day's shoot into several folders all with same date but with different descriptions to separates different subjects, for example...
2014-August
2014-08-18 Dogs
2014-08-18 Cats
2014-08-18 Goats
or if two subjects were photographed together it may be
2014-August
2014-08-18 Dogs + Cats
2014-08-18 Goats
Now if you use any other kind of organisation such as subject/places as your primary folder organising then it all gets a bit vague and messy as to where you put things as sometimes it is not clear cut how you can file an image as you may have a photo with both a cat and a dog in it. Using subject for your primary organisation is not really workable. But if you organise location by date, you can then add all the other types of organisation via metadata. So you can have secondary organisation with smart [preferable] or dumb collections that handle say dogs, cats or locations etc and unlike physical folders a picture of a dog and a cat can be in both 'Dogs' and 'Cats' collections.
Your Secondary Organisation is in fact your main way of finding things, but if you organise by date description then the description can also be the first stage of your secondary organising by metadata. This means you can organise basic stuff really easily and smart collections can find 'dogs' in folders with 'dog' in the folder name even if the files in folder are not named or have keywords like 'dog' added. So by adding a description to the dated folders LR can import images into, you've already done a huge amount of basic organising.
-
Folders, and folder structure have a place within DAM, however folders should never be the prime organisational approach.
Absolutely! But I think the discussion here is, name them and structure them so they provide as much useful functionality outside the DAM or far less so. I can’t think of a single reason not to use the name to aid you outside the DAM, once you come up with a system that works for you.
Keywording and metadata acquisition are really the only ways to adequately organise one's images. Once this is done images can be searched for in multiple ways and categorised in multiple ways. In Lightroom a single image may end up as part of the population of many Smart collections.
Absolutely! The OP's question appears to me to ask about folder naming, not using folders solely to find your images.
-
No argument (the later part about the DAM being better overall). I'll add, you have to name the folders in any case. Might as well name them to aid in finding your images outside the DAM. If you find this to be true, then the mimic of the folders seen in LR will aid you too. Putting all images into one folder then expecting to find them later is again, a really bad idea IMHO. Putting them into two is only slightly better. So you have to ask yourself, how much effort do you want to go through to name folders and organize them alone, all the other work within the DAM still should be done (keywords, smart collections etc).
Agreed, I was not suggesting to have just one big folder. For me the folder structure is the "Physical" layer of data storage, so I organise using criteria as disk performance, backup strategy, etc. For instance, recent images go to a SSD or high speed Raid and after editing and heavy use move the folders to a less expensive / high volume storage. Depending on your backup strategy you may set limits on the size of folders and so on.
All information related to image content goes as metadata in the DAM, which would be the "logical" layer.
In the end, the most important aspect of any storage system is to be able to find what you search for, so use the strategy that works best for you.
Regards,
-
Keywording and metadata acquisition are really the only ways to adequately organise one's images.
Not necessarily. I have done documentary work over long periods of time, one project which was 13 weeks over 4 separate years and dates are the easiest way for me to find a lot of stuff in that huge collection of images. The reason being many events happened on a weekly basis and because it was all carefully organised by date/description, it helped me to focus on that organisation and thus remember it. Also I started that project before LR even existed.
Now with metadata added to that carefully organised collection, then I can look for stuff in two different ways.
The 2 big problems that metadata organising evangelists tend to ignore is that it takes an awful lot of work and time to do properly and also the huge amount of useless cruft you sometimes get from basic metadata searches with loads of unwanted stuff appearing. I'll use email as an example as it's easier to demonstrate.
I want to search for emails from Mark, but what tends to happen is that any mail that contains the letters 'mark' or has been sent to a Mark will appear, so then you have to recall Mark's surname which can be tricky at times as with some people you do not use their full name often or may not even have it in your contacts and his email address may be something random like aarvard323@host.com. The other issue I notice is that data I know contains the keywords or text that I am searching for does not appear in the smart collection/playlist/search. Spotlight in OSX is particularly bad this way.
My music for DJing is organised almost entirely by smart playlists from keywords with the odd exception of shortlists for the evening or the mix I'm making. So much easier than organising physical media. ;D
But the actual files are still organised alphabetically on the hard drives as again they have to go somewhere and at least it is in a way that makes sense and is still usable if something happens to my smart playlists.
-
Folders, and folder structure have a place within DAM, however folders should never be the prime organisational approach.
For one, most images cannot sit simply in a single folder as a means of categorisation because they could, and should, be categorised in several different ways. Duplication of image files to sit in several folders is a big, big no-no in DAM.
Our posts overlapped where we both used the term Primary Organisation and I think folders should be that. But in the sense of primary=first, not primary=most important.
But then when I want to look through recent stuff, particularly personal photos skipping back through recent folders with date-description is such an very easy way to do that.
Not to mention that browsing through date/description folders is a great way of noticing stuff you hadn't been specifically looking for - the usefulness of which cannot be overlooked. Metadata tends to be better at finding exactly what you are after [if you make the search criteria specific enough].
-
Some great discussions here - in fact a whole course of the ins and outs of DAM! So I'll through my 2 cents worth in...
As one who developed my original catalogue 12 years ago while travelling overseas, I have found it infinitely valuable to dump all uploads into a limited hierarchical catalogue like this:
YYYY
> YYYYMMDD-TT-ShortLocationDescriptiveTitle
The TT is for AM or PM and is only used if necessary (e.g. If there is a major change in location from am to pm.
The "ShortLocationDescriptiveTitle" is to help me remember, as I, too, don't remember what I had for breakfast most days.
The point of this is simplicity, repeatability and consistency. There is also an element of legacy and longevity here as (hopefully) dates never end, although I will someday. It is also a great "log" of time and place.
Of course, this is all backed up by both keywords (essential, so that my series of images of "horses" in a "Montana" "landscape" with "scenery" of "snow-capped" "mountains" in "summer" with "field" "wildflowers" and "forests" isn't hidden behind a folder name.
As well, Categories come into play using these same keywords and ****s.
This may look complicated at first, but it very quickly becomes second nature allowing me to find groups of images from a specific trip location and date or via keywords all set within the context of my life history.
Hope this helps.
-
Throwing them in a big folder is a bad idea IMHO (I've heard Kelby recommend it, he's usually more interested in doing something super easy now, not thinking about the results later).
Sorry, I didn't write this clearly. I was thinking about the folder structure as a container, with a 2014 folder that contained date-based sub folders. So that was my "one big folder," but it's not just one folder.
I put each assignment in a separate folder with the date shot and a brief descriptive folder name: 0807 headshots, or 0805 joe blow portrait, or 0910 football vs ESU. These are in the 2014 folder, so they sort chronologically and alphabetically at the same time.
You then go on to answer all the hypothetical questions that I posed to the O.P. I already knew the answers, at least for my uses, but I expect some folks will find this very useful. :)
-
This got a little off course. I don't think anyone is suggesting "one big folder" to hold all the images. And there is only one place I was when I took the picture - it too is "immutable and objective" - unless borders are redrawn and I'm will to take my chance with that. I was in NJ for the Mustang shot, not NY, even though NY was a subject of the image.
And no one is suggesting that the folder structure be the only way to find an image. A robust metadata (tags and keywords) system is assumed.
The folder structure may simply be the first level of organization, with metadata providing many more levels and layers. I think I'm sticking with Andrew here, it makes very good sense to me to use folders that are places.
From there we got into a number of different hybrid folder naming structures: YYYYMMDD-TT-ShortLocationDescriptiveTitle, 2014-08-18 Dogs, Leica/2014/2014-01-31 and so on. If it's "bad" to categorize with folders, then these approaches are certainly "bad" as well.
For those who use a strict date-base folder hierarchy, how do you work with the files on initial import? It seems that you must have to assign some keywords, or something, right away so that the group doesn't end up spread out over a number of different day folders. I know Lightroom gives you the previous import collection by default, which is good, but very short lived.
I do also add a description to the date and may subdivide a long day's shoot into several folders all with same date but with different descriptions to separates different subjects, for example...
2014-August
2014-08-18 Dogs
2014-08-18 Cats
2014-08-18 Goats
jjj, if you take a picture on 2014-08-18 with a dog and a cat in it, which folder do you put it in?
-
This got a little off course. I don't think anyone is suggesting "one big folder" to hold all the images
No one here, that's ridiculous. It was proposed in the past by Scott Kelby. Not sure if he's changed his mind on that, I typically ignore him :-*
And no one is suggesting that the folder structure be the only way to find an image. A robust metadata (tags and keywords) system is assumed.
Yes, I think we are all in agreement in that respect.
For me, I don't see a reason not to name and organize folders and subfolders as best I can for finding items outside the DAM. It isn't a perfect system, certainly alone as others have outlined areas where it could be confusing in some context. That's where metadata and a good DAM can greatly aid further in finding your images. What I don't agree with is the idea that in the long run you're better off avoiding trying to use your folder system to categorise your photos. Fully yes, that's dumb. As part of the organization system, no, it's quite helpful to me, I can't speak for others. As I said, anything but a descriptive name would just confuse me, dates are meaningless to me. But that's just me.
-
You can think of folders as metadata at OS / disk level.
For me the main difference is:
Folder structure > mono-dimensional
Tags & metadata > Multi-dimensional
The fact that you can add metadata at any time allows you to reorganise your collections / selections in the future by a criteria that you didn't think of before.
Any descriptive name you were going to use for your folder structure can be used as keyword tags.
I envision a scenario where the physical organization of the "Digital Assets" is independent of content such as data in enterprise data bases. This is a long journey from where we are.
-
Just a couple Aperture/Mac comments here....
I dump my originals straight from camera to a folder called "NewPictures"
Immediately after I run a script to rename them yyyy-mm-dd-hour-minute-second[sequence]
I then import these to Aperture, and move the previously renamed files to a year-based folder structure (1997, 1998,...2014). I'll create a new 2015 folder when we enter 2015.
This works great for me...but the "problem" is that if I'm not in Aperture, it's impossible to find pictures that I've tagged with keywords, GPS, ratings, flags, etc. One of my longstanding gripes with Aperture is that all the metadata that you add to a picture is locked in the Library or some type of sidecar file. (The same is true of other apps).
IMO, attempting to use folders for any type of organization other than date or location is flawed, because a single image can only live in one folder. It's a hugely limiting constraint on being able to access images that may share numerous properties, or may have an ambiguous organizational property.
Recently I've been experimenting with burning the metadata back into the originals using the Export Originals command...which then writes (some of) the metadata to IPTC fields. One great advantage of this approach is that with the metadata written to the file, the metadata is now searchable using Spotlight, which solves the problem of not being able to find images outside of the DAM software.
However, it's an incomplete solution, because there is a lot of metadata that doesn't necessarily map into IPTC fields. For example, it doesn't appear that I can burn GPS coords (at least from Aperture).
This also presents a bit of a workflow challenge, since it requires importing the images, tagging them, then reimporting the images with the IPTC.
I've experimented with exiftool, which can definitely add the metadata, but the problem with this approach is that there is no UI for assigning metadata. I could create a bunch of scripts that could be run sequentially on images to add individual tags...but this would require a bunch of work up front to create all the scripts and would also be very tedious to apply them all.
From what I can gather, it *appears* that Apple may be trying to solve this issue (exposing metadata to the Finder and other applications) with the new Photos app. If this is true I think it solves a huge issue that all DAM software presents: essentially locking all the "value" you add to your photos within a black box. Of course each computing platform is it's own black box...but that's another story.
Ultimately, while a dedicated DAM certainly has it's advantages, the "lock in" and accessibility problems these tools imbue is frustrating and substantial. Like the OP, I am surveying the field of alternatives because Aperture will eventually cease to be a usable solution...and it doesn't have all the latest lens correction, noise reduction, etc features.
It's interesting (to me) that the quality of the RAW rendering engine and the image manipulation tools--while certainly very important--have taken a back seat to considerations of DAM portability and DAM lock-in. I've spent substantial time and effort making all my images searchable--and this provides incredible value when working with tens of thousands images. Finding a solution that enables me to preserve and access these data outside the context of a vendor-specific solution is hugely important, and I'm not about to trade one "black box" for another (Lr, C1, etc).
thx--
PP
-
I don't know about Aperture, but in the case of LR the catalog is just a relational database that can be read easily by a wide variety of applications. Maybe here is an opportunity to consider for developing an user friendly application.
What I fail to understand is why would you like to search an image out of the DAM if you have the DAM in the first place? Does it take a long time to load your DAM? I'd think that it would take less time to load the DAM than doing a primitive search through a folder structure.
An additional comment for those that like to organise their images by location and your camera does not have a GPS: in case you didn't know, if you have a smartphone you can register a tracklog (there are several free apps like those used to track your workout) and then load into LR (map module) and it will assign the coordinates to each image based on capture time. It will even interpolate locations if you had periods without GPS signal. You can also adjust the offset time between your camera and phone.
Regards
-
You can think of folders as metadata at OS / disk level.
For me the main difference is:
Folder structure > mono-dimensional
Tags & metadata > Multi-dimensional
The fact that you can add metadata at any time allows you to reorganise your collections / selections in the future by a criteria that you didn't think of before.
Any descriptive name you were going to use for your folder structure can be used as keyword tags.
I envision a scenario where the physical organization of the "Digital Assets" is independent of content such as data in enterprise data bases. This is a long journey from where we are.
Very well said.
>>I envision a scenario where the physical organization of the "Digital Assets" is independent of content such as data in enterprise data bases. This is a long journey from where we are.
Most DAM software already provide this to varying degrees: for example, as many point out, the physical location of the image is deemphasized in Aperture (love it or hate it).
>>What I fail to understand is why would you like to search an image out of the DAM if you have the DAM in the first place? Does it take a long time to load your DAM? I'd think that it would take less time to load the DAM than doing a primitive search through a folder structure.
What if you want to access your images on a device that your DAM doesn't run on? You mentioned enterprise DB's above: Most folks that use and interact with these systems will tell you that data tends to become "silo'd" in these systems (due to a number of factors). Data certainly has an intrinsic value, but inaccessible data is virtually worthless.
IMO, the real issue that needs to be solved is abstracting the user interface required to get/set the data from the data itself. This isn't a huge problem to solve--since it's been solved for many other types of data--but it certainly presents unique challenges for digital photographs (multiple different file formats, closed or non-public file formats, etc). Most modern file systems support some form of (or some degree of) arbitrary metadata...and Windows and Mac OS provide the means to index and search these data. There is a clear case to be made that adding metadata may require specific applications and specific user interfaces...but why do we need specific applications to access it? (Just to be clear, I'm not arguing that a CR2 file should be renderable "anywhere;" I'm arguing that the metadata describing the contents of these files should be accessible anywhere).
The move to the cloud will only highlight these problems.
PP
-
What I fail to understand is why would you like to search an image out of the DAM if you have the DAM in the first place?
Some of us are unfortunate enough that our DAM of choice, Aperture, is being discontinued. And we don't know how much of Aperture's metadata will migrate to Photos.
Maybe, one day in the future, there will be no more Lightroom, either.
-
Some of us are unfortunate enough that our DAM of choice, Aperture, is being discontinued. And we don't know how much of Aperture's metadata will migrate to Photos.
Maybe, one day in the future, there will be no more Lightroom, either.
Exactly. Or one may wish to migrate to another DAM. Or someone else might need to find an image outside the current DAM. It's like backing up to multiple drives, it's a belt and suspenders approach. And as I stated, I've often found images I'm looking from directly from the finder within a folder I've clearly named faster than launching LR and looking from there. I can see no justification for not using a well organized folder structure and naming for anything I store on a computer when I am comfortable doing said organization. If someone wants to use a different method and it works well for them, so be it. This gets back to the root of the OP's question about organizing and following the recommendations of one fine book. You don't have to follow it to the letter.
-
http://scottkelby.com/2009/10-things-i-would-tell-new-lightroom-users/
(2) Use Collections instead of Folders
Folders are where the actual photos you imported from a particular shoot are stored. Your good photos from that shoot, bad photos—the whole ball of wax. But once we import photos, are most of us really care about are the good ones, and that’s why Collections were invented (well, it’s one of the reasons anyway). Matt and I always joke that “Folders are where we go when we want to see the shots that weren’t any good” because we put all our “keepers” in a collection right away. Collections are safe, and will keep most users out of trouble.
(3) Store all your photos inside one main folder
You can have as many sub-folders inside that one main folder as you want, but if you want to have peace, calm, and order in your Lightroom, the key is not to import photos from all over your computer. Choose one main folder (like your Pictures folder on a Mac, or your My Pictures folder on a Windows PC), and put all your photos inside that folder. THEN import them into Lightroom (and if you’re importing from a memory card, have those images copied from the card info a folder within your main folder). Plus, this makes backing up your image library a breeze. Every time I run into someone who’s Lightroom life is a mess, it’s because they didn’t follow this one simple rule. Also, if you’re working on a laptop, it’s totally fine to store your photos on an external drive, rather than on your laptop.
Imagine migrating from proprietary collections to another DAM with such a setup.
-
Some of us are unfortunate enough that our DAM of choice, Aperture, is being discontinued. And we don't know how much of Aperture's metadata will migrate to Photos.
Maybe, one day in the future, there will be no more Lightroom, either.
I moved from iMatch to LR. Doing data migration from one system to the other is notthat of a problem if you know the data structuring. It is a mapping excercise. Also data migration best practices show that you will never get all data across without some manual intervention or cleanup. Key is you have to know and decide on how to deploy the structuring concepts of thesystem you move to.
-
http://scottkelby.com/2009/10-things-i-would-tell-new-lightroom-users/
Imagine migrating from proprietary collections to another DAM with such a setup.
I wonder if Kelby meant to put a hierarchy of folders inside a main, photo, folder rather than loose image files all in a single crowed folder? I have my hierarchy of location folders inside a single folder named "Lightroom Library."
-
For those who use a strict date-base folder hierarchy, how do you work with the files on initial import?
- create a new folder with the OS
- use a script to rename image files in the OS
prefix (date the new folder was created) - suffix (sequence number within the folder)
20140809-001.ARW
20140809-002.ARW
No thinking about categorization required before getting to work on the images.
-
- create a new folder with the OS
- use a script to rename image files in the OS
prefix (date the new folder was created) - suffix (sequence number within the folder)
20140809-001.ARW
20140809-002.ARW
No thinking about categorization required before getting to work on the images.
Isaac,
OK, so that leaves you with a bunch of renamed images in the initial folder all ready for editing and adjustments. From there, how do you get them all distributed into the folder-by-date structure? Drag and drop?
-
OK, so that leaves you with a bunch of renamed images in the initial folder all ready for editing and adjustments. From there, how do you get them all distributed into the folder-by-date structure? Drag and drop?
This is overthinking the issue. You just use LR's import dialog to rename files and distribute them to folders.
-
This is overthinking the issue. You just use LR's import dialog to rename files and distribute them to folders.
Oh, OK! I get it! The first folder is not known by Lightroom at all. Lightroom then imports from it.
At that point the new group of files is in the folder-by-date hierarchy. That's the end point desired. How do you work with the files in Lightroom scattered around like that? Lightroom creates the previous import catalog collection, so you can work from that. But if you haven't finished that work before the next import, how do you manage that?
I import a group of files into an •import folder and work on them there adding keywords, deleting duds, and making adjustments. If I import more before I'm done with those, they just stack on and can be sorted by date.
Once I'm done, I drag-and-drop the finished files into my folder-by-location hierarchy.
-
Think back to our conversation about Aperture's managed folder system which you said was actually date-based. Did you need to know that to work with your pictures? Clearly not, because you used Aperture's virtual folders and metadata, and it's the same here. If anything, you'd tend to use metadata fields more in Lightroom - for instance, the four iptc location fields would cover your geographical folder structure. I don't see any great virtue in your last drag and drop step, but if that's what you want to do....
One feature I really dislike is the Previous Import, and for the reason you offer.. It's less of a problem now I use 32 gb cards and might only need to import once after a shoot, but with my old 4 gb ones it's a pain. Instead I have smart collections such as shot within the last x days, and I save some of these as "Favourite Sources" - that's in Filmstrip at the bottom left where you see most recent locations.
-
Maybe look up my workflow smart collections?
-
I use hierarchical folders by day, e.g.,
2014
2014/2014-07-31
and handle this setup in the Import dialog via an Import preset. (I don't touch those settings normally.)
-
This got a little off course. I don't think anyone is suggesting "one big folder" to hold all the images. And there is only one place I was when I took the picture - it too is "immutable and objective" - unless borders are redrawn and I'm will to take my chance with that. I was in NJ for the Mustang shot, not NY, even though NY was a subject of the image.
And no one is suggesting that the folder structure be the only way to find an image. A robust metadata (tags and keywords) system is assumed.
Never assume anything! :P
The folder structure may simply be the first level of organization, with metadata providing many more levels and layers. I think I'm sticking with Andrew here, it makes very good sense to me to use folders that are places.
Terrible idea to use subject as basic physical organisation. One of the many reasons why it isn't a good idea is that you may end up with 10s of thousands of pictures in one folder.
From there we got into a number of different hybrid folder naming structures: YYYYMMDD-TT-ShortLocationDescriptiveTitle, 2014-08-18 Dogs, Leica/2014/2014-01-31 and so on. If it's "bad" to categorize with folders, then these approaches are certainly "bad" as well.
Not at all, you are not categorising your shots just because you stick then in date folders with a description. You are simply storing them in a sensible way. The date-description approach is good as it's very easy and works in any OS/programme and makes sense to any human. I do not see any downsides to using it. Folder sorting by camera such as Leica though is pointless.
For those who use a strict date-base folder hierarchy, how do you work with the files on initial import? It seems that you must have to assign some keywords, or something, right away so that the group doesn't end up spread out over a number of different day folders. I know Lightroom gives you the previous import collection by default, which is good, but very short lived.
I simply import into date folders and do the detailed stuff afterwards. On occasions where the subject matter of the import is the same, I may add some keywords then. But if importing from say my phone then it may be a week's worth of pics, so I import and label the folder with the day's shots in. And may even subdivide the days if there are lots of different subjects. As I said above this makes casually browsing through one's photos very easy.
jjj, if you take a picture on 2014-08-18 with a dog and a cat in it, which folder do you put it in?
I explained that in same post. 2014-08-18 Cat + Dog, the description is simply what's in the folder on that day. It is not how I organise pictures of cats or dogs. I could easily have done 2014-08-18 Cats, Dogs and Goats, but if the subjects are completely separate then why not place in separate folders if you have lots of each. If I only had 15 animal shots in total then 2014-08-18 Cats, Dogs and Goats would be fine if I had hundreds of shots of each animal that day then separate folders makes more sense. The whole point of any organisation is to whittle down and find what you are looking for. Large folders with thousands of images don't help with that.
-
I moved from iMatch to LR. Doing data migration from one system to the other is notthat of a problem if you know the data structuring. It is a mapping excercise. Also data migration best practices show that you will never get all data across without some manual intervention or cleanup. Key is you have to know and decide on how to deploy the structuring concepts of thesystem you move to.
Folders ordered by date/description do not need any migrating or mapping as they just work and is the main reason I use it. The metadata is also there too for metadata organising, so dead easy.
-
Oh, OK! I get it! The first folder is not known by Lightroom at all. Lightroom then imports from it.
At that point the new group of files is in the folder-by-date hierarchy. That's the end point desired. How do you work with the files in Lightroom scattered around like that? Lightroom creates the previous import catalog collection, so you can work from that. But if you haven't finished that work before the next import, how do you manage that?
I import a group of files into an •import folder and work on them there adding keywords, deleting duds, and making adjustments. If I import more before I'm done with those, they just stack on and can be sorted by date.
Once I'm done, I drag-and-drop the finished files into my folder-by-location hierarchy.
Still overthinking. :)
Import by date, you can rename files at same time if your subject is all one thing. Once in LR add description to each folder and you're done with physical folders. Unless you want more than one folder per day for multiple subjects - entirely optional but remember this is adding metadata organising at same time, folder names are metadata too.
Use smart collections then to organise your work by locations, animal or whatever.
The reason why dates for folders is preferable is that there is no ambiguity. That's the day the photos were taken, add description and thats it, job done. Add metadata to taste and get developing.
With folders sorting by subject it all gets messy.
Take locations - I go to Swansea take some photos and place them in a folder called Swansea. I then return to Swansea because I decided that I really liked it there and then do a series of images of Mumbles, another visit and I do shots in the Grand Theatre, another visit was of mountain bikers on Kilvay Hill.Return once more and shoot a different part of the Mumbles. Now where do these shots go? Swansea seemed fine for a single visit, but then repeat visits make it the locations more complex and you may go from a few dozen shots of Swansea to many thousands. so you may have to rejig what's in the original Swansea folder as say for example were taken around the docks. Manually moving files around as your subject locations get more granular is a pointless waste of time.
So rather than just Swansea, folders may now be
Swansea
-City Centre
-Grand Theatre
-Exteriors
-Interiors
-Oxford Street
-Swansea Market
- Docks
-West Dock
-King's Dock
-Kilvay Hill
-Mumbles
-Mumbles Castle
-Mumbles Seafront
A dog folder can get just as bad. You shoot a some dogs, they get added to dog folder. People like your dog shots you do some more and add them to dog folder then you get a name for being a dog photographer and that's your business. Can't keep all those doggie pics in one folder.
Now if you organise location or dogs by smart collections this can grow/become more complex as you go along and images automatically get added to smart collections even if all you did was add a description such as Mumbles Castle/Labrador Puppy to the folder description. Do this with actual physical folders and you are simply digging a hole for yourself.
-
I guess I'm still confused.
Say I import a group of images taken over several days. During the import step I let Lightroom put each image in the correct folders-by-date folder. Good.
Now I'm ready to edit and adjust those images. As long as they're still in the recent import collection I'm good.
But what do you guys do if you haven't yet finished editing and adjusting that set of imported images and have another set to import? How do you get back to the first set of imported images so that you can finish editing and adjusting them? They're all over in various folders now.
-
A dog folder can get just as bad. You shoot a some dogs, they get added to dog folder. People like your dog shots you do some more and add them to dog folder then you get a name for being a dog photographer and that's your business. Can't keep all those doggie pics in one folder. Now if you organise location or dogs by smart collections this can grow/become more complex as you go along and images automatically get added to smart collections even if all you did was add a description such as Mumbles Castle/Labrador Puppy to the folder description. Do this with actual physical folders and you are simply digging a hole for yourself.
I think you're taking the folder structure idea too literally. There needs to be a balance between one folder where all images go as proposed by Kelby (and yes, I think that's what he proposes and the majority of his audience will read it that way) and hundreds or thousands of folders. And it doesn't matter as long as it makes sense to you. One could create hundreds of folders and subfolders to the point it would confuse them which means, too many folders. Let's take your example above in my usage of folders which is unique solely to me. I have thousands of photo's of dogs, most mine over the years. They are all keyworded with the dog's names. In fact I have a smart collection that does nothing more than to find images without keywords, that's important data to apply to the images. I have a folder called Santa Fe which is based on that location. I have dogs shot in Santa Fe but they don't go into that folder because IF I were looking for dog images outside the DAM, I know that's where I'd search for them (the Dog folder). It isn't necessary to have Dogs shot in Santa Fe in both folders even with an alias. I know that if I want to find dogs, they are in the dog folder. If you take the folder creation too literally such it confuses you where to look outside the DAM, the organization system is broken, it's too complex.
There is a reason we have keywords, pick flags, star ratings and all kinds of other metadata fields we can use to find images inside the DAM. The idea of using folders is to avoid the one folder for all images but at the same time, avoid so many folders it is a nightmare to understand. All one needs to do is come up with a system that makes sense to them. My folder structure makes perfect sense to me, I could have a Dog plus Santa Fe plus dog name keyword all in one image, I don't have to duplicate anything like that for the folder structure.
An organized folder structure isn't supposed to be a foolproof DAM bypass. It's supposed to be a method whereby if you have to find images outside the DAM, it's easier than one big folder with all images. Or three (Person/Place/Thing). But it isn't a system for finding any and all images solely by virtue of the folder name. If you have 1000 dog images in the dog folder and get a cat, nothing stops you from either creating a Cat subfolder OR just renaming the folder Dog and Cat. But you'd be pretty sure the new cat images were not in the folder called Sydney or Epson Print Academy or even Santa Fe. And that alone is kind of useful. At least to me.
In the end, one folder, 59 folders, 5890 folders, it's up to you. If it makes sense, if you can find your images, doesn't matter.
-
So rather than just Swansea, folders may now be
Swansea
-City Centre
-Grand Theatre
-Exteriors
-Interiors
-Oxford Street
-Swansea Market
- Docks
-West Dock
-King's Dock
-Kilvay Hill
-Mumbles
-Mumbles Castle
-Mumbles Seafront
Or just use those as keywords, stick with one folder called Swansea. Or both. Whatever works for you.
-
Or just use those as keywords, stick with one folder called Swansea. Or both. Whatever works for you.
That's what I do. One big Swansea folder with images having either keywords and/or the IPTC location field to differentiate them. If I shot a dog picture there, I'd have an image with a dog keyword.
Works for me.
-
That's what I do. One big Swansea folder with images having either keywords and/or the IPTC location field to differentiate them. If I shot a dog picture there, I'd have an image with a dog keyword.
Works for me.
Me too. I think you're on the right track. But hearing how others work is useful, much like reading Peter's book. Think about how you and others might organizes your paper files. Some might have one big folder called "Household" while other's may have folders called Utilities, while other's still would have Water, Electricity, Garbage collection and so on separated or in a larger folder called Household. There's no right answer for everyone. I'd be hard pressed to suggest every piece of paper you have to file goes into a single folder called Paperwork. But heck, you could do that. And I think having a separate folder for each month for the electric bill is overkill but heck, if it works for you, why not.
-
Now I'm ready to edit and adjust those images. As long as they're still in the recent import collection I'm good.
But what do you guys do if you haven't yet finished editing and adjusting that set of imported images and have another set to import? How do you get back to the first set of imported images so that you can finish editing and adjusting them? They're all over in various folders now.
The recent import collection is useless if you import more pictures, which happens. But these new pictures aren't scattered into various folders. They're in a few dated folders which would be neighbours, or they could be tracked by a smart collection listing images shot in the last x days or are in my current work collection.
-
Recent Import would be more useful if it had a history. But it isn't useless otherwise, I use it all the time.
If I have to import a lot of data, what I do is copy all images from all the cards to the folder I want and then conduct a single Import. It's faster, it keeps the Recent Import tacking all those images.
-
The recent import collection is useless if you import more pictures, which happens. But these new pictures aren't scattered into various folders. They're in a few dated folders which would be neighbours, or they could be tracked by a smart collection listing images shot in the last x days or are in my current work collection.
True enough, but they could be mixed in those adjacent folders with previously imported pictures that happen to have been taken on the same day.
A work collection is a good idea. Just drag from the recent import collection to the work collection before importing more images. But then you're stuck working in a collection for image editing; it's such a pain to delete a file from the disk when you're working in a collection.
-
There is no need to complicate things. Lightroom keeps things easily organized, and the same structure can be used with a program such as Bridge. For example:
I keep my job and personal files separate, so when I import images made for a Job, they get imported (using a preset for ease of use) into a particular Drive and into a particular Client folder; within the Client folder there usually is a particular Job title folder, the import then creates a "yyyy_mm_dd" folder inside. Having created the structure inside LR, it can be used in Bridge or the Finder. I can also include non-image files (InDesign , Word, etc, that pertain to the 'ABC job' folder, those will not show up un LR but will in Bridge or Finder. the Best of all worlds. It looks something like this:
Job Drive
--Acme Co
----ABC job
-----2014-08-09
For my personal work, it goes:
Image Drive
--Leica downloads
----2014
-----2014-08-09
Should there be both job and personal images on a card, it simply means checking and importing one set, say to my Leica or Canon folders; and then importing the job images; LR can be set not to import images that were already imported.
Renaming files to something like: '2014_08_09_location_project_001' or such is also useful.
Keywording is really the key for retrieving all your "baby blue" 'chevy" images regardless of the multiple Drives or Folders they might be saved in.
As I mentioned in my earlier post, get a copy of the Where are my files tutorial; Seth Resnick's explanations are much more detailed and better than mine.
Jean-Michel
-
I guess I'm still confused.
Say I import a group of images taken over several days. During the import step I let Lightroom put each image in the correct folders-by-date folder. Good.
Now I'm ready to edit and adjust those images. As long as they're still in the recent import collection I'm good.
But what do you guys do if you haven't yet finished editing and adjusting that set of imported images and have another set to import? How do you get back to the first set of imported images so that you can finish editing and adjusting them? They're all over in various folders now.
No they are in tidy, dated folders. Which can be easily found as they are....dated. :) Look in your Folder panel [left hand side in Library module] where all your folders that have been imported can be found. Any hard drives greyed out are not currently connected, but if you have generated 'smart previews' you will still be able to work on them even though they are offline.
Each year in Finder or Explorer I make a new folder for say 2014 and then add the 12 month folders for that year.
On import I get LR to import to the current month, currently 2014-08-August see 'Destination' screengrab from import dialogue. This screengrab is an import from iPhone so covers several days of the last week whilst I was off visiting my Mum back home, the imported shots are in the folders with no description and the tick mark/numbers.
In the second screengrab from within LR's Library module you can see those imported folders, which now have a description in their name.
All the shots from 2014-08-07 folder were added to the '2014-08-07 Road Laying' folder as they were also of that subject.
-
Or just use those as keywords, stick with one folder called Swansea. Or both. Whatever works for you.
I think you are missing the point with regard to what I'm saying where physical folders that are organised by subject where circumstance change and thus outgrow your original organising idea.
Photos of your own dogs is quite manageable by your system, but if you became a pro shooter of dogs then suddenly all dog photos in one place would be a bit like the Kelby suggestion you do not like. Having your primary organisation done in a way where you would never need to redo it such as dates is better than one such as subject where it could become unwieldy. Metadata is much better for organising subjects. As illustrated by this reply.
One big Swansea folder with images having either keywords and/or the IPTC location field to differentiate them. If I shot a dog picture there, I'd have an image with a dog keyword.Works for me.
But if you have a physical folder dedicated to dogs as well as one dedicated to places then where do you put the dog photo? Organise physical folders by dates and then use metadata to do the subject organising as a lot of images can be of many subjects. For example - a photo of your pet dog with your girlfriend in Swansea, so is the picture in the Swansea folder, a dog folder or girlfriend folder? Dated folders make for less work and no need to worry where things go when importing. Add keywords at your leisure which can then feed into smart collections.
I originally used to do folders by subject myself, but realised how terribly limiting and time consuming it was and moved to date folders+metadata. I do however still have subject folders for one set of images. Ones in my 'information' folder which are photos to remind me of something to buy or an idea for the house renovation. These are mostly disposable images that only need to be in that one place, kind of like a pin board. There are a bunch of subfolders so I can quickly look at a subject or add to a folder. I think of them as visual notes rather than photos.
-
For example - a photo of your pet dog with your girlfriend in Swansea, so is the picture in the Swansea folder, a dog folder or girlfriend folder?
I've explained this. My folder system is by location; not by subject.
So the example picture goes in the Swansea folder. It gets the appropriate IPTC location data. And it gets the keywords dog, perhaps breed of dog, name of dog (if I know it), girlfriend's name and maybe others. Simple. Works for me.
If folders-by-date works for you, use that.
-
True enough, but they could be mixed in those adjacent folders with previously imported pictures that happen to have been taken on the same day.
Not if you've added a description to folder name. ;D
A work collection is a good idea. Just drag from the recent import collection to the work collection before importing more images. But then you're stuck working in a collection for image editing; it's such a pain to delete a file from the disk when you're working in a collection.
Use folders then, much easier.
Otherwise 'Alt click/Go to folder in Library' and delete from there or use the shortcut/method mentioned here (http://www.mosaicarchive.com/2012/05/09/delete-photos-from-lightroom/)
-
I've explained this. My folder system is by location; not by subject.
Location is subject organising. It does not just mean person or creature in photo.
-
Not if you've added a description to folder name. ;D
Use folders then, much easier.
Otherwise 'Alt click/Go to folder in Library' and delete from there or use the shortcut/method mentioned here (http://www.mosaicarchive.com/2012/05/09/delete-photos-from-lightroom/)
I get the date part; I don't get the description part. What is the description? Location, subject, or what?
-
Location is subject organising. It does not just mean person or creature in photo.
Not true. Location is not the location necessarily shown in the picture (subject), it's where I was when I took the picture. It's unique and objective. It's not a picture of Swansea, it's a picture taken while I was in Swansea.
-
I get the date part; I don't get the description part. What is the description? Location, subject, or what?
The description is whatever makes sense to describe the photos in that folder to you.
-
The description is whatever makes sense to describe the photos in that folder to you.
OK, I'm with you. Mechanically, how do you do that? Lightroom's import function will create the folders-by-date arrangement "automatically" and that would seem to be a good reason to consider using such a structure. But you must have to create the folders and then direct the imports into those folders?
-
This thread continues to throw up interesting issues.
Ultimately, no matter how good we are using the Develop module and the various output modules, it is the Library module, and by extension the import dialog that really determines how usable Lightroom is to us.
Unfortunately, as our image collections become larger so any flaws in our workflow become more acute.
So, having a really efficient, usable, and relevant workflow to suit the brand of photography we do is really important.
A good way to experiment with workflow ideas is to create a test catalog where various import presets, file renaming presets, and even develop presets can get a run in a non-demand scenario where getting it wrong does not matter. Keywording hierarchies and keywording strategies can also be developed
Even experimenting with small numbers of images (10) can be very valuable.
So, if you do need to alter your workflow, doing this in your main catalog is a daunting exercise - don't do it.
Instead, experiment in your test catalog, fine tune your workflow, and when you are confident in what needs to be done only then start implementing the changes in your main catalog.
Lightroom, despite some weaknesses, is actually a very well designed application that can be integrated into the DAM strategies of a wide variety of photographic enterprise.
Tony Jay
-
OK, I'm with you. Mechanically, how do you do that? Lightroom's import function will create the folders-by-date arrangement "automatically" and that would seem to be a good reason to consider using such a structure. But you must have to create the folders and then direct the imports into those folders?
Let LR import the automatically dated folders and then right click and rename them once in Library module.
Or you can select a subset of images you want to be in a different folder and make a new folder by clicking on whichever folder you want images to be in and name them with Same Date-different description.
As I mentioned above at beginning of year I create a year folder and folders for each of the 12 months to go in that. Then import images to the appropriate month as the year progresses. Also worth noting is that you can manually drag folders or images around in LR and they will move on the hard drive(s) to reflect that - that's when moving in 'Folder' panel not in collections as they are virtual. Move a folder from Hard Drive 1 to Hard Drive 2 will copy off HD1 and then LR will delete from HD1 when all files are moved.
Not true. Location is not the location necessarily shown in the picture (subject), it's where I was when I took the picture. It's unique and objective. It's not a picture of Swansea, it's a picture taken while I was in Swansea.
But where in Swansea? It covers a big area, so not that unique. Were you in the Mumbles, Townhill, Waunarlwydd or maybe the city centre or a particular place in the Mumbles. Also does The Gower count as Swansea or even the Mumbles come to that? Mumbles has a Swansea postcode but is the other side of the bay from the city itself and is most certainly a physically separate entity.
Plus if you go there a lot you may end up with tens of thousands of photos in one folder.
Pic below is a snap from iPhone taken in part of Mumbles called Southend but looking towards Swansea across the bay, so a single folder location to sort it by isn't that unique or obvious to me and that's where I grew up. :o
-
This thread continues to throw up interesting issues.
Ultimately, no matter how good we are using the Develop module and the various output modules, it is the Library module, and by extension the import dialog that really determines how usable Lightroom is to us.
Absolutely. Finding your images is the first and most important stage of being able to develop or do anything with them. :)
-
But where in Swansea?
Maybe that's a bad example for me as I don't know what, or how big, Swansea is. My locations end up being a city or an island: Mexico > Cozumel > San Miguel or North Carolina > Oak Island.
If I was in Southend when I took a picture of Swansea, I'd put it in the Southend folder, not the Swansea folder. I'm after the location my feet were in, not the location in the picture.
-
I think you are missing the point with regard to what I'm saying where physical folders that are organised by subject where circumstance change and thus outgrow your original organising idea.
If in the simplest form I've described their use they do, you simply add more folders or refine the name as I illustrated by adding the name Cat to the Dog folder or adding a Cat subfolder.
Photos of your own dogs is quite manageable by your system, but if you became a pro shooter of dogs then suddenly all dog photos in one place would be a bit like the Kelby suggestion you do not like.
Not at all! First, all the other folders besides Dog are still useful in finding items in those folders outside the DAM. 2nd, that isn't at all like Kelby suggesting one folder for all images and then finding them solely in the DAM (using proprietary dumb collections too).
Having your primary organisation done in a way where you would never need to redo it such as dates is better than one such as subject where it could become unwieldy.
Who said anything about primary but you? You don't seem to understand the simple role of naming and organizing folders outside the DAM. It's far from primary.
Metadata is much better for organising subjects. As illustrated by this reply.
Who here has suggested otherwise?
But if you have a physical folder dedicated to dogs as well as one dedicated to places then where do you put the dog photo?
I told you, I'll tell you again, it doesn't matter. Put them where it makes most sense to you. For me, the answer would be, in the dog folder.
Organise physical folders by dates and then use metadata to do the subject organising as a lot of images can be of many subjects.
Dates are meaningless to me. If they are meaningful to you, please do so. Separating dogs into different folders by date would make finding the images outside the DAM nearly impossible for me while having them all in one folder makes it very easy for me.
For example - a photo of your pet dog with your girlfriend in Swansea, so is the picture in the Swansea folder, a dog folder or girlfriend folder? Dated folders make for less work and no need to worry where things go when importing. Add keywords at your leisure which can then feed into smart collections.
Not on my system, my dog would go into the dog folder. A number of keywords could define Swansea or girlfriend. If outside the DAM I needed to find a picture of my dog, it's going to be in the dog folder. Pretty simple.
I originally used to do folders by subject myself, but realised how terribly limiting and time consuming it was and moved to date folders+metadata.
So you modified a system that didn't work for you with one that does. Your system isn't going to work for me. It might not work for Bob.
There's nothing you've stated thus far that doesn't support my way of working for me, if a single folder named Dog doesn't have sufficient granularity, very easy to create a new folder in LR and call it Border Collie, Whippet, Huskey and move existing images there or just start placing those breeds into sub folders. The same images would still have keywords describing those breeds. But if I needed to find a photo of a dog, I know what folder to look in outside the DAM. I don't see how you miss that this is both simple, flexible and most importantly, a system that works for me and has since before LR shipped.
-
Maybe that's a bad example for me as I don't know what, or how big, Swansea is. My locations end up being a city or an island: Mexico > Cozumel > San Miguel or North Carolina > Oak Island.
If I was in Southend when I took a picture of Swansea, I'd put it in the Southend folder, not the Swansea folder. I'm after the location my feet were in, not the location in the picture.
But where Southend is is not exactly easy to say. There are no signs referring to it as Southend, I doubt any visitor would realise that is where they were, I grew up there and couldn't tell you where it officially starts or stops. Or even if there is an official demarking of the area.
-
Maybe that's a bad example for me as I don't know what, or how big, Swansea is.
Even if you did, is that important to you? GPS metadata would be far more useful too. Don't get me wrong, it might be very important to divide up all the various locations in Swansea but it might not. Seth has hundreds upon hundreds of keywords as for his workflow he needs it. I have a fraction of the number of keywords as Seth. But I've as yet had very few issues finding my images. And as I keep saying, that's the bottom line, what your needs are. Seth (who's a friend and partner) has never told me I must use more keywords. Don't let anyone here tell you the method you use to file anything isn't correct. For you!
-
Even if you did, is that important to you? GPS metadata would be far more useful too. Don't get me wrong, it might be very important to divide up all the various locations in Swansea but it might not. Seth has hundreds upon hundreds of keywords as for his workflow he needs it. I have a fraction of the number of keywords as Seth. But I've as yet had very few issues finding my images. And as I keep saying, that's the bottom line, what your needs are. Seth (who's a friend and partner) has never told me I must use more keywords. Don't let anyone here tell you the method you use to file anything isn't correct. For you!
There are a couple of important points here:
1. Workflow does need to be individualised. A perfect solution for one is anathema to another.
2. Understanding principles is crucial otherwise the implementation will be poor and unusable.
3. Suggestions are good - prescriptions are bad - see 1. and 2.
For what it is worth my workflow is very different to Andrew's. I have a very detailed keyword hierarchy approaching 24 000 keywords, and counting. I also make extensive use of IPTC metadata fields and therefore metadata presets to help that process. Smart collections, as a result, becomes the primary method by which I organise myself - even for what I do in the Develop module.
However, I would be very cautious in recommending that anyone else implement my workflow in detail unless I understood their workflow needs to the nth degree.
Far rather people get ideas from my workflow that are implementable and rational for their workflow.
Tony Jay
-
For what it is worth my workflow is very different to Andrew's. I have a very detailed keyword hierarchy approaching 24 000 keywords, and counting. I also make extensive use of IPTC metadata fields and therefore metadata presets to help that process. Smart collections, as a result, becomes the primary method by which I organise myself - even for what I do in the Develop module.
Other than how we might organize our folders, our workflows are probably not that different. I don't have anywhere the number of keywords but use them religiously for all images. I have a boat load of Smart Collections, love em. I use IPTC metadata fields a lot too. I wish LR would allow us to search and build SC's on any and every such field (why it doesn't after all these years I can't understand).
-
This thread clearly shows that people want to be able to find their images outside the DAM, and that finding that needle in the haystack is challenging. Who needs a DAM if the OS could handle this use case buy itself?
Out of curiosity: on average, how many keywords do you all apply to your images? 5? 10? 20?
Windows (NTFS) and Mac OS both support filenames of up to 255 characters, not including the extension. Why not just rename your files according to the keywords that you apply to the image? It would be trivial to write a script for exiftool to do this.
This easily solves the problem of finding images outside the DAM since Windows and Mac OS can both find files that contain some string. A file named "Susan-Johnny-California-Calistoga-Wedding-Sunset[-sequence, if necessary].CR2" is infinitely more findable and recognizable than some abbreviation or abstraction through folders. It also means you aren't duplicating data, since the capture date metadata, file creation date, file modification date, etc are available for sorting, filtering, etc.
If, on average, there are 25 keywords applied and each keyword contains 10 chars, the filename is a better place to describe the contents of the image since the filename is often used to describe the contents or subject of the file. This avoids all the tomfoolery associated with devising complex folder structures.
PP
-
OK, so that leaves you with a bunch of renamed images in the initial folder all ready for editing and adjustments. From there, how do you get them all distributed into the folder-by-date structure? Drag and drop?
The name given to the initial folder, when it was created, would be that days date ("20140809") and I move images from my camera into that "20140809" folder using a mini USB cable and select all / copy / paste - so the "initial" folder is actually the final folder.
All the image files end-up being prefixed with the name of the folder that contains them and suffixed to ensure unique names.
-
This thread clearly shows that people want to be able to find their images outside the DAM, and that finding that needle in the haystack is challenging. Who needs a DAM if the OS could handle this use case buy itself?
Out of curiosity: on average, how many keywords do you all apply to your images? 5? 10? 20?
Windows (NTFS) and Mac OS both support filenames of up to 255 characters, not including the extension. Why not just rename your files according to the keywords that you apply to the image? It would be trivial to write a script for exiftool to do this.
This easily solves the problem of finding images outside the DAM since Windows and Mac OS can both find files that contain some string. A file named "Susan-Johnny-California-Calistoga-Wedding-Sunset[-sequence, if necessary].CR2" is infinitely more findable and recognizable than some abbreviation or abstraction through folders. It also means you aren't duplicating data, since the capture date metadata, file creation date, file modification date, etc are available for sorting, filtering, etc.
If, on average, there are 25 keywords applied and each keyword contains 10 chars, the filename is a better place to describe the contents of the image since the filename is often used to describe the contents or subject of the file. This avoids all the tomfoolery associated with devising complex folder structures.
PP
If you really want to do this you can but I would not recommend this approach.
Searching for images outside of DAM software is not mean't to be a common approach but something that one may have to resort to when there is an issue.
Tony Jay
-
Here the workflow I have developed over the years as a amateur with some 1000 photos a year.
I copy the pictures to the computer from the cards via the operating system, not within lightroom.
The reson for this is that I often have more then one card, often I have my "serious" DSLR and a little Point-and-Shoot.
I copy all the files in a folder year/yyyy_mm_dd_"a description of the shoot" . So, if I do a portrait session with my girlfriend or my niece it will their name, if I go to the zoo it will be the name of the zoo, if I am in the city it will be that name, just something that reminds me where I was or what I shot.
Then I import the folder into Lightroom and let it create the previews (und often have a coffee or dinner while the machine does it's work, this is why I import after copying).
After this I do my keywording and geocoding.
I use the folders for short term uses, say I want show my mother the shots from the last shooting with my niece, I just select the correct folder within LR and show her.
Otherwise I would have to search by date and the name of my niece.
On the other hand, if I want search all the pictures of the tiger in our zoo, keyword search is the method of choice.
I strongly believe there is no "correct" way of organizing his or her pictures, everyone has different needs, different ways to think or remember things.
Of course I took ideas and methods of others, but at the end I had to develop my own method that works for me.
-
I strongly believe there is no "correct" way of organizing his or her pictures, everyone has different needs, different ways to think or remember things.
But that doesn't mean all ways are equally good.
-
"I strongly believe there is no "correct" way of organizing his or her pictures, everyone has different needs, different ways to think or remember things.
Of course I took ideas and methods of others, but at the end I had to develop my own method that works for me."
My sentiments exactly!!! I find it quite irksome when some people say "No, your way is all wrong" B.S., if it works for me, it's most certainly correct. Could there be improvements, probably. But only if I am having a problem do I need to adjust. Had I done it a different way in the beginning, perhaps it would work better, but to redo a system that suffices on 10's of thousands of images would be insane (for me). Possibly changing going forth, but that would depend on if the present system is really problematic!
-
But that doesn't mean all ways are equally good.
But that judgement is up to the individual, as what's good for one may not be good for another. Has someone been appointed to be the almighty ranker from good to bad. (I know, there could be flaws in anyones system and could be improved in someway)
-
The name given to the initial folder, when it was created, would be that days date ("20140809") and I move images from my camera into that "20140809" folder using a mini USB cable and select all / copy / paste - so the "initial" folder is actually the final folder.
Not heard of this new fangled thing called drag and drop then Issac? ;)
Easier to use LR to import images into folders by date anyway. Even better when they are images from multiple dates.
-
In my mind, this issue isn't so much about what way is "correct." It's more about ways that can lead to dead ends as the photo library expands.
For example, many would agree that a single folder full of 100 pictures may not be a problem today. But when that library grows to tens of thousands with many different subjects taken in may different places for many different reasons, that idea will hit a dead end. The owner may not see that coming.
I've mentioned a potential dead end to my folders-by-location arrangement. One day I may have so many pictures that they can't all fit on a single storage device. At that point, bringing on a second storage device brings the question of what to do with that system? I'd probably have to move an arbitrary number of top level location folders to the new device. If my system were folders-by-date, I'd just cut over to the second device on a certain date.
For me, my system works well and I'm willing to take the chance that I may have a somewhat less good solution if I have to split things across storage devices. Or maybe storage devices will continue to grow in capacity at least as fast as my library grows.
My reason for starting the thread in the first place was to hear from others, with more experience and larger libraries, about potential dead ends.
-
But that judgement is up to the individual, as what's good for one may not be good for another. Has someone been appointed to be the almighty ranker from good to bad. (I know, there could be flaws in anyones system and could be improved in someway)
No it isn't. Bad practice is bad practice.
-
No it isn't. Bad practice is bad practice.
No? what isn't???
I agree, a bad practice is a bad practice. But you telling me my system is bad, when it works great for me is B.S. just because it doesn't follow your way of thinking.
-
I've mentioned a potential dead end to my folders-by-location arrangement. One day I may have so many pictures that they can't all fit on a single storage device. At that point, bringing on a second storage device brings the question of what to do with that system?
I don't see that being a problem this early in the more san's coffee. LR can easily deal with multiple drives. Say you have one drive with all your folders. Let's say for simplicity there are 26 root folders (A-Z). Your drive is getting too full. You buy another. In LR you move folder K-Z to new, secondary drive. Don't let potential FUD lead you to believe the system you are using or envisioning will explode in your face someday.
-
If in the simplest form I've described their use they do, you simply add more folders or refine the name as I illustrated by adding the name Cat to the Dog folder or adding a Cat subfolder.
There's nothing you've stated thus far that doesn't support my way of working for me, if a single folder named Dog doesn't have sufficient granularity, very easy to create a new folder in LR and call it Border Collie, Whippet, Huskey and move existing images there or just start placing those breeds into sub folders. The same images would still have keywords describing those breeds. But if I needed to find a photo of a dog, I know what folder to look in outside the DAM. I don't see how you miss that this is both simple, flexible and most importantly, a system that works for me and has since before LR shipped.
Still missing the point I was making. A date system never needs to be amended after the fact. Whereas as you just mentioned and as I previously illustrated above that you need to physically move images around folders as your library expands and gets more complex if filing by subject.
Who said anything about primary but you? You don't seem to understand the simple role of naming and organizing folders outside the DAM.
So back to your usual insulting and inaccurate self I see. Two people used the word primary, but in two different ways. Go back and read posts properly before replying. And I certainly do understand naming and organising files outside of a dam as that's why I take great pains to organise my work in folders that I can easily browse in or outside of LR
It's far from primary. Who here has suggested otherwise? I told you, I'll tell you again, it doesn't matter. Put them where it makes most sense to you. For me, the answer would be, in the dog folder.
I always tell people to place things where it makes sense to them. Doesn't mean their system is not badly flawed or even bonkers though.
Dates are meaningless to me. If they are meaningful to you, please do so. Separating dogs into different folders by date would make finding the images outside the DAM nearly impossible for me while having them all in one folder makes it very easy for me. Not on my system, my dog would go into the dog folder. A number of keywords could define Swansea or girlfriend. If outside the DAM I needed to find a picture of my dog, it's going to be in the dog folder. Pretty simple.
Not really as you need to use a DAM to find Swansea or girlfriend but not dog. That is fine if dogs are you primary interest and nothing else is important.
This is why physically filing by subject is flawed as photos can be many subjects at the same time.
So you modified a system that didn't work for you with one that does. Your system isn't going to work for me. It might not work for Bob.
Not saying you should change, but I am pointing out how it is flawed and scales poorly as your library expands.
The reality is that if you have a large library of images a DAM is the only way to find all aspects of your work. Organising folders so that a file browser can also easily be used is sensible as it's a belt and braces [or suspenders in American] way of working. Using just metadata or just physical folders has huge drawbacks to each system, together however they are very complementary.
-
I'm saying nothing about your system as I know nothing about it. But if you want an example of bad practice, look above to the suggestion of loading keywords into file names. The thing is, we should never make the mistake of saying whatever works for someone must be ok or equally good.
-
Still missing the point I was making. A date system never needs to be amended after the fact.
I don't care, you are missing my point! Dates are meaningless to me, content isn't. I can find dates within the Finder, it's been possible from day one. There's zero advantage TO ME to use dates within a folder structure.
Two people used the word primary, but in two different ways.
I don't care if two thousand different people used the term. Folder structure isn't and never was intended as a primary or secondary method of organizing images. It's simply one additional method outside the DAM to find my images in a method I prefer.
And I certainly do understand naming and organising files outside of a dam as that's why I take great pains to organise my work in folders that I can easily browse in or outside of LR
And your method would fail for me. Get it?
I always tell people to place things where it makes sense to them.
Thanks, I'll continue to do that.
Doesn't mean their system is not badly flawed or even bonkers though.
There is nothing flawed or bonkers with my system, it works exactly as I wish it to work. Move on, you're never going to convince me with that FUD! Let's hope others like Bob don't either. But that's his call.
The reality is that if you have a large library of images a DAM is the only way to find all aspects of your work.
Hogwash! It will be more difficult but it's not the only way! It is flawed and bonkers to suggest, no demand, that a DAM is the only way to find images.
-
My sentiments exactly!!! I find it quite irksome when some people say "No, your way is all wrong" B.S., if it works for me, it's most certainly correct.
The FUD proponents will have you blue in the fact trying to convince you otherwise. This isn't about a scientific, fact based argument like, if you take a 16-bit ProPhoto image of colorful flowers and convert it to sRGB JPEG, there's a reduction of color gamut. You might not care about this anyway. This debate is about how you and I find our images. If it works for us, it works for us, there isn't any science these guys can spit out that will convince us otherwise nor should it.
One can argue that going from point A to point B can have differing paths and one is a shorter distance than the other. The tools and science in comparing the two is not up to debate. If the goal is to get from point A to point B and you don't care the distance traveled, any path is equally valid. But even if you tell a FUD proponent you prefer the longer path because it's a more enjoyable journey, or you can also drop off your laundry to the cleaners using that path, they will tell you it's wrong, the shorter path is better. FOR THEM! So unless you submit to their way, it's the highway which is ridiculous. If they really did have your workflow interest in mind, they would listen and understand the path you've chosen is better for you. But it's all about them. Ignore them.
-
In my mind, this issue isn't so much about what way is "correct." It's more about ways that can lead to dead ends as the photo library expands.
For example, many would agree that a single folder full of 100 pictures may not be a problem today. But when that library grows to tens of thousands with many different subjects taken in may different places for many different reasons, that idea will hit a dead end. The owner may not see that coming.
I've mentioned a potential dead end to my folders-by-location arrangement. One day I may have so many pictures that they can't all fit on a single storage device. At that point, bringing on a second storage device brings the question of what to do with that system? I'd probably have to move an arbitrary number of top level location folders to the new device. If my system were folders-by-date, I'd just cut over to the second device on a certain date.
For me, my system works well and I'm willing to take the chance that I may have a somewhat less good solution if I have to split things across storage devices. Or maybe storage devices will continue to grow in capacity at least as fast as my library grows.
My reason for starting the thread in the first place was to hear from others, with more experience and larger libraries, about potential dead ends.
This is exactly the problem with physical filing by subject [location is a subject]. It doesn't scale well or adapt to increasing complexity without more work.
Date filing for physical organising does not have that issue or any need to adapt and is less effort too, so win, win. :)
I have 376k images and now with yyyy-mm-dd description filing there are no problems as my library expands/gets more complex.
With music, I physically file everything alphabetically [the equivalent of date] and then use smart playlists to organise by genre/feel and finally after several decades and various filing systems I feel my music is finally organised. Organising by single subject [genre/feel/tempo etc] simply does not work in any shape or form. I recall music for a variety of reasons, what city an artist came from, what genre they are play which can vary enormously, a specific tune, the band's name, when I heard it and so on. Now I can search by all methods.
By the way you can easily convert all your photos to a date folder system. Firstly tag all photos in your locations using keywords and create smart collections that correspond to to your locations or any other filing criteria you use. Now you have collections that correspond to your folders and any DAM you use will be able to do this. Now import all your images into LR by date and voila you now have all images in date folders, Create year and month folders to place the individual day folders in and add a description to each folder if you want [recommended]. Test this on a duplicate subset of your images to get a feel for it and once all the prelim work is done go for it, if it suits you. There's be a chunk of work in adding folder descriptions in one big go but in future, it takes very little effort to keep going with this system.
It'll probably be easier to do with with a new catalogue as otherwise you have to delete all pics from current catalogue and then re-import by date.
But I really advise doing this with a duplicate set of images in case you decide to go back to your prior system.
-
Not heard of this new fangled thing called drag and drop then Issac? ;)
I've seen too many people release before they'd dragged over the target. Performance of the keyboard shortcuts is more reliable.
Easier to use LR to import images into folders by date anyway. Even better when they are images from multiple dates.
Did you read carefully enough to understand that images from multiple dates are placed in the same "date" folder, if they are loaded onto the computer on the same date?
-
I'm saying nothing about your system as I know nothing about it. But if you want an example of bad practice, look above to the suggestion of loading keywords into file names. The thing is, we should never make the mistake of saying whatever works for someone must be ok or equally good.
I agree ... I think the tedium of sorting shoots into multiple folders and sub folders can be a bit redundant, my time is more valuable ... also the desire to store all pertinent data in a file name simply because Apple and MS allow us to utilize 255 characters seems to defeat the purpose of DAM.
I consider Peter's book an extremely valuable asset and I think it should be required reading for anyone who has to deal with more than a few dozen images. I don't follow his recommendations exactly to the letter ... but I think establishing a simple, methodical folder structure is key without resorting to extraneous pre-file sorting by subject, category, geo location or using 255 character names goes a long way in keeping an archive more streamlined and better suited to pass the test of time. Besides, DAM solutions should not create more work ... they should make the task easier.
I'm not condemning what others prefer to do. I prefer to keep my DAM tasks as simple as possible by invoking the power of the software to allow more time for clicking my shutter release rather than a mouse or trackpad.
-
I don't care, you are missing my point! Dates are meaningless to me, content isn't. I can find dates within the Finder, it's been possible from day one. There's zero advantage TO ME to use dates within a folder structure.
Not telling you to use dates, just pointing out the flaws of not using them. Or and anyone who uses Finder for anything is a masochist. :P
I don't care if two thousand different people used the term. Folder structure isn't and never was intended as a primary or secondary method of organizing images.
Utter, utter bollocks what a daft thing to say, even for you. For many many years it was the only way of organising your images. File Browsers were how people organised and found their data that was in folders until DAM apps started to appear [which not until LR appeared did it become mainstream] and even now I bet most people us folders as their primary organising.
Folders are my primary organising tool [primary meaning first as I already explained] and it works very well indeed.
And your method would fail for me. Get it? Thanks, I'll continue to do that. There is nothing flawed or bonkers with my system, it works exactly as I wish it to work. Move on, you're never going to convince me with that FUD! Let's hope others like Bob don't either. But that's his call. Hogwash! It will be more difficult but it's not the only way! It is flawed and bonkers to suggest, no demand, that a DAM is the only way to find images.
Didn't say your method was bonkers, definitely flawed though.
Of course you can find an image in a library of hundreds of thousands of images without a DAM, simply by manually searching. But as you well know that is not a usable solution compared to using some metadata to quickly pick up the files you are looking for - assuming you have added some, no point using a DAM otherwise.
-
I've seen too many people release before they'd dragged over the target. Performance of the keyboard shortcuts is more reliable.
So other people make mistakes, so you daren't do that? ??? Not to mention copying into the wrong folder is not even a problem, cancel the copy or move files into correct folder once done. No big deal.
Dragging to correct folder is no harder than pasting to correct folder.
Did you read carefully enough to understand that images from multiple dates are placed in the same "date" folder, if they are loaded onto the computer on the same date?
If you actually took photographs you would know that photographs taken on different dates get loaded into different date folders by LR regardless of when they are copied onto the computer. LR can tell the difference between shot date and copied date because it is different metadata.
-
So other people make mistakes, so you daren't do that?
I see no reason to make those same mistakes.
If you actually took photographs you would know that photographs taken on different dates get loaded into different date folders by LR regardless of when they are copied onto the computer.
And that is not what I wish to be done. (http://books.google.com/books?id=ZMYA5ygSzPkC&lpg=PP1&dq=Thousands%20of%20images%2C%20now%20what%3F%20%3A%20painlessly%20organize%2C%20save%2C%20and%20back%20up%20your%20digital%20photos&pg=PT77#v=onepage&q=%22The%20date%20is%20the%20download%20date,%20not%20the%20date%20the%20pictures%20were%20taken.%22&f=false)
-
The FUD proponents will have you blue in the fact trying to convince you otherwise. This isn't about a scientific, fact based argument like, if you take a 16-bit ProPhoto image of colorful flowers and convert it to sRGB JPEG, there's a reduction of color gamut. You might not care about this anyway. This debate is about how you and I find our images. If it works for us, it works for us, there isn't any science these guys can spit out that will convince us otherwise nor should it.
Actually someone could show you or myself an easier way to find our images and that would be a fact. Saving time is a measurable quantity which can be used to prove facts. :P Here's a fact for you, I used to use your method, but outgrew it's usefulness and now use a easier methodology.
One can argue that going from point A to point B can have differing paths and one is a shorter distance than the other. The tools and science in comparing the two is not up to debate. If the goal is to get from point A to point B and you don't care the distance traveled, any path is equally valid. But even if you tell a FUD proponent you prefer the longer path because it's a more enjoyable journey, or you can also drop off your laundry to the cleaners using that path, they will tell you it's wrong, the shorter path is better. FOR THEM! So unless you submit to their way, it's the highway which is ridiculous. If they really did have your workflow interest in mind, they would listen and understand the path you've chosen is better for you. But it's all about them. Ignore them.
Poor analogy, I will happily travel a longer, more interesting route somewhere but simply making things more difficult for oneself is not an interesting journey it's just harder less pleasant work.
You love to use the ridiculous term FUD whenever you have no argument to back up your point of view it would seem.
-
I see no reason to make those same mistakes.
Nor me, so I do it better than those who got it wrong, so no mistakes are made. Not attempting something is a lazy way out.
And that is not what I wish to be done. (http://books.google.com/books?id=ZMYA5ygSzPkC&lpg=PP1&dq=Thousands%20of%20images%2C%20now%20what%3F%20%3A%20painlessly%20organize%2C%20save%2C%20and%20back%20up%20your%20digital%20photos&pg=PT77#v=onepage&q=%22The%20date%20is%20the%20download%20date,%20not%20the%20date%20the%20pictures%20were%20taken.%22&f=false)
Being too terse again Isaac. What point are you making?
-
Actually someone could show you or myself an easier way to find our images and that would be a fact.
Easier is subjective, something you don't seem understand based on your posts here. Ever hear the old saying, "you can pay me now or you can pay me later?" Saving time now to waste it later (for me, trying to find something outside a DAM with dates) isn't time effective for me. If it is for you, great.
You love to use the ridiculous term FUD whenever you have no argument to back up your point of view it would seem.
It is FUD because as yet, years and years after setting up my preferred system, it's working exactly as I wish it to work. So you are only voicing nonsense FUD text like bonkers, and definitely flawed. Here is another old saying you should consider: if it ain't broke, don't fix it. I can only speak for myself unlike others here, my system isn't broken. As such, I have no reason to consider your FUD which is based on your own language (bonkers, definitely flawed though). What is flawed is your inability to allow us to use a system that works for us, despite text you wrote that sounds pretty hypocritical putting the two in context:I always tell people to place things where it makes sense to them.
My system makes sense to me. I have no issues finding my images inside or outside the DAM. It is therefore and has been since I started it, not flawed nor bonkers (whatever that is supposed to mean).
-
And that is not what I wish to be done.
What you wish to be done and how is immaterial to jjj and a few others. You must do what they want you to do because it's right. Therefore you're wrong, the workflow is flawed. All while we hear:I always tell people to place things where it makes sense to them.
Do what you want, it probably will work. If it needs modification, you are probably smart enough but of course not as smart as jjj and a few others, to modify your workflow. The discussion is wavering to the point it probably needs to be shut down as once again, the insults are flying:
If you actually took photographs you would know that photographs taken on different dates get loaded into different date folders by LR regardless of when they are copied onto the computer.
You love to use the ridiculous term FUD whenever you have no argument to back up your point of view it would seem.
Being too terse again Isaac. What point are you making?
Not heard of this new fangled thing called drag and drop then Issac?
Bob, as the OP, you gaining anything here within the last page or two or is this just moving towards another waste of time?
-
Nor me, so I do it better than those who got it wrong, so no mistakes are made. Not attempting something is a lazy way out.
I make no mistakes using select all / copy / paste.
Being too terse again Isaac. What point are you making?
Troll.
-
...But if you want an example of bad practice, look above to the suggestion of loading keywords into file names...
How exactly is that a bad practice? Of the files named 2014-08-01_04-01-25.CR2 and 2013-08-01_04-01-25.CR2, which one has a picture of Johnny? If you have 50,000 images each named according to this scheme, meticulously organized into folders named by year, how do you find all the images that contain pictures of your dog when you lived in San Francisco, but not in Los Angeles?
The file itself has a creation date and a modification date, and most systems will let you search for the capture date...so naming your file by date is duplicating data, and doesn't provide any meaningful information about what the file has in it (e.g. the subject). Describing the subject is why keywords exist. Unfortunately, setting/getting keywords is only available in your "black box" DAM application.
I provided an explanation for why keyword-based file naming is a better solution for being able to find your images outside the DAM; it's up to you to show why date-based file naming (or any other file naming scheme) is better. The only explanations provided thus far are appeals to authority...("I read it in a book").
PP
-
Easier is subjective, something you don't seem understand based on your posts here.
Well seeing as you selectively quoted a post to take it out of context and are forever misinterpreting people's posts, maybe you should try reading posts more correctly.
-
Troll.
So asking you to clarify one of your overly succinct posts is trolling and there's me thinking you liked to be precise about use of language.
-
What you wish to be done and how is immaterial to jjj and a few others. You must do what they want you to do because it's right. Therefore you're wrong, the workflow is flawed. All while we hear:I always tell people to place things where it makes sense to them.
Stop misrepresenting my and other people's views.
Do what you want, it probably will work. If it needs modification, you are probably smart enough but of course not as smart as jjj and a few others, to modify your workflow. The discussion is wavering to the point it probably needs to be shut down as once again, the insults are flying:
From you and oddly now Isaac it would seem.
Your continued personal attacks singling myself out are very tedious, you need to get over yourself.
-
So asking you to clarify one of your overly succinct posts is trolling and there's me thinking you liked to be precise about use of language.
If you actually took photographs…
Troll.
…you would know that photographs taken on different dates get loaded into different date folders by LR regardless of when they are copied onto the computer.
"And that is not what I wish to be done." (http://books.google.com/books?id=ZMYA5ygSzPkC&lpg=PP1&dq=Thousands%20of%20images%2C%20now%20what%3F%20%3A%20painlessly%20organize%2C%20save%2C%20and%20back%20up%20your%20digital%20photos&pg=PT77#v=onepage&q=%22The%20date%20is%20the%20download%20date,%20not%20the%20date%20the%20pictures%20were%20taken.%22&f=false)
-
I simply cannot understand why folder structure and naming is such a pain. At the end of the day the filename is the thing that has to be unique in a given realm. Compare with isbn or ean coding. This makes it unique regardlesss of where it is stored or in which collection it is being referred. Folders are just physical storing structures.
-
How exactly is that a bad practice?
See ButchM's explanation above. Further, do you change the filenames when keywords change?
-
How exactly is that a bad practice?
I think John was talking about putting all the metadata into the name.
Of the files named 2014-08-01_04-01-25.CR2 and 2013-08-01_04-01-25.CR2, which one has a picture of Johnny? If you have 50,000 images each named according to this scheme, meticulously organized into folders named by year, how do you find all the images that contain pictures of your dog when you lived in San Francisco, but not in Los Angeles?
The file itself has a creation date and a modification date, and most systems will let you search for the capture date...so naming your file by date is duplicating data, and doesn't provide any meaningful information about what the file has in it (e.g. the subject).
No, but it serves the same purpose as your wanting to add keywords to the name, it's useful outside of a DAM. Plus it makes file names unique which is the most important reason.
Describing the subject is why keywords exist. Unfortunately, setting/getting keywords is only available in your "black box" DAM application.
I provided an explanation for why keyword-based file naming is a better solution for being able to find your images outside the DAM; it's up to you to show why date-based file naming (or any other file naming scheme) is better. The only explanations provided thus far are appeals to authority...("I read it in a book").
Long file/folder names tend to be hard to read as they get truncated in many UIs, so Date + [short]description is better. Date+description is like folder and metadata organising is better than either one is on their own.
-
Troll.
No that second quote you used was taking the mickey, a different thing from trolling and not the one you first quoted when calling me a troll. As I said, I thought you liked to be precise about things, you are being disappointing today Isaac.
"And that is not what I wish to be done." (http://books.google.com/books?id=ZMYA5ygSzPkC&lpg=PP1&dq=Thousands%20of%20images%2C%20now%20what%3F%20%3A%20painlessly%20organize%2C%20save%2C%20and%20back%20up%20your%20digital%20photos&pg=PT77#v=onepage&q=%22The%20date%20is%20the%20download%20date,%20not%20the%20date%20the%20pictures%20were%20taken.%22&f=false)
Still as terse and uninformative as the first time you posted the link.
-
The file itself has a creation date and a modification date, and most systems will let you search for the capture date...so naming your file by date is duplicating data, and doesn't provide any meaningful information about what the file has in it (e.g. the subject). Describing the subject is why keywords exist. Unfortunately, setting/getting keywords is only available in your "black box" DAM application.
Completely agree.
I provided an explanation for why keyword-based file naming is a better solution for being able to find your images outside the DAM; it's up to you to show why date-based file naming (or any other file naming scheme) is better. The only explanations provided thus far are appeals to authority...("I read it in a book").
Right, the lack of any other explanation, when the same folks tell us:I always tell people to place things where it makes sense to them. is telling.
-
I simply cannot understand why folder structure and naming is such a pain. At the end of the day the filename is the thing that has to be unique in a given realm. Compare with isbn or ean coding. This makes it unique regardlesss of where it is stored or in which collection it is being referred. Folders are just physical storing structures.
Folder structure and naming is dead easy. Some people don't like to do things the easy way though. ;)
-
See ButchM's explanation above. Further, do you change the filenames when keywords change?
There's no reason he couldn't.
-
I think John was talking about putting all the metadata into the name.
No, but it serves the same purpose as your wanting to add keywords to the name, it's useful outside of a DAM. Plus it makes file names unique which is the most important reason.
Long file/folder names tend to be hard to read as they get truncated in many UIs, so Date + [short]description is better. Date+description is like folder and metadata organising is better than either one is on their own.
Agree, though I was just referring to keywords. Butch added all metadata.
I have encountered a good reason for pumping keywords into filenames, but it was purely for SEO because the stock site parsed information from the filenames. Instead of applying the keywords to files which were exported to his stock site, the user had followed the advice of Dan H????? and renamed his master files. Plenty hit 250+ characters and he found the system cumbersome to read and time consuming to maintain, and a year down the track he came to his senses when dealing with derivative files and finding he didn't have spare characters to add a suffix like "B&W" or "Client X". Sooner or later bad practice will bite you in the bum, usually at the most inconvenient time.
-
There's no reason he couldn't.
You can spend hours polishing a turd, if that turns you on.
-
At the end of the day the filename is the thing that has to be unique in a given realm.
Yes!
prefix (date the new folder was created) - suffix (sequence number within the folder)
20140809-001.ARW
-
No that second quote you used was taking the mickey, a different thing from trolling and not the one you first quoted when calling me a troll.
"a person who sows discord on the Internet by starting arguments or upsetting people"
-
"a person who sows discord on the Internet by starting arguments or upsetting people"
Ooh, the irony.
-
You can spend hours polishing a turd, if that turns you on.
Apparently it does according to a previous excuse for doing things the hard way.
-
You can spend hours polishing a turd, if that turns you on.
One man's turd is another's gem. But of course, trying to get you or jjj to let us do what we think is best, based on our own unique workflow, needs and understanding or our needs isn't on your radar.
You guys are right, we are all wrong. That is about the only text that will get the troll-like behavior to cease in such discussions.
One can spend hours debating with turds, it's rather pointless.
-
There's no reason he couldn't.
There are several good reasons not to as well ... foremost would be if the image is used or referenced elsewhere by other software for say a video, slideshow, book design, etc. outside of your DAM software, changing/updating the name to reflect metadata changes could break those links creating even more work. It seems silly to me to employ folder structure and naming conventions to duplicate the purpose EXIF and IPTC metadata ... the latter two specifically designed for such work ... it just seems like a unneccessary duplication of effort.
By all means, I am not judging anyone on what they use in their personal workflow ... only raising questions as to exactly how efficient such mentioned options are in real world daily chores.
Considering Apple is integrating "tagging" or keywords into the OS ... I'm hoping we can see better integration of metadata for our digital assets inside and outside of DAM solutions to streamline things even further.
-
I have encountered a good reason for pumping keywords into filenames, but it was purely for SEO because the stock site parsed information from the filenames. Instead of applying the keywords to files which were exported to his stock site, the user had followed the advice of Dan H????? and renamed his master files. Plenty hit 250+ characters and he found the system cumbersome to read and time consuming to maintain, and a year down the track he came to his senses when dealing with derivative files and finding he didn't have spare characters to add a suffix like "B&W" or "Client X". Sooner or later bad practice will bite you in the bum, usually at the most inconvenient time.
That would be Dan Heller I'd guess, the most prolix of chaps. So excessively long file names seem totally in keeping with his usual logorrhea.
-
Considering Apple is integrating "tagging" or keywords into the OS ... I'm hoping we can see better integration of metadata for our digital assets inside and outside of DAM solutions to streamline things even further.
I'm not sure what Apple is going to do, but it seems much of this exists as seen here using Get Info:
(http://www.digitaldog.net/files/getinfo.jpg)
-
One man's turd is another's gem. But of course, trying to get you or jjj to let us do what we think is best, based on our own unique workflow, needs and understanding or our needs isn't on your radar.
You guys are right, we are all wrong. That is about the only text that will get the troll-like behavior to cease in such discussions.
One can spend hours debating with turds, it's rather pointless.
No one is saying you have to change your system. That's just your incorrect inference.
We are however talking about what we think is most efficient working practice long term to help Bob who asked about such things. As a result he can now see some potential issues with his non-date system
You are welcome to carry on with whatever system you like as that's your problem not ours.
In fact we would be foolish in encouraging you to be more efficient as they would mean you'd have more time to post on here. ;D
-
Bob, as the OP, you gaining anything here within the last page or two or is this just moving towards another waste of time?
It has become a waste of time with name calling and endless repeating of the same arguments. I was hoping someone new might join in with additional knowledge or perspective. Now, if they did, they might be unwilling to participate.
While I agree with John that there are such things as "best practices," not all choose to follow them or even agree with them. That's their prerogative. In my mind DAM, like so many other things, requires practitioners to understand the rules before attempting to break them. This thread was my attempt to understand those rules so that I could make my own informed decisions about my system and approach. My switch from Aperture to Lightroom made it a convenient time to consider another approach.
It's important now, and may be again in the future. Lightroom still doesn't feel "just right" to me. If, and that's a big if, Apple's new Photos app started with the many good features of Aperture and then expanded them (to the cloud, with 3rd part non-destructive plug-ins, or something), I may well want to be in a position to move back. I will not be deleting my Aperture library for quite a while.
-
No one is saying you have to change your system. That's just your incorrect inference.
Not a thing incorrect about it as far as I'm concerned! And your system as I said repeatedly is equality incorrect for me.
We are however talking about what we think is most efficient working practice long term to help Bob who asked about such things
Let's see if Bob finds this discussion useful as presented in the last day. He has a system, he seems more than OK with it. Other's here have said in no uncertain terms what you and John suggest isn't going to work for them. Again, if it ain't broken, don't fix it.
-
This thread was my attempt to understand those rules so that I could make my own informed decisions about my system and approach. My switch from Aperture to Lightroom made it a convenient time to consider another approach.
Agreed and I think at this point, the rule is, there are no rules if the system makes sense to you, it works for you, you have flexibility in changing the workflow as you move forward. Even jjj said he used to use one system and changed it, indicating:
1. He got it wrong for him.
2. He was able to move forward to another organizational system.
As I wrote, don't let FUD proponents give you an idea that everything is fine then one day, your system blows up in your face the next day. Even if you run out of room on a drive, there are simple ways to move forward.
Lightroom still doesn't feel "just right" to me. If, and that's a big if, Apple's new Photos app started with the many good features of Aperture and then expanded them (to the cloud, with 3rd part non-destructive plug-ins, or something), I may well want to be in a position to move back. I will not be deleting my Aperture library for quite a while.
That is telling! It indicates you need a system that doesn't depend on Lightroom, you might move elsewhere. I love LR and plan to use it as long as I can but there's no way I'm building a system that would break if it went away, died while I needed to find photo’s and so on. Hence the reason I use a well structured (for me) folder system. It's why I would never use Kelby's suggestion of dumping all or even most images in one folder and using proprietary collections to find them. As I said, there's a balance IMHO between one folder and 1000 folders. That balance is understood by me and no one else. And the same is true for what you do. And that's the bottom line. Unless folks here can describe how on one day, everything is running fine and as you expect then the next you've got an impossible to fix mess, I think you should move ahead with what you feel works best for you.
-
It has become a waste of time with name calling and endless repeating of the same arguments. I was hoping someone new might join in with additional knowledge or perspective. Now, if they did, they might be unwilling to participate.
While I agree with John that there are such things as "best practices," not all choose to follow them or even agree with them. That's their prerogative. In my mind DAM, like so many other things, requires practitioners to understand the rules before attempting to break them. This thread was my attempt to understand those rules so that I could make my own informed decisions about my system and approach. My switch from Aperture to Lightroom made it a convenient time to consider another approach.
It's important now, and may be again in the future. Lightroom still doesn't feel "just right" to me. If, and that's a big if, Apple's new Photos app started with the many good features of Aperture and then expanded them (to the cloud, with 3rd part non-destructive plug-ins, or something), I may well want to be in a position to move back. I will not be deleting my Aperture library for quite a while.
If you ever used Aperture in a managed mode ... you would see that even Apple adopted the year, month, day approach for file/folder structure. Not saying you should do likewise ... just pointing out that there was likely very good reasons those engineers chose that approach. Scalability, applying future updates and consistency to name a few ...
-
Well seeing as you selectively quoted a post to take it out of context and are forever misinterpreting people's posts, maybe you should try reading posts more correctly.
Stop misrepresenting my and other people's views.
The text you wrote is provided exactly as you wrote it. If you think I or others are misrepresenting exactly what you write, do a better job of writing!
You love to use the ridiculous term selectively quoted or misinterpreting people's posts whenever you have no argument to back up your point of view it would seem.
-
See ButchM's explanation above. Further, do you change the filenames when keywords change?
Butch's explanation doesn't address the problem at hand; the purpose of doing all this crazy file-system organization is so you can access your pictures quickly and easily outside the DAM.
There will be a day, due to Adobe, or Apple, or on your own whim, where the information in your DAM will be inaccessible (for whatever reason...for example from another device your DAM doesn't run on). When data becomes silo'd, you will be faced with the problem of how to get that information out, either into another "black box" or into a form that can be accessed independently. The fact that everyone here does some degree of organization outside the DAM proves that there is a need to access these data outside the DAM.
Logically, your OS is a DAM, though one not necessarily optimized for managing or accessing data associated within (mostly proprietary) image formats. Despite this, there are steps you can take to work around these limitations and provide you with the means to access your data using the tools your OS provides. Naming a file by date vs. naming a file by subject (keywords) is a difference in degree, not a difference in kind. My point is that while date-based naming provides some information about the image, that data is already available via create date, modification date, and capture date...AND that date-based naming tells you nothing about the subject...which is really the only "interesting" thing I'm interested in when looking for images.
PP
-
If you ever used Aperture in a managed mode ... you would see that even Apple adopted the year, month, day approach for file/folder structure. Not saying you should do likewise ... just pointing out that there was likely very good reasons those engineers chose that approach. Scalability, applying future updates and consistency to name a few ...
It's the old DAM mantra - folders purely for physical storage, metadata for organisation. I just think they went too far by entirely hiding folders!
-
It's the old DAM mantra - folders purely for physical storage, metadata for organisation. I just think they went too far by entirely hiding folders!
Yes, the Aperture Library package is arranged with the image files stored in a folder-by-date hierarchy. The good thing is that Aperture automatically attached some internal "metadata" about what project you had put them in. Lightroom makes you do that step yourself (by creating collections).
I wonder when Krogh's DAM book came out, perhaps the Aperture team read it!
-
I think they came out around the same time, Bob, and the hidden folders were quite counter to the book's buckets system. Apple lifted much of its DAM design (and software engineers and product managers) from Extensis Portfolio.
-
I think they came out around the same time, Bob, and the hidden folders were quite counter to the book's buckets system. Apple lifted much of its DAM design (and software engineers and product managers) from Extensis Portfolio.
Yes, the hidden folders made a lot of people crazy and Apple was pretty quick to relent and provide the referenced library system so that folks could have folders they could see on the desktop. It was a little odd, to me, to hear all of the complaints because the "hidden" folders were only hidden to those who didn't want to right-click on the package and use the Show Package Contents command. :)
-
In fact I was only thinking about the referenced model, Bob, and I'd forgotten the reaction to 1.0. As an aside, I was at the UK launch of Aperture and remember the presenter saying he was getting into it not because of what is was, but because of "what it would be by version 3"....
-
Not a thing incorrect about it as far as I'm concerned!
Dear me. Seeing as I haven't been trying to get you to change systems, you are most certainly incorrect in inferring that I have. If you keep trying to argue otherwise you really are a lost cause.
-
Thank you to all who added something constructive to this conversation. Everyone need not agree.
I've assembled my learnings and plans from this thread onto my blog: http://www.bobrockefeller.com/blog/dam-in-lightroom-from-aperture
That post will help me remember the pros and cons of the arrangements.
-
The text you wrote is provided exactly as you wrote it. If you think I or others are misrepresenting exactly what you write, do a better job of writing!
You love to use the ridiculous term selectively quoted or misinterpreting people's posts whenever you have no argument to back up your point of view it would seem.
Selectively quoting is quoting part of something which changes the context of the partial quote, not misquoting which is a different thing again. You repeatedly misread and misinterpret posts which is why I keep having a go at you for it, no other reason. Anyway I've had enough of your childish behaviour as I shall alter the settings to hide your generally insulting posts and be done with your nonsense. Debating with you is like wrestling with fog as Rob C once said. Your relentless stupidity is why so many people on here get exasperated with you and in the real world too, so I gather.
-
Selectively quoting is quoting part of something which changes the context of the partial quote, not misquoting which is a different thing again. You repeatedly misread and misinterpret posts which is why I keep having a go at you for it, no other reason. Anyway I've had enough of your childish behaviour as I shall alter the settings to hide your generally insulting posts and be done with your nonsense. Debating with you is like wrestling with fog as Rob C once said. Your relentless stupidity is why so many people on here get exasperated with you and in the real world too, so I gather.
Agreed Isaac, Troll. It's my fault again, it figures.
-
Thank you to all who added something constructive to this conversation. Everyone need not agree.
I've assembled my learnings and plans from this thread onto my blog: http://www.bobrockefeller.com/blog/dam-in-lightroom-from-aperture
That post will help me remember the pros and cons of the arrangements.
Interesting post, but your list of cons is not accurate.
"There are a few drawbacks to the folder-by-date system, however:
Finding an image outside the DAM application requires knowing the date the image was taken; something few people would remember.
Using Lightroom, you would have to create collections to group the files in any other way but by day. Aperture did that for you using it’s virtual concept of a project."
The first issue is wrong as I can certainly find things outside of LR as I use date + description and used Bridge for many years as my organiser which is a file browser not a database like LR/Aperture. Plus because I use a date system it helps me to recall dates of when things were done. Also criticising a system designed to be used in conjunction with a DAM for how it works without a DAM is a bit daft. It's like criticising LR for not being able to edit Word documents. :P
Second point - there's no problem in using collections to collect images by whatever criteria you want. That is exactly what they are meant to do. And as you demonstrate on your blog you can do exactly the same with Folders as you can with projects, there's no real difference. So what's the problem there? It's not like Aperture can read your mind and automagically create sub folders in Aperture for you with the right names ???
I think the main issue is the fact you are used to working in Aperture and LR does things much the same but with alternative names to what you are used to which makes you think things are more different than they actually are.
-
JJJ, Do you have much experience in using Aperture?
-
I was very excited when Aperture first came out as it looked like it would solve many of the problems of dealing with large numbers of images. Sadly v1 was not only very buggy but couldn't even import my already large and well organised folders - which is what killed it's initial uptake amongst photographers in my view. LR tried the something similar in very first beta but was quickly changed to also use referenced folders after feedback. Apple finally relented as well later on. I kept Aperture updated and used it regularly, but it was still too clunky and messy compared to LR's clean and efficient interface. Aperture seemed to become more like 1990's software as time went on whilst LR polished their modern interface that was more thoughtfully designed. I really liked Ap1.0 looks wise but later versions feel like a dogs dinner.
I actually spent quite a bit of time with Aperture recently and its still clumsy and inefficient. For example Photostream projects [or folders in any other programme] are incorrectly named.
They are date named but not in a sensible/usable way as they are Oct 2013 Photostream, November 2013 Photostream and so on and are randomly scattered through my projects. If I put them in a folder to contain my various Photostream projects then they will not sort correctly as seen in first screengrab as April 2014 comes before Dec 2013 and so on. Second screengrab shows correct sorting after I tediously had to manually rename files so they would sort correctly. This is a really basic mistake and just shows how unfriendly Apple are to such basic ways of filing.
The other issue was that LR leapfrogged Aperture in processing quality a while back.
-
In the first example the sorting is in alphabetical order. Works for some things (like names of songs) but definitely not for this purpose.
-
Thank you to all who added something constructive to this conversation. Everyone need not agree.
I've assembled my learnings and plans from this thread onto my blog: http://www.bobrockefeller.com/blog/dam-in-lightroom-from-aperture
That post will help me remember the pros and cons of the arrangements.
One thing you don't mention at all is the Library Filter panel, which I don't think has an Aperture equivalent, and it's behind my suggestion that LR users tend to make more use of IPTC fields than Aperture users. Rather than a folder/project system recording where photos were taken or the location they depict, you're putting the information into the 4 main IPTC location fields and then using the Library Filter to slice and dice the pictures in a more ad hoc fashion. The left panel might still include some geographical structure, but there will be fewer containers - so I wouldn't have a left panel list of all geographical locations, just smart collections for frequently-used groupings such as "country = USA" or "state contains Maine or NH or RI or MA". These standard fields will also migrate well to other systems.
John
(https://dl.dropboxusercontent.com/u/7678369/filterpanel.png)
-
John,
Very true. The Library Filter is a helpful too and I use it a good bit when searching for images across my library. I always used the IPTC location fields and consider them to be important metadata, even if I have the image in a folder-by-location hierarchy.
In Aperture I used to use its Filters in a similar way. Aperture offers a few more options for filtering, and doesn't take up any screen space while active.
I don't use a filter like that much while working on a new set of images. My brain still works better with the folders-by-location and a temporary •Imports folder to hold current work.
But my "location" is never based on the location in the picture (subject). My "location" is simply where my feet where when the picture was taken; I find that to be as unambiguous and imutable as the date the image was taken.
Maybe I will have to learn, but I don't like collections that much. I use them if I have a special purpose, such as a photo book, a set of images for a client or some such. My biggest two gripes are deleting images from disk while working in a collection and their "split" from the folder pane so I have two panes for looking at image groups. I know, I know it's probably my Aperture-brain talking, but still.
Too bad we're on different continents, I think it would be fun and educational for us to sit together in front of a computer and exercise Lightroom and Aperture "going through the paces!"
-
Yeah, it would be pleasantly argumentative!
It's hard to be sure, but I think I use the Filter Panel much more actively or ad hoc in LR than I think I would use the Aperture equivalent. I will often hide it by pressing the "\" key and I have a number of sets of columns saved - just like the one in my screenshot. The Filter Panel tends to be more of a tool for exploring metadata and drilling down into it, similar to Excel pivot tables if you're familiar with them, so for instance I found a few cases of "Unknown City"
The problem with location fields has always been consistency. Individuals can certainly be consistent and can stick to a "where I stood" or "what's shown", but people change practices over time or make exceptions. Neither is really satisfactory - which is why there are two fields in the IPTC Extension (which no-one ever uses!).
I don't find collections totally satisfactory, and I've never been a big fan of how delete works. I like how Aperture albums hang off the project, and how you can drag a smart album to another source, and in LR it can certainly be a pain to have related folders and collections in two panes. The bigger the catalogue, the more this is a problem. An Aperture-style merging of the two panes might work, though I feel the way forward is for a "left panel filter" which filters all your folders and collections in the same way as the little filter panel at the top of keywords. Progress comes at glacial pace (though at least nowadays the glaciers move faster, if backwards).
-
Butch's explanation doesn't address the problem at hand; the purpose of doing all this crazy file-system organization is so you can access your pictures quickly and easily outside the DAM.
There will be a day, due to Adobe, or Apple, or on your own whim, where the information in your DAM will be inaccessible (for whatever reason...for example from another device your DAM doesn't run on).
The whole purpose of DAM is to allow the data to be independent of a specific software solution ... As I recall that was the main theme of Krogh's book. Establish a solid foundation that can be scaled to grow into what may come next.
if you are saving your metadata back to the individual image files ... many other options other than Adobe can utilize at least most if not all of that data. It can be used regardless of what type and how many containers you choose to store your image files within. For example, I employ Media Pro for my long term archive and primarily only use the DAM portion of Lr or Aperture until a job has been completed and delivered. I also have little trouble seeking out and accessing images using Spotlight or Finder searches.
It seems to me if you know you are going to have to invest the effort to keyword, label and rate the images no matter what, sorting the images into category based folder structures can be a bit redundant.
As I said before, it matters little to anyone else other than you how you set up your DAM folder structure ... though sooner or later the sheer quantity of images you will have accumulated will soon outgrow categorizing by subject matter specific folder storage. Sooner or later you run out of cross referencing options ... Like back in the day of dealing with negatives and slides ... you still needed a catalog that could take into account all the criteria pertaining to that image so you can put your hands on the images required in short order.
Streamlining the process without sacrificing accuracy and efficiency is important to me. The more time I spend with a mouse in my hand means I'm spending less time holding a camera.
-
I don't use a filter like that much while working on a new set of images. My brain still works better with the folders-by-location and a temporary •Imports folder to hold current work.
Same for me. I have a few saved filters, but far less than Smart Collections. And what's up with the disconnect between the two (SC's and Filters)? You'd think the two would be functionally equivalent in terms of what we can search for. For example, I can search a SC for "source color mode" but not by filters.
-
Same for me. I have a few saved filters, but far less than Smart Collections. And what's up with the disconnect between the two (SC's and Filters)? You'd think the two would be functionally equivalent in terms of what we can search for. For example, I can search a SC for "source color mode" but not by filters.
Yes, odd. Filters and Smart Albums in Aperture appear to use the same underlying engine; you can search for the same stuff in both.
-
Bob,
For a good discussion of library organization check out George Jardine's article at http://www.digitalphotopro.com/technique/software-technique/heresy-in-library-organization.html#.U-lhBGPw3ew (http://www.digitalphotopro.com/technique/software-technique/heresy-in-library-organization.html#.U-lhBGPw3ew)
It's a clear discussion of why he organizes his library the way he does.
Les
-
if you are saving your metadata back to the individual image files ... many other options other than Adobe can utilize at least most if not all of that data. It can be used regardless of what type and how many containers you choose to store your image files within.
iirc there's a problem with lack of standardization on the syntax used to represent hierarchical keywords in image meta data.
-
iirc there's a problem with lack of standardization on the syntax used to represent hierarchical keywords in image meta data.
Perhaps that is then a good argument against not implementing hierarchical keywords ... at least until there is a standard set and accepted.
-
Perhaps that is then a good argument against not implementing hierarchical keywords ... at least until there is a standard set and accepted.
Not really, Butch. You could use the same argument against a number of fields (eg colour labels, flags) which are widely available but not standardised, and you'd be waiting forever and a day for a standard to be agreed (eg IPTC Extension fields) and then implemented in the application you happen to use (eg IPTC Extensions and Aperture). Metadata is an imperfect world, and in that environment you have to make yourself aware of the details of what things work now and how they can also screw other stuff up! I'm not a big fan of hierarchical keywords, but that's not because of the lack of standardisation.
-
Perhaps that is then a good argument against not implementing hierarchical keywords ... at least until there is a standard set and accepted.
fwiw I wasn't talking about "a standard set" but --
You’ll notice that I’m using the “/” character to separate the various levels contained in a keyword. The choice of the separation character (http://gcoupe.wordpress.com/2012/03/21/lightroom-4-a-mixed-blessing/) is arbitrary, some applications use the period (“.”) or the pipe (“|”) character , since there is no industry standard at the moment.
-
In the first example the sorting is in alphabetical order. Works for some things (like names of songs) but definitely not for this purpose.
Sorting is alphabetical in both cases. It's just that Aperture labels Photostream folders stupidly considering how computers sort things.
-
Just as another data point, Matt Kloskowski, of Kelby Media and at Lightroom Killer Tips, offers his ideas about organizing your Lightroom library, not by date, but by topic.
It's item 2 in this post:
http://lightroomkillertips.com/5-lightroom-organizing-mistakes-and-how-to-avoid-them/?utm_content=bufferd612d&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer
-
Just as another data point, Matt Kloskowski, of Kelby Media and at Lightroom Killer Tips, offers his ideas about organizing your Lightroom library, not by date, but by topic.
Matt is agreeing with what you and I have been saying all along Bob.
But that's all wrong.
-
Just as another data point, Matt Kloskowski, of Kelby Media and at Lightroom Killer Tips,
Yeah, Matt and Kelby really are the first people you'd go to for DAM advice, colour management too.... /heavy irony
-
Yeah, Matt and Kelby really are the first people you'd go to for DAM advice, colour management too.... /heavy irony
Like I said, just another data point. But, for better or worse, Matt is a well-known Lightroom instructor. That doesn't make him right or wrong, it just means he has heard and seen more than I have, at least.
You don't think he's drinking buddies with Peter Krogh? :)
-
Matt seems one of the more measured guys in the Kelby business, Bob, but their strengths have never been in DAM and I wouldn't consider it much of a data point. Someone like George Jardine is a more credible source - see this post (http://mulita.com/blog/?p=4339) for instance.
John
-
Like I said, just another data point. But, for better or worse, Matt is a well-known Lightroom instructor.
What did I tell you Bob, wrong data point and you're wrong. Stick to doing what you prefer doing, or tell those who do things differently what they want to hear.
Here's something George wrote that we all (well most of us) agree on:
The important thing (in the short run…) is that you can find your photos.
Anyway, back to digital photo libraries. Earlier I said that the folder organization you use doesn’t matter, as long as you can find what you’re looking for. And that truly is the heart of the matter.
-
Selective and misleading quotation - what some people specialize in, eh?
-
If you have a DAM and rely on your folder structure to find your images, you might not have realized the full potential of a DAM. I cannot think of a possible folder structure that cannot be related to metadata. Think the other way around: with metadata, the folder structure of your image collection is the one you decide at any time.
In the case of LR, there is nothing obscure about it or LR being a "blackBox". The LR catalog is an unencrypted, unsecured relational database that can be accessed by a broad range of applications. By having a LR catalog (not the application) it would be possible to write a script that recreates a new folder structure (based on metadata), move the images to the appropriate folders and create corresponding xmp files if not using DNG.
You can hammer a screw, but I would recommend to use a screwdriver
-
Selective and misleading quotation - what some people specialize in, eh?
Selective? Oh yes, seems pointless to copy and paste George's entire article when you yourself referenced the link as something you think backs up your opinion. Misleading quotation? Only if as I suspect of you John, you have difficulty reading and comprehending English. The text George wrote that I pasted from two areas in his article stand on their own. George is saying what I said pages and pages ago, post #2 in fact (exact quote): So my point is, build your organization based on what works best for you.
George is a good friend and wine drinking buddy, maybe I have to pull an Annie Hall moment on you (https://www.youtube.com/watch?v=9wWUc8BZgWE). The two sentences he wrote are as clear as the noise on your face and I really doubt he'll say he doesn't mean: the folder organization you use doesn’t matter, as long as you can find what you’re looking for. And that truly is the heart of the matter.
That George's writing backs up what I and other's have said, indicates you should treat him like you did Matt (dismiss him out of hand). But since you linked the article as recommended reading, the hypocrisy of your POV is pretty clear.
Bob, here's the bottom line. As the OP you can close down the thread. John will never agree with what Matt, I, George and other's have said here. In fact, what he's stupidly proposing is the opposite: use a system even if it doesn't make sense to you. Just look and read his last few posts? He dismisses Matt outright because he doesn't agree with him. He then stupidly references an expert who's piece he appears not to have read or understood. Then when in that piece, the expert he wishes he were states clearly that the folder organization you use doesn’t matter, as long as you can find what you’re looking for, he's got the balls to suggest that isn't what George meant and it's misleading!
Again, don't do what makes sense to you as most have suggested, do what John says. They 'you'll be right' in his eyes. The data points he just provided backs up what you have been saying all along! Maybe John can scour the web and find some 'expert' with his chops that writes "don't use folders to organize, and build your organization based on what doesn't works best for you".
Selective and misleading quotation - what some people specialize in, eh?
What an utterly foolish thing to write John.
-
You can hammer a screw, but I would recommend to use a screwdriver
Agreed with your points before this. No one is suggesting we rely on a folder structure, it's another form of finding your images if you can't use a DAM or you wish to migrate to another. Or to answer your quote above, if you don't have that screwdriver, that hammer is a heck of a lot better than using your bare hand! Obviously if you have the screwdriver, use it. If you have an electric screwdriver, maybe better yet.
-
Enough. We've gone far enough off the rails.