Is there a way in PL6 elite to rename images without changing the actual filenames on my drives? I’ve read the manual and found nothing (or didn’t see it…)
I guess you could enter the name of the image in the Title field in IPTC-Status or the Headline field in IPTC -Content. but that is not really renaming the image. Why do you want to rename the image without renaming the actual file? How would you utilize it?
Mark.
Well, I want to rename the file for all the normal reasons: to be more descriptive, memorable, etc.
And I like to keep my source files with their original names for a variety of reasons. It comes from working primarily in video editing, where it is common to keep original filenames and to rename the files within the editing program.
It helps when you want to use footage (or in the case of photos images) between different projects, programs, etc.
But it really helps to keep the filenames consistent between your working files and your backups. Thus, for example, for the film I am editing at the moment I work from my SSD RAID array, but I have 2 backups of each camera card on slower hard drives. If I ever need the backups I can relink the footage/replace the footage very quickly. If the filenames have been changed, it’d be a royal pain in the behind to find the backup files.
Edit to add: I realize it’s not a common feature in photo apps (or seems not to be; I don’t think you can do this in Lightroom). I was just wondering if you can do it with DxO…
Many of us use virtual copies for that purpose, although you can’t uniquely rename virtual copies in the Windows version of PhotoLab yet. You can uniquely rename VC’s in the Mac version. But even in the Windows versions of PL some people use the Master virtual copy as their “backup”. PhotoLab is a non-destructive editor so the need for physical backups is not a requirement for most of us.
Mark
1 Like
@mwsilvers you are braver than I, Sir 
. First thing I do is stash a backup somewhere. “Non-destructive editors”, DAM packages “only the metadata part of the RAW is changed”, native file syncing software and hard drive glitches corrupt pictures on occasion and nothing anyone says will change my mind - I sleep better knowing the original (several copies of in fact) is put away somewhere safe 
3 Likes
@cpcanada There is no “pseudonym” capability in DxPL but as @mwsilvers has suggested there are the metadata settings, IPTC data and keywords and the search capability (somewhat limited) will allow you to re-discover images based upon the data you have put into those fields
If assigned to the original ([M]aster) image before making Virtual copies then the fields will be carried over into the Virtual copies and will find itself
- In the DxPL database
- In the DOP
- In the sidecar metadata for RAWs (DxPL does not update RAW images) and the embedded Metadata for JPG, TIFF and DNG if allowed/forced by the user.
- In any exported images unless explicitly prohibited by the user.
- In any external DAM or editing software that is IPTC/Keyword “aware”
Regards
Bryan
PS:- I “steal” IPTC fields to hold descriptions of the edits and/or Test markers to enable me to identify the Virtual copies, there is no VC renaming facility available in DxPL(Win)
PPS:- Backups are always necessary but I don’t think @mwsilvers meant what he stated in that particular context but rather that the RAW image, in particular will, remain untouched. However, if you use IPTC or keywords with JPG, TIFF or DNG then the issue of writing that metadata back to the original needs to be considered.
Yet more edits:-
with this option selected then the metadata will automatically be written back to the image
and a sidecar file containing the following will be created automatically by PL6
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
xmlns:exif="http://ns.adobe.com/exif/1.0/">
<xmpMM:InstanceID>uuid:d874e788-25f8-4d1d-947a-6e77822b5d6a</xmpMM:InstanceID>
<photoshop:SidecarForExtension>RW2</photoshop:SidecarForExtension>
<dc:format>image/x-panasonic-rw2</dc:format>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="x-default">[M]aster</rdf:li>
</rdf:Alt>
</dc:description>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang="x-default">Sculpture @ Leonardslee Gardens</rdf:li>
</rdf:Alt>
</dc:title>
<tiff:Orientation>1</tiff:Orientation>
<exif:DateTimeOriginal>2022-10-31T13:22:42.328+00:00</exif:DateTimeOriginal>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>
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
1 Like
@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
1 Like
@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.!?
1 Like
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.
1 Like
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.
1 Like
@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.