{frame4} reports inconsistently on Ingest/rename.

[NickML]

I have an unusual issue when using the variable {frame4} where it returns a different value depending on the command it is used within. I'm on PM5.0, build 13915 on OSX10.6.8.

When ingesting:

• the original files are NNEFS
• Upon ingesting, I rename files as {frame4}, eg 0550.nef
• Upon ingest I apply a local stationary pad which has the following string at the end of the caption field: "Ref:{iptcyear4}{iptcmonth0}{iptcday}{frame4}"

In my example this morning, this results in ingested files named between 0550.nef and 1644.nef, with an equivalent line in the caption field that says: "Ref:20130790550" to "Ref:20130791644"

I then edit, take the selected files into CS5 ACR, and save as JPEGS into a new folder from within PSCS5 as "SOMETHING-{documentname}", in this case, a set of JPEGS whose filenames vary from SOMETHING-0550.jpg for the first one to SOMETHING-1644.jpg for the last one.

The problem occurs with the next part. If I then want to rename those JPEG files from within PM so the first one which was called  SOMETHING-0550.jpg is now called SOMETHINGELSE-0550.jpg, the easiest way is to select SOMETHING-0550.jpg and select Rename>"SOMETHINGELSE-{frame4}".

However, in the preview of the Rename (see grab below), and in the renaming itself, the {frame4} now returns a different, higher, value, as if if has been shifted by adding a new number. - in my specific example, +226 for the first one, and +227 for the final one in the set.

• For example, byusing the rename function, the first file in the set previously known as SOMETHING-0550 is now SOMETHINGELSE-0776 (+226) instead of SOMETHINGELSE-0550
• and the last file in the set previously known as SOMETHING-1644 is now SOMETHINGELSE-1871 (+227) instead of SOMETHINGELSE-1644

I'm guessing either one of two things is happening. Either CS5 is altering the equivalent of {frame4} in ACR (and then PM then correctly reads the new, changed-by-PS, 'incorrect' value for{frame4}, or PM has some kind of bug. A quick search in the forums didn't show up anything similar. Any ideas ?

ADDED AFTER POSTING:

• If I try to rename the original NEFs, this works fine so 0550.nef can be renamed to foobar0550.nef with no problems. The problem seems specific to JPEGS output from NNEF files in ACR.
• In my example, SOMETHING-0550 wrongly renames to now SOMETHINGELSE-0776. If I look in the raw metadata of the NNEF, the only reference to 0776 I can see there is under aux:ImageNumber. See screengrab.

[attachment deleted by admin]

[Kirk Baker]

Nick,

Can you send us your NEF file and the JPEG you produced from it?  Contact me privately for FTP server info and instructions.

Thanks,

-Kirk

[Kirk Baker]

Nick,

Thanks for the samples.  Photo Mechanic writes one key/value to XMP data for tracking tag, rating, color class, and frame number.  Normally it looks like this:

<photomechanic:Prefs>0:1:0:000550</photomechanic:Prefs>

or in the more compact form, this:

photomechanic:Prefs="0:0:0:000550"

But in your JPEG, something has gone and modified it to look like this:

photomechanic:Prefs="0:0:0:040776"

If the only thing that was done to produce the JPEG with the damaged frame number was to run a NEF through the ACR plugin in Photoshop and then save it as a JPEG then there must be some sort of problem with Photoshop or the ACR plugin.

In regards to XMP metadata, most apps completely ignore XMP data they don't work with and simply preserve it through the workflow.

I see that Photoshop has added:

aux:ImageNumber="40776"

which matches the change to PM's Prefs.  But I don't know why Photoshop would create a number that large, nor why it would modify our keys/values.

-Kirk

[NickML]

Thanks, Kirk, I appreciate you looking into it. That's baffling. The 40k-ish figure that PS adds seems to correlate to the shutter count. One thing I did consider was whether there were two frame counts, one for stills, and one for stills+video together. However, it doesn't explain why the difference between the two frame numbers manages to increase during the shoot itself, since no video was shot that day. I'll do some tests with shooting JPEGs in camera and see whether that affects things.

[NickML]

I think you must be right: the issue is with ACR.

To test, I shot a JPEG in-camera, which the camera named as "_D3S3806.JPG" and the actuation number is 44,038. This was ingested and renamed as {frame4} which was 3806.jpg. If I then rename manually from within PM as {frame4}, the same frame number is assigned. If I edit in PS, then rename, then the same frame number is given - meaning I can't replicate the bug with JPEGs.

I did the same with shooting RAW+JPEG. The actuation number was 44,039 and the filename was "3810.nef/.jpg". I took the RAW file only, put it through ACR to produce a JPG, then renamed as {frame4}, which renamed it to 4039.jpg (the last four digits of the actuations). When I did the same with the paired JPEG, however, the renamed name was the correct 3810.jpg.

All of which is a long way of saying I haven't got a clue what's going on, except it's ACR's fault not yours. Thanks for looking into it anyway.

Nick

[jongolden]

I am having a similar problem with current version Photo Mechanic Version 5.0, build 13915 (a16ea99)

I ingested CR2 files from Canon 5D3, using NAME_{yr2}{month0}{day0}_{hour24}{min}_{frame} .
I realized the camera date was off by 1 hour and used Tools: Adjust Date/Time to adjust time.
I then attempted to File: Rename Photos. But PM does not see {frame} any longer and wants to put nothing in the referenced space. 
the problem occurs with either {frame} or {frame4}

any suggestions

[Kirk Baker]

Jon,

I am having a similar problem with current version Photo Mechanic Version 5.0, build 13915 (a16ea99)

I ingested CR2 files from Canon 5D3, using NAME_{yr2}{month0}{day0}_{hour24}{min}_{frame} .
I realized the camera date was off by 1 hour and used Tools: Adjust Date/Time to adjust time.
I then attempted to File: Rename Photos. But PM does not see {frame} any longer and wants to put nothing in the referenced space. 
the problem occurs with either {frame} or {frame4}

Was any other software used to adjust/modify your CR2 file or XMP sidecar file besides Photo Mechanic?

-Kirk

[jongolden]

No.. I actually realized I had the problem before I had formatted the chips, so I re-imported chips with incorrect time, changed time with PM, and then attempted to rename.

OS 10.6.8 BTW

Jon

[jongolden]

OK.. Here is some understanding and a workaround 

Canon 5Dm3 does NOT actually have a embedded EXIF "frame" field. (other cameras as well I hear -- Kirk?) - Either it does not exist or PM cannot gain access to it.. PM takes the pseudo frame number the camera applies to a filebasename as you shoot. (ex: _IMG1234) and substitutes that on ingest in a string like I use: NAME_{yr2}{month0}{day0}_{hour24}{min}_{frame}   

BUT, Since the ingested files don't have an actual EXIF field "Frame" that PM can use, and PM no longer has access to the original filenamebase, it is blank.. BUT in my case, I always write this string: NAME_{yr2}{month0}{day0}_{hour24}{min}_{frame} into SUP CAT 1 for future reference, in case a client renames a file, for example.

So my work around was to: 1. change date/time to fix time issue on files, then 2. use a rename string that looks like this NAME_{yr2}{month0}{day0}_{hour24}{min}_{sup1:-4}         (-4 to use last 4 digits of sup cat 1)
Of course I now needed to replace the SUP CAT 1 field on the renamed files, but that was straight forward..

I hope this helps people understand why there are issues with frame and frame4 on certain cameras (5Dm3 for sure) and maybe give you some options.