unchanged secondary destination + original filename vs. renamed filename

[sdewitte]

I'm currently evaluating Photo Mechanic.

In my workflow I want to copy, rename and add metadata (IPTC) to photos which go to the primary destination. In the secondary destination I want an unchanged copy of the original photo (no renaming, no adding of metadata [in dated subfolders to prevent the small change of overwriting duplicates]). In this way, I can always fall back to the original, unchanged photo in case anything goes wrong during PP. Of course, I can do this manually, but it would be nice if this could be automated.

Then, to link the original, unchanged photo from the secondary destination to the changed/updated/renamed photo from the primary destination, I want to add both the renamed filename and the original filename to the IPTC title field in the following way:
{new-filename} (original {quality}: {original-filenamebase})
For instance: SDW_080522_001633.NEF (original RAW: DSC_1633)

Is either of the two steps above possible in the current version of Photo Mechanic? If not, can they be added to a next version? For instance, for not applying any changes for the secondary destination, there could be just a tick mark to indicate "apply (or don't apply) changes to the secondary destination" (or even more specific, a separate tick mark for renaming and one for adding IPTC metadata). I think Photo Mechanic is a great program, and if the above two features are currently available or will be implemented soon, I will definitely buy a copy. If not, I have to look further for my 'ideal' DAM app.

Kind regards,
Sander

[Kirk Baker]

Sander,

I'm currently evaluating Photo Mechanic.

In my workflow I want to copy, rename and add metadata (IPTC) to photos which go to the primary destination. In the secondary destination I want an unchanged copy of the original photo (no renaming, no adding of metadata [in dated subfolders to prevent the small change of overwriting duplicates]). In this way, I can always fall back to the original, unchanged photo in case anything goes wrong during PP. Of course, I can do this manually, but it would be nice if this could be automated.

Then, to link the original, unchanged photo from the secondary destination to the changed/updated/renamed photo from the primary destination, I want to add both the renamed filename and the original filename to the IPTC title field in the following way:
{new-filename} (original {quality}: {original-filenamebase})
For instance: SDW_080522_001633.NEF (original RAW: DSC_1633)

Is either of the two steps above possible in the current version of Photo Mechanic? If not, can they be added to a next version? For instance, for not applying any changes for the secondary destination, there could be just a tick mark to indicate "apply (or don't apply) changes to the secondary destination" (or even more specific, a separate tick mark for renaming and one for adding IPTC metadata). I think Photo Mechanic is a great program, and if the above two features are currently available or will be implemented soon, I will definitely buy a copy. If not, I have to look further for my 'ideal' DAM app.

Version 4.6 will have the ability to keep images at the Secondary destination copied as originals.  We don't and won't have a new variable that gives you the 'new filename' because of the way the copy occurs and the time of the IPTC generation (it is a catch-22 kind of situation.)  You can use the same renaming variables in the IPTC Stationery Pad and get the same result however.

I don't have a scheduled release date for version 4.6 but it will do most of what you're asking it to do.

-Kirk

[sdewitte]

Kirk,

Thanks for your swift reply.

You can use the same renaming variables in the IPTC Stationery Pad and get the same result however.

I don't quite understand how you can reach the same result ( "SDW_080522_001633.NEF (original RAW: DSC_1633)" ) with just one variable. Can you explain a bit what you mean?

Kind regards,
Sander

[Kirk Baker]

Sander,

You can use the same renaming variables in the IPTC Stationery Pad and get the same result however.

I don't quite understand how you can reach the same result ( "SDW_080522_001633.NEF (original RAW: DSC_1633)" ) with just one variable. Can you explain a bit what you mean?

You'll have to use several variables, the ones you used to rename the file, the {quality} and {filenamebase} variables.

-Kirk

[sdewitte]

Kirk,

You'll have to use several variables, the ones you used to rename the file, the {quality} and {filenamebase} variables.

Ah, you mean that during the copy/ingestion from a card (or any other location), the variables {filename} and {filenamebase} will represent the original filename on the card (and not the new filename).

So, to get:
SDW_080522_001633.NEF (original RAW: DSC_1633)
in the "Object Name" field,
I can use:
SDW_{datesort:2}_00{frame4}{filename:-4,4:UC} (original {quality}: {filenamebase})

Two more questions then:
Any better way to add the extension, instead of "{filename:-4,4:UC}"? In a theoretical case the extension (including the dot) does not necessarily have to be 4 characters long (although for all images, including my NEF's, it probably is).
Is it possible to not hard code the 2 zeros in front of the frame number (while the original filename has only 4 digits)? In other words, is there a way to always format a variable to a certain number of characters, 6 in this case, with a choice of padding characters, "0" in this case.

Kind regards and thanks for your help,
Sander

[Kirk Baker]

Sander,

You'll have to use several variables, the ones you used to rename the file, the {quality} and {filenamebase} variables.

Ah, you mean that during the copy/ingestion from a card (or any other location), the variables {filename} and {filenamebase} will represent the original filename on the card (and not the new filename).

So, to get:
SDW_080522_001633.NEF (original RAW: DSC_1633)
in the "Object Name" field,
I can use:
SDW_{datesort:2}_00{frame4}{filename:-4,4:UC} (original {quality}: {filenamebase})

Two more questions then:
Any better way to add the extension, instead of "{filename:-4,4:UC}"? In a theoretical case the extension (including the dot) does not necessarily have to be 4 characters long (although for all images, including my NEF's, it probably is).
Is it possible to not hard code the 2 zeros in front of the frame number (while the original filename has only 4 digits)? In other words, is there a way to always format a variable to a certain number of characters, 6 in this case, with a choice of padding characters, "0" in this case.

Just use {filename} instead of {filenamebase}.  It will include the filename extension.
As for the numeric formatting, no, there is no 'fill with needed zeros' feature.

-Kirk

[sdewitte]

Kirk,

Just use {filename} instead of {filenamebase}.  It will include the filename extension.

If I understand correctly, this is not possible during the ingest. Because at that time {filename} holds the original filename on the card (for instance: DSC_1633.NEF) and not the new filename (for instance: SDW_080513_001633.NEF). Which is OK, as you explained. But then I still need to construct this new filename with extension to put it in the IPTC Object Name field. And therefore I need a way to add the extension of the original filename to the new filename, which I did with "{filename:-4,4:UC}". This is not the ideal way, as explained earlier, but if this is the only way, I can live with it (because for me, I only have .NEF extensions). Please, let me know whether "{filename:-4,4:UC}" is currently the only way to extract the extension from the original filename during ingest.

Kind regards,
Sander

[Kirk Baker]

Sander,

Just use {filename} instead of {filenamebase}.  It will include the filename extension.

If I understand correctly, this is not possible during the ingest. Because at that time {filename} holds the original filename on the card (for instance: DSC_1633.NEF) and not the new filename (for instance: SDW_080513_001633.NEF). Which is OK, as you explained. But then I still need to construct this new filename with extension to put it in the IPTC Object Name field. And therefore I need a way to add the extension of the original filename to the new filename, which I did with "{filename:-4,4:UC}". This is not the ideal way, as explained earlier, but if this is the only way, I can live with it (because for me, I only have .NEF extensions). Please, let me know whether "{filename:-4,4:UC}" is currently the only way to extract the extension from the original filename during ingest.

Sorry, I misunderstood your question.  And yes, your method is currently the only way to do what you're trying to do.

I'll see about adding an {filenameext} variable in 4.6.

-Kirk

[sdewitte]

Kirk,

I'll see about adding an {filenameext} variable in 4.6.

Thanks. That will be a useful addition.

However, now I think of it, what you hinted at might even be better for the "Object Name" field. That is, using:
SDW_{datesort:2}_00{frame4} (original {quality}: {filename})
(i.e. the new filename without extension and the original filename with extension) instead of:
SDW_{datesort:2}_00{frame4}{filename:-4,4:UC} (original {quality}: {filenamebase})
because the new filenames extension might change during PP (for instance into .DNG), making the contents of the "Object Name" field out of date, while the original filenames extension will always remain .NEF.

Still, a {filenameext} variable would be useful for other purposes, though.

Kind regards,
Sander