Actually, just to expand on this, any edited image including Jpeg, DNG and TIFF will remain untouched since there is no save feature in PhotoLab and to burn in edits made to any file type requires an export to a newly created file. And yes, I regularly backup my images. .
Mark
Not brave, just confident. In five years of using PhotoLab on a daily basis I have never had a problem and still have all my virtual copies all the way back to PhotoLab 1 unless I have chosen to delete them. If necessary, I can always retrieve almost anything I want from my daily updated backups of my computer which includes image files, .dop files, .xmp files and the database. However, your requirements may be different than mine and I would never presume to tell you to stop doing something that works for you.
Mark
@mwsilvers Not absolutely true if you factor metadata into the mix!
The image will remain unchanged and intact but the file won’t if you write any metadata back to a JPG, DNG or TIFF.
In truth the only reason any file changes with any editor is if that file is overwritten, i.e. some of the more “brainless” packages seem to want to write the edited file back to the same directory with the same name, a “default” strategy that I have never understood!!
Prior to PL5 DxPL basically changed nothing with respect to the external image (except being able to delete the image or change the image name) but that changed with respect to metadata from PL5 onwards and I am glad to see that your daily backups of image, DOP and XMP sidecar are there to help keep your images and edits safe!
My metadata requirements are significantly less than many people here, which is why I have not gotten terribly involved in the ongoing discussions of PhotoLab’s DAM. PhotoLab is my primary editor, and I do not share or update metadata with any other applications. I certainly understand all your points with regard to metadata, My comments were solely based on image editing, nothing more.
Mark
@mwsilvers I understand your situation (or rather a “lack” of a situation)!
The problem comes if metadata is used to effectively “rename” an image (and to store any “notes” and “comments” about the edits applied to an image - my scenario) because it raises the issue of whether that metadata should be kept within DxPL (which is possible) or “externalised” to be visible in any other software capable of displaying IPTC data!?
That comes down to what @cpcanada wants from the “renaming” and how widely that data should be made visible (or not) and whether the IPTC fields are already in use etc. etc.!?
For that feature you need to have a well-thought DAM integrated into a package with a well made RAW converter. This is what most DxO customers are highly allergic to, my guess is, they never experienced what this app could do. And I don’t think or know if such an app is around these days, my attempts in LR onyl showed me the horrific workflkow Adobe’s developers appear to have in mind. Since Apple buried Aperture, it’s only workarounds and poorly made efforts around.
And by the way, renaming pictures without renaming files might be one approach, but using metatags and albums/projects would probably bring you closer to what you like to do. Anyway, nothing around for that
this ties back to my wish/request for having a feature that pushes the original image file name into a keyword field…
One problem with many metadata aware applications like many RAW-converters is that they still work internally with IPTC and IPTC is frozen and not extensible like XMP.
Using a “standard” field/element for something else has a cost in increasing confusion. It results in building your own metadata “bubble” instead of making the data usable more widely.
As many here already know most of us are “locked in” in IPTC but with XMP where the X stands for Extensible (possible to expand as I reda it) it would be much better if the RAW-converter manufacturers stared to open up for real XMP-compatibility because then you could separate your own “Image ID” or “Image number”-fields/elements from the standardized fields. I saw that technique being used during my years in the museum world. In that case the museum defined their own namespace instead of contaminate the IPTC-standard fields. That is a better solution, I think. Then it´s also possible to still use the Keyword-field in the IPTC-schema in the IPTC-namespace for the “flat keywords” used in IPTC-implementations in several software-solutions.
Of the same reason I think it´s problematic to use the Dublin Core standard element “Subject” for private hierarchical keywords of a kind not compatible with the Controlled Vocabularies of the IPTC recommendations. You can read by yourselves below.
Using the IPTC Subject Scene and Genre codes with your Controlled Vocabulary Keyword Catalog
With that said people has used dedicated fields in their SQL-databases too for all sorts of data long before people starting to do the same with IPTC-data. That also has caused a lot of confusion over the years in many situations when their application forms had field labels in their databas application forms that didn´t correspond at all with the data in those fields. This also often causes challenges in migration scenarios when old systems data has to be converted to fit he needs of new ones. The problem is that the people who decided about these unconventional uses of these systems fields often are gone since decades and might even be dead. Many systems are also poorly documented.
You can do that with the system of “variables” in Photo Mechanic even if it´s nothing I would recommend.
Wouldn´t it be a better idea to just put a line at the bottom of for example the Description-element (something like: “Filename: {filename}”
If you ask for a flexibility like You seem to do you can´t expect it to be found in general tools like Photolab. For that you need something more flexible like Photo Mechanic but it will come with a price because these tools have a much higher learning curve. But if people are prepared to spend a couple of houndred dollars extra and are prepared for that challange they will find they will get a far more effective metadata tool than Photolab.
With PM Plus you can rig it to use a template like the one above that does all this automatically when you ingest/import your images into Photo Mechanic (that process just leaves the images where they are in your folder but creates previews and indexes the metadata automatically)
As I have written before Photo Mechanic integrates very well with Photolab as long as you just maintain the data in PM and never in Photolab and that you use a flat keyword-structure and not hierarchical keywords.
I’ve just noticed you’ve posted in the Mac forum, so I assume you are running a Mac.
In which case, why not use Finder tags to add names and other info to your files?
You don’t need any other software and the Spotlight search will allow you to search for files you have previously marked.
@Stenis I picked the ‘IPTC’ fields for a specific reason, there are a lot of them which I don’t use so “high jacking” the odd field or two might be “useful” particularly if it is possible to find one that might be (vaguely) appropriate to this particular scenario.
I do understand the risks you identified and would never propose such a “solution” for anyone that is using the IPTC data with a serious intent, or at least to use the most “obvious” fields that are not currently required by the user!
For private use it should be O.K. provided the images are not destined for “publication” or the metadata is actually going to remain in DxPL, i.e. AS(OFF) {or MS(OFF)} and no ‘Metadata’/‘Write to image’ is executed!
As you identified that comes at a price!?
@Sparky2006 Not exactly Auto keyword embed original image file name requests the opposite, i.e. embed the original name in the metadata because you want to rename the file but retain the original name for reference purposes.
This request is to allow a “pseudonym” while retaining the original name (for the purpose of preserving any such references).
In my case I have multiple backup copies and the software I use will allow my to synchronize, when I will wind up with duplicates with the old and the new names, or Mirror when I will wind up overwriting DOP (and Xmp sidecar files) and images files for JPGs, and yes I do understand the notion of preserving multiple versions of the same data but when you changes file names then …
@Joanna are Finder tags visible in DxPL(Mac)!?
Because I use DxPL(Win) I was looking for a “solution” (workaround @JoJu) that would work for all users, including me, for this particular “issue”, and chose to suggest adding “clutter” to the IPTC metadata rather than the keywords!
Not an uncommon trick to avoid the need to re-organize a database, either as a permanent feature or as a temporary measure until a proper re-organization could be scheduled! One of my customers had the entire U.K. households on file!?
Of course not. But, since one is not restricted to using PL for everything and many people use external DAMs, I thought, why not use the ultimate free DAM - otherwise known as macOS Finder?
If you don’t specifically want keywords for compatibility with other DAMs, I see absolutely no need to spend out on alternative solutions.
I’m sorry if that disadvantages Windows users but this kind of in-built utility is one of the numerous reasons why Macs might seem expensive until you realise that they already contain software that Windows users end up paying more for 
I have never used PL’s DAM simply because I don’t need to.
@Joanna I understand that!
Although I purchased IMatch last Christmas, when it was on offer, if I want or feel I need a DAM then I need to spend some money when on the Windows platform
To be honest I have never felt at a disadvantage using Windows, the restrictive nature of the Mac with respect to hardware has meant that it has always been a no-go area for me, all my desktop systems bar one have been own built (laptops excluded).
I will admit that the emergence of the M1 is about the only thing that has made me feel “envious” and it is doing great service for my youngest son who is a videographer now that Premier Pro can use it!
But he started with Macs because of Final Cut Pro which he used as his editing platform until, overnight Mac abandoned the professional users, old projects simply could not be used (or so I was told by my son) and it became a “consumer” product.
He moved to Adobe Premier Pro and has edited with that on Mac machines ever since, given that his brother and I both use Windows machines he could have “joined” the family and “benefitted” from joint hardware expertise, his brother builds his own machines when he doesn’t bring the parts to me to perform the upgrade and buy his "cast offs (always fairly priced) but he has an investment in the Mac so …
The Mac is “expensive” because Apple rule that market like … rules … (no politics here)!
Until the M1 I felt there was no advantage only disadvantages!!
Sorry but that was just an example. It depends depends on what you want to do. It is a good practice in DAM-systems to use a Unique ID. The filenamebase can serve as one if the filename is important to you. From what BAYT wrote about having different versions of the same original file I can suggest another solution.
I have also seen some examples where people just want to see the original filename and it´s always there in EXIF just to pick up if you have a more competent metadatasoftware than Photolab. No need for any other actions then. In Photo Mechaninc it´s possible to tailor make the metadata-fields you want to see in the “contact sheet”-view of Photo Mechnaic. As I said, no need to reinvent that wheel if it´s only a matter of seeing.
In the example above you can use: Filenamebase: {filenamebase} instead of {filename}. That can solve many problems.
So, if the filename is “ABCDEF.ARW” the base is “ABCDEF” regardless if anyone changed derivatenamnes to ABCDEF.TIF, ABCDEF.JPE or ABCDEF_1.JPG etc. In that case it can work to save ABCDEF as a unique ID in a special metadata field for that but I would avoid using the Keyword-field for that under any circumstances. Info like that doesn´t belong in that field at all.
@Joanna
It´s nothing wrong to use what you have got but the reason to use other tools than the ones in Mac OS or Photolab is to increase productivity. One of the absolutely most common reasons why people try to use image metadata is that it might be a very time-consuming work if you haven´t got access to really efficient metadata tools. I know from my own experience. I tried first many years ago when I used Lightroom and gave up and I think the first ones to give up many times are people trying to use hierarchical keywords 
So, one question I have to you is if you really use your own application IRL to maintain your own metadata or if you too have given up like many others that have tried to maintain metadata with too dull and ineffective tools? With good tools you are able to automate a lot of the work that you will end up having to maintain manually instead with for example Photolab or for that matter the Finder or what ever you use in your Mac OS.
Tools like Photo Mechanic is not just for dead line ridden sports- or event-photographers but for all that are serious of different reasons about metadata. It´s for people who value their time more than just their licensing money.
@Stenis where in the exif do you think that the file name is preserved? I changed the filename from P1101278 to P11012789 (instead of P1101279 as I had intended) and Photo Mechanic returned the following
So those fields are not getting the value from some deeply preserved metadata field!?
I thought that it would be there somewhere and used a number of programs that pull out all manner of … but no sign of the original filename!? This does not answer @cpcanada’s query but might help with @Sparky2006’s issue but only if the original file name is preserved somewhere already rather than the user having to put it there manually or having a new feature in DxPL to put the data somewhere in the metadata, e.g. as a keyword as @Sparky2006 has requested.
I am sorry but there is nothing the least bit complicated about hierarchical keywords except the fact that all the software manufacturers have their own “take” on what the exact format should be (frequently guided or constrained by what their users have grown used to, i.e. the “history” of the product) so we have conflict between the standards body, and developer A and developer B and … and DxO dropped DxPL into the middle of that and then panicked when certain users complained and made matters even worse!
The risk now is that metadata was “yesterday’s” project and DxO won’t fix the obvious faults and complete the missing features!? But it needs to co-exist with other products because the long established products are not going to change any time soon (probably any time ever)!
I suppose it all depends on how much metadata you want to record. My app is based around Keywords (including hierarchical), Finder Tags (both colour and textual), Description and Rating. So, fairly simple and certainly no IPTC.
Although I could use just Finder, one of the main advantages of my app is that entire folder hierarchies are presented “flattened”, so you can browse a folder and its sub-folders without having to keep on selecting different folders.
And the search mechanism works the same, in that any search is based on the currently selected folder but includes sub-folders. Once search results are shown they can be saved in a “smart folder” for quick recall. Such smart folders can be named either based on the searched keyword(s) or anything else.
All this is fairly much the same as using Finder and Spotlight, just with a nicer UI.
Oh, and I use the macOS Spotlight database, so no problems with synchronising an independent database.
[quote=“BHAYT, post:22, topic:30087”]
@Stenis where in the exif do you think that the file name is preserved? I changed the filename from P1101278 to P11012789 (instead of P1101279 as I had intended) and Photo Mechanic returned the following
So those fields are not getting the value from some deeply preserved metadata field!?
I thought that it would be there somewhere and used a number of programs that pull out all manner of … but no sign of the original filename!? This does not answer @cpcanada’s query but might help with @Sparky2006’s issue but only if the original file name is preserved somewhere already rather than the user having to put it there manually or having a new feature in DxPL to put the data somewhere in the metadata, e.g. as a keyword as @Sparky2006 has requested. [/quote]
Hi, I might have ment the filename and not the original filename. I use to trow my files on EXIF Tool and in that tool the filename is in the first row of what comes up in a just overwhelming number of metadatalines coming up
First part:
Second part:
[quote]
BAYT wrote: I am sorry but there is nothing the least bit complicated about hierarchical keywords except the fact that all the software manufacturers have their own “take” on what the exact format should be (frequently guided or constrained by what their users have grown used to, i.e. the “history” of the product) so we have conflict between the standards body, and developer A and developer B and … and DxO dropped DxPL into the middle of that and then panicked when certain users complained and made matters even worse! [/quote]
I didn´t say it´s complicated with hierarchical/structured keywords in general if you just use them - but for me that was rarely the case. It´s just much more inefficient than a flat structure and that is especially when you want to maintain the keyword list. Because I found very often I had to extend it to meet my needs. In Photo Mechanic I don´t like the user interface they provide either (it´s not at all as effective using just the “Keyword”-field and a flat list, so I found myself endlessly exporting - maintaining- importing - using - exporting - maintaining - that bloody list. Below is the controlled vocabulary I started with but finally stopped using because it severely affected my workflows overall effectiveness.
You see I am a person that rarely gives up on things (otherwise you can´t work as an IT-developer as I did for many years), but I just couldn´t justify all the time it took using structured keywords. The alternative cost of using it just got far too high compared with using a flat keyword structure, which is instant and semiautomatic when adding new keywords. That got very obvious when using Photo Mechanic as the metadata tool and metadata database. The structured keywords the way they are handled in Photo Mechanic just didn´t work between PM and Photolab and it hasn´t in other tools either I have used before.
On example of the tab separated structured keyword list i used in PM Plus.
I don´t think DXO will drop all development of the PictureLibrary. They are very close now having a pretty good product to offer and they have done it in a surprisingly short time. Lightroom has used 15 years at least and Photo Machanic more than 20 I think. As I see it Photolab today might work for unambitious hobby users but compared to PM Plus it´s a toy but a good but limited toy that definitely got far better in version 6 than in version 5.
I have no complaints really about using Photolab as a passive consumer of the metadata applied in PM Plus. It works far better than both Lightroom and Capture One does of different reasons. The synchronization between PM Plus is instant if both applications are open simultaneously and if Photolab isn´t the synch occurs the next time the image folder we have updated in PM gets opened in Photolab. So for people who want things to be done today and not in a year or two have a very well scaling working integration solution today as long as not using structured keywords
BUT, DXO just have to make it possible to upload and download keyword lists regardless is they are flat or structured and we lifted that for sure when complaining about it in version 5. It has to be possible both to migrate to and from Photolab as it is with for example Capture One. It is not enough being able to reindex the image files in another DAM. You have to have even the keyword lists you have been using when population the keyword elements in the IPTC/XMP.
Still IPTC is the backbone in metadata handling for images whether we like it or not either classic IPTC or as a compatibility namespace in XMP.
Of course, we can take what we got in the fridge and live with that but I´m that screwed up after working with rationalizing IT-processes in general during many ears and with the photographers’ workflows in particular when working in the cultural heritage world for the City Museum of Stockholm, that I don´t accept putting up with that. Especially since tools like Photo Mechanic got available for around 200 U$ or 2000 SEK. That is a ridiculously low price if I compared it to what it costed to implement Fotowares Enterprise DAM (I think it landed on more than 1 miljon SEK to get it up and running and I think that probably was very cheap because we were a very not more than three doing that job (Me (design of integration, setting up servers and databases, data conversions and building application interfaces, our librarian who took care of the metadata mapping between XMP and SQL and a Fotoware guy who set up the DAM-system initially). It´s difficult to compare but the core tech in PM Plus is to a very large extent the same as in an enterprise DAM like Fotoware and it´s nothing but fantastic that it´s available today to a price almost everyone can afford. For me living with what is in you OS is not an option, that is just poorly used time.
It´s also the fact that your application despite it might be good for handling just the keywords seem to be pretty limited. Keywords are essential and important when managing DAM-systems locally but they are of very limited use on the Internet unless you stick to standardized vocabularies used of an entire branch. Of that reason all the other IPTC-fields are so much more important when it comes to make your images accessible for everybody on the Internet. The keywords are often common words and that makes your image keywords just drowning in the common Internet noise.
Of my 25 IPTC-fields altogether, about 13 are usually static and standardized. About 6 fields are usually the same for a certain session (Event and location). About 3 fields are partly updated by variables picking data from the “Event and location”-fields. I also batch-update the keywords on different sets of images. Since PM manages to keep together RAW and JPEG-files that is possible to do very efficient. So totally 22 of 25 fields are possible to batch update very efficiently.
After that I just walk through it all and add the specifik data and that is very easy because it´s very easy to copy all the data in the Info Form and paste it to all the images that it will be suitable for with just using a few keyboard commands.
If metadata isn´t possible to carry out very efficiently my experience is that it won´t be done at all.
For some of my work buddies that were Photo antiquarians time and effectivity wasn´t an issue at all. They felt they had all the time in the world but our photographers really saw the value in effective metadata workflows. Since I still happen to be a friend with some people at FotoWare I´ve got some interesting feedback when I told them I was using Photo Mechanic.
The photographers at the museum and the photo antiquarians used FotoWares Windows-application Fotostation (pardon the F-spelling but that is Norwegian :-). It was OK but not all that effective compared to PM today. Fotostation is much more though than PM and can be seen as a form of control room interface for the users workflow in the DAM in a much broader sense than PM is, which makes it more complicated. It also costed about more than 3,5 times the cost of PM Plus 6 (more than 7000 SEK compared to about 2000 SEK for PM).
So, both the licensing costs and PM Plus far better productivity has now got quite a few FotoWare Enterprise DAM users to use PM Plus instead as a mean of feeding their DAM-systems with metadata - both image metadata and workflow metadata that control how the images are getting handled by the DAM systems automation hub. That´s the real beauty of using a common XMP-based metadata standard because that is the very core tech that´s making scalability possible in a broader sense. That´s also why it´s so important to be able to migrate even the keyword-lists. The possibility to migrate is essential for scalability.
The photo files you see in your finder window are just containers for the images you took, the image itself has no name by itself, but we can think it to be the same as the file name.
In order to
, you can always add the desctiptive text to the filename, so that both the description and the original filename exist in the new file name.
Descriptive filenames can be easy to use, but they also have some limitations: “me and my dear friend sherpa lantong on everest in june 2015 - IMG_1234.jpg” is a fairly descriptive name, but such names tend to get long if you want to add e.g. date, location, persons and more to the original filename.
Maybe you can find some inspiration here: About Digital Asset Management - TuTo DxO
