Bri W

Even if you've never used this before, not sure how anyone could watch Neil's video and not think oh yeah, we need that! 🙂

IMatch and PhotoSupreme handle this by having a server addon (the former) or version (the latter). This way you access your database from anywhere without having to pay for storing a huge set of files online. I have yet to really look into that for myself. The part where I save on cloud storage is appealing.

I'm talking about The Metadata Working Group standards set by Adobe, Canon, Apple, Microsoft, and Sony. Ratings are part of that standard and it specifies -1 for rejects and 0-5, if no rating is present 0 is supposed to be assumed. IPTC provides for extended data, which also have standard places in XMP or the legacy IIM. Some DAMs will read IIM and sync it to XMP. XMP is an ISO standard, there are name spaces provided. Yes the X is for extensible, but it is stupid when programs like ACDsee ignore the name spaces already there and create their own. If users decide to switch, they have to use EXIFtool or other tools inside the new DAM (which often rely on EXIFtool) to change those tag names. Hierarchical keywords are the sticky point. There is a MWG standard but it seems no one really likes it from what I could find. EXIFtool supports it. The closest we have to a standard in use is writing them to XMP:XMP-LR:HierarchicalSubject. Since Lightroom is the 800 pound gorilla, whether we like it or not, that is an unofficial standard. It's what Imatch and Daminion use and I'm sure others. EXIFtool also supports it. ACDsee use their own proprietary name space again and you have to tell it to sync to flat and then it only syncs the leaf. You should have control over how hierarchical keywords are written to flat keywords, since outside your DAM, it is the flat keywords that will most likely be used. Again there are standard named spaces in XMP for flat keywords. I actually like how Capture One supports XMP more than how LR does despite C1's weaknesses in keywording. LR is just write it or don't. I have C1 set to load XMP. Since I write all metadata in IMatch I don't want C1 writing over it with it's more limited features for metadata. I do want to be able to filter with the ratings, labels, and keywords that are in the XMP sidecars. Since C1 doesn't use XMP to store develop settings like LR, I don't lose anything by leaving it on load only. There are pros and cons for storing the develop settings in XMP, the main pro would be less sidecars to worry about. A strong DAM can make sure sidecars stay with the master file as long as you move them in the DAM. The con is as I mentioned, when both metadata and develop settings are stored in the XMP, you risk overwriting the metadata with a weaker tool.

The problem I see in most of these posts is the requests are for another limited photo manager/processor a PAM or PAMP. Lightroom is far from the bar a real DAM solution should reach for. A full featured DAM does not hinder its use for photos only. I agree LR is probably the standard for photo manager/raw processors, but it too falls short even in that limited scope. LR does HDR but saves as a DNG, another attempt to lock you in. The standard is openEXR or older and more limited .HDR, some of us care more about that "super raw" than the tone mapped/fused byproduct (which by the way is no longer HDR). A real DAM needs to follow standards, the metadata needs to be written to the correct sections of XMP (Extensible Metadata Platform), yes that means sidecars for files that don't allow embedding the data, like raw files. When standards are followed, any other program that also follows standards can read it and use its functions to sort and search on it. All proprietary metadata should be easily extracted for remapping to the next DAM. Nothing should be locked into that particular DAM. At the very least it should handle graphics files, but that's just a GAM Steve said: The use of a database should not be required. However, if there’s just no getting around it for whatever reason (speed of searches, etc.), then perhaps the DAM could recreate it knowing only the root directory where all photos are stored. Of course, this might take awhile. Yes, speed of searches is why you need a database. Following XMP standards would take care of the second part if the XMP was written to standards in the first place at least for EXIF, IPTC, and hierarchical keywords. I agree that it should be a referenced database that leaves all files where you want them in your file system. Steve also brought up mapping and location tags. Again I have to bring up IMatch. I create location boundary on the map, then fill in all the location data for the IPTC section of XMP. I also can specify keywords to be written. I have my own location hierarchy in keywords, and some locations may also have keywords written unrelated to the location branch but always wanted for that location. I can use the GPS data if present or drop the photos on the map and even add direction of view. From there all the metadata is written and I'm in full control of all of it. I never use reverse lookup. It is too often wrong and/or not granular enough for my desire. Don't confuse XMP or other sidecars with transferring your raw conversion. Yes, some processors store the recipe for conversion in the XMP, that can serve transferring the raw in its parametric edited state to the same processor in another location. Yes some raw processors will attempt to translate that recipe to its own "kitchen" People need to understand the fact that each raw processor has its own selection of tools, and even if the tools have the same names they work differently. If they all worked the same, only the subjective attractiveness of the UI/UX would differentiate them. That is not the case, and it is a blessing and a curse. If you want a permanent copy of how that photo looks as edited in the raw processor of the moment, export it to jpg. or better 16 bit tiff. The non-destructive parametric editing we love about raw processors is the reason only that processor can read, write, and properly "cook" the recipe. If you want to use a different processor, start over. Look at it as an opportunity to do better. This is also argument one for separation of DAM and processing. Hierarchical keywords of course. Those that don't need them, don't use them, but without them a DAM it isn't. It should support import and export of controlled vocabularies. These can be created in app, found for free online, or paid curated lists. Those need to be easily editable. There should be controls for grouping keywords (keywords that are only used for organizing the list such as Who, What, Where, Why, etc.) LR has this. There should also be controls for the mapping between flat keywords and hierarchical keywords, LR doesn't. It should be quick and painless to fix the files where this mapping fails because it will. One cool feature in IMatch that I've come to depend on is color coding keywords. I color code each first level branch of keywords. All keywords under it then have that color. I can see at a glance of the thumbnail if I'm missing branches of keywords. Drilling down hierarchies can be time consuming, so you should be able to start typing and have matching keywords show in a list to speed up the assignment of keywords. Synonym support can help the organization and speed of assignment. Animals are a great example. You probably want the taxonomy, then you often have multiple common names (Puma, Panther, Catamount, Mountain Lion...) Sure you could build all of that into the hierarchy, but then you'd need to remember which did you use for the leaf. Better to use synonyms so that entering one common name applies all and the hierarchy of classification. The lack of synonyms in C1 is what drove me to separate DAM from processing when I dumped LR. Version and buddy file (sidecars like xmp, processor files, even supporting documents) control is vital. This way you can control how metadata is copied to child files and moving the parent also moves the children and and buddy files. Labels are so useful, most programs cripple them. Lightroom gives you sets of labels, you can only see, search, and filter one set at a time. You can change the label text, but not the color. There are only 5 colors plus the white custom label. Capture One has seven colors, cool two more, but you can't change the text or color and there are no sets. IMatch labels allow editing of the color and text. If there is a limit to the number, I haven't found it yet and I have 19. I have labels that match C1, others that I use for stages of workflow outside of C1 or non photo files, and others that match my main set from LR. I can see all of these labels in the IMatch viewer and thumbnail windows. I can quickly click on one in the collections list and instantly filter my view and I can use them in complex filters that combine other metadata. The point is in a real DAM I can make it work with the limitations of LR, C1, On1.... both to read the labels they can write or write labels to XMP that they'll read and filter on. I think Affinity can come up with a number of ways to make the raw conversion more like dedicated converters. Maybe something like a raw adjustment base layer that brings up the develop persona when selected with the settings always adjustable. They could facilitate copying raw settings in a number of ways without creating a PAM/PAMP/GAM or best of all DAM. If they do create a manager I hope it isn't as limited as the majority of requests on here are asking for. At the very least it would have to support all files types the current suite can edit. It must follow XMP standards so that if it didn't write metadata with the control and flexibility of IMatch it could sort and filter what I create in IMatch without mucking it up. I still stand by my post back on page 3, I'd rather they concentrate their resources on Photo, Designer, and Publisher. All amazing version 1 products. I look forward to paying for version 2.

I voted no. I use IMatch as my DAM and Capture One Pro as my main raw processor. I think it would take years to catch up to the power of IMatch as a DAM, and I'd rather they put the resources into Photo & Designer. I would like non-destructive raw processing in Photo, and I'd like to be able to copy and paste raw settings on a batch of photos, but neither would be top priority. I once thought all in one management and processing was a great idea. I no longer think that way. LR is a rather weak DAM and it may be the best of the bunch in that regard compared to the other be all photo raw processors. Same goes for HDR and Pano. I wasn't even happy with the raw processing in the end which drove me looking for another does it all solution. I finally realized I already used a handful of specialized programs for HDR. I used PTGui Pro for panorama stitching with Affinity for finishing. So I changed my search to finding the strongest, most open DAM and a raw processor that was fast, had great color editing, and tethering. IMatch and C1 won out. Since I manage everything in a dedicated DAM, I don't hesitate to process a raw in Affinity, or DPP if a certain image just isn't getting there in C1 (rare). Maybe I'll add DXO for it's reputed noise and geometry handling. Photo and Designer are great v1 programs, I look forward to them getting even better.