Camera Raw/Lightroom: Frame # converts to shutter actuations in EXIF - Camera RAW

  • 1
  • Problem
  • Updated 2 months ago
  • (Edited)
In EXIF info, the image frame # is being converted to the camera shutter actuations, when processing through camera raw (results identical in LR and PS CC). I've tested this independently of PS & CC, and its only when processed through Camera Raw that you can no longer access the original frame #, instead it sees a new number, which when investigating turned out to be the Camera shutter actuations.
This is a major problem, as I make use of the 4 Digit frame # in many applications and Naming / IPTC processes, but can no longer do so after converting from original NEF file.
This is in 9.8 and the latest 9.9 versions, not sure how soon before that.
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
  • massive pouty and grumpy face - angry next

Posted 2 years ago

  • 1
Photo of John R. Ellis

John R. Ellis, Champion

  • 3691 Posts
  • 963 Reply Likes
Can you provide more detail about what you're observing in which program?  In the industry standard EXIF, there is no frame number, and LR doesn't display frame number or shutter counts.   (The proprietary MakerNotes for many cameras do contain that information, but LR doesn't display it.)
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Can do ... the Frame# is an IPTC item, that is viewable when looking at the EXIF metadata, in my case I use PhotoMechanic. 
I make use of the {frame4} variable in renaming the image files, and that can be done and redone at anytime, as long as the EXIF info is preserved.
In the first image, saved as jpg directly from Photomechanic, you can see that the frame#  in the image info panel, is the same as within the filename (#5872)
In the 2nd image, processed through ACR via LR or PS, you can see that it has changed, and is now #8151, which has nothing to do with the image naming... after checking, I discovered that it is the shutter actuations of the camera for that image, not that capture frame reference.
So it seems that the coding within ACR is picking up the shutter actuations within the EXIF, and using that info to (incorrectly) insert into the Frame # info field.
(Edited)
Photo of David Franzen

David Franzen, Employee

  • 99 Posts
  • 20 Reply Likes
Hi Minielly,

Do you happen to know what the source is for the value of the "Frame #" that PhotoMechanic displays for the JPEG it exports? Does it display the same thing for your original NEF file? I'm wondering if the "Frame #" value is draw from a metadata property stored inside a file, or if it's just being derived from the file name.

If you could attach or provide links to your original NEF and the two JPEGs you've shown here, it might help my investigation.

You mentioned that "Frame #" is an "IPTC item." I could not find a property with this name defined in the IPTC's metadata specifications, but perhaps I missed it. Do you know if "Frame #" has a formal definition somewhere?

Camera Raw and Lightroom do copy a value from NEF files' internal Nikon metadata into an XMP field named "aux:ImageNumber," but it's not clear to me if the core issue here is that the value is actually being drawn from the wrong location, or if this is just a case where two different apps are handing non-standard metadata in different ways.

Thank you,
David
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Thanks David - If you can provide me with a private email or location to send the NEF file, I can do so along with the two Jpgs.
I may not have stated the IPTC info correctly for the Frame#... It may not be a standard field, but it is an IPTC variable that is made use of, at any time someone wants to extract and use the 4 digit actual frame number of an image in the caption, client or file info, and not the Shutter actuation value which could go up to 300K +.
The displayed value for the frame # is the same in PM for the NEF and JPG versions, although I don't know where its drawn from in the EXIF - perhaps it may be of further help, to know that when I tried to upload one of the ACR processed images (with exif info preserved) to an online shutter count site - it wasn't able to read anything from the file for the camera actuations. 
I'm not sure when this may have started, but I do know it wasn't always this way, as I've been able to rename processed image files in the past without this error, so something seems to have changed in an ACR version in the last year or so.
Thanks for the insights on this - CM
Photo of John R. Ellis

John R. Ellis, Champion

  • 3676 Posts
  • 961 Reply Likes
You could upload the files to Dropbox or similar and post the sharing links here.
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
https://www.dropbox.com/sh/9wnneldhlm7bibn/AADJGHfZesQZ6lMiHmyWUDx1a?dl=0

Here you go - please let me know when you have them downloaded - TY.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3691 Posts
  • 963 Reply Likes
Frame number is definitely not an industry-standard EXIF or IPTC field. I did a little research on the Photo Mechanic forums, and a Photo Mechanic employee explained that for some cameras (including Nikons and Canons) it is reading the frame number from the undocumented, non-standard, proprietary MakerNotes field: http://forums.camerabits.com/index.php?topic=3969.msg17863#msg17863

When PM "ingests" a file, it writes the frame number (and other info) into a proprietary XMP field. There was another report four years ago that Adobe Camera Raw might be interfering somehow with PM's XMP field, with the frame number somehow getting replaced with the shutter count in the XMP field: http://forums.camerabits.com/index.php?topic=8547.msg41337#msg41337 .  But that thread never reached a definitive conclusion, as far as I can tell, and it seems pretty unlikely ACR would have done that.

I agree with David's suggestion of providing the "before" and "after" files, so we can put them under a microscope and examine the metadata in detail to see if ACR or LR have interfered with the data written by PM.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3691 Posts
  • 963 Reply Likes
"I may not have stated the IPTC info correctly for the Frame#... It may not be a standard field, but it is an IPTC variable that is made use of, at any time someone wants to extract and use the 4 digit actual frame number of an image in the caption, client or file info, and not the Shutter actuation value which could go up to 300K +."

I think informally many Photo Mechanic users understandably refer to {frame4} and such as "IPTC variables", but more precisely, the Photo Mechanic documentation calls them "image variables".  {frame4} is listed in the section Camera or Image-Specific, not in Standard IPTC Fields.

This may sound overly pedantic, but when dealing with metadata (which in general has a complicated industry legacy), it's important to use precise terms to keep our heads straight.
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Good info - thanks on this.
As far as the process involved, PM is used to rename and apply IPTC info to the metadata, then the image would be brought into LR for further production. I can't check what LR sees for the frame #, as it's not a field ( as you say)... but exports from LR or via PS - have the switched info fields.
I just checked, and bypassing PMechanic does not resolve the problem, as an image going  from camera through ACR, produces an output file that is placing the shutter actuation value in the Frame # of an exif reader (PM in my case)... using an online EXIF viewer, I can see that within the XMP section the RawFileName is displaying it properly as DSC_6915 and then the ImageNumber is displayed as 9206 - which is not the frame number, but rather the shutter actuations.
(Edited)
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Thanks John, you're quite right and keeping heads straight with the stuff is always a good thing :)
Here's the link to the DB with an NEF and two JPG produced images, one through ACR, then other as a save extraction using PM
Let me know when you have the image files downloaded, TY.

https://www.dropbox.com/sh/9wnneldhlm7bibn/AADJGHfZesQZ6lMiHmyWUDx1a?dl=0
(Edited)
Photo of David Franzen

David Franzen, Employee

  • 99 Posts
  • 20 Reply Likes
I have successfully downloaded the files, thank you.
Photo of David Franzen

David Franzen, Employee

  • 99 Posts
  • 20 Reply Likes
Thanks for bringing this to our attention.

I have logged a feature request bug for Camera Raw that I think will help. The fix is to make Camera Raw stop overriding an existing aux:ImageNumber value in a file's XMP with a different value when it updates metadata for a photo and when it copies metadata to a derived file (like a JPEG saved from Camera Raw). The fix would apply to Lightroom as well. At this time I cannot comment on when or if the fix will be released. 

Thanks,
David
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Excellent and much appreciated. It may seem trivial to some, but its caused a major hiccup in a current project for the image handling through the client chain.
Thanks again - Craig
Photo of John R. Ellis

John R. Ellis, Champion

  • 3676 Posts
  • 961 Reply Likes
The issue might be a little more complicated.  While LR is changing XMP:aux:ImageNumber, it isn't changing XMP:photomechanic:Prefs="0:0:3:005872", where according to the PM support engineer I linked to above, PM is storing its notion of the frame number (5872).  That field is left unchanged by LR / ACR. 

It's certainly possible that the engineer misspoke, only spoke the partial truth, or PM has intentionally changed in the meantime.   But it looks suspicious that PM is ignoring the frame number it wrote to its own proprietary field in favor of the Adobe-defined XMP:aux:ImageNumber.

You might post a question at the PM support forum asking about this.  (In the past, I've observed that PM can be more responsive to changing their program than Adobe is with respect to metadata.)
Photo of Minielly

Minielly

  • 8 Posts
  • 0 Reply Likes
Hmmm... I'm swimming without a lifejacket in this tech discussion, but keeping afloat as best I can... I can post a question there, as I know the PM guys, but perhaps you could phrase the details or known issues, so they can zero in on the specific are of concern.
Happy to go to DM i you want, thanks again.
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 14143 Posts
  • 1766 Reply Likes
This issue was marked fixed by the engineering team in 9.10 or later. Let us know if you still have any issues.