Rename image without renaming file?

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@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.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@Stenis

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.

@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.

@Stenis

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

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)!

[Joanna (Joanna Carter)]

@Stenis

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?

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.

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

[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.

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 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.

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@Joanna

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.

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.

[platypus (Canon & Mac (Intel and M1))]

@cpcanada

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

@cpcanada

rename the file for all the normal reasons: to be more descriptive, memorable, etc.

, 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