Renamer: convert hexadecimal value to integer

[herman]

I like to have the shuttercount as part of the filename for my images.
All my cameras had something like a file index in EXIF which gives a number for the shutter count.

The exception is my current main camera where the designer created a "Image Unique ID" in EXIF which consists of a long string containing a hexadecimal number.

An example to illustrate this:

Code Select Expand

{File.MD.Exif::Main\42016\ImageUniqueID\0}

returns for a particular image

Code Select Expand

000000000000000000000000000016cf

I tried to format the variable as

Code Select Expand


{File.MD.Exif::Main\42016\ImageUniqueID\0|numformat:int,05}

but that returns

Code Select Expand

00016

So it seems that IMatch does not recognize the variable as a hexadecimal number.

The hexadecimal value 16CF translates of course to 5839 decimal.
I would like the IMatch Renamer to convert / cast this string as 05839

Please consider this as a low priority request.
As it is now I have unique filenames, it is just that I don't like the filenames having no relation to the shutter count.

[lenmerkel]

Herman, what is the data type of that specific tag? It might not be string, but a long int, and you're getting the formatted value as hex. You could try the modifier value:rawfrm to prefer the raw value if there is one. If it's actually string, then yes, it needs to be parsed somehow back to an integer.

[herman]

Given the large number of leading zeros I assumed it must be a string (I wish the shutter would still be alive when all these zeros turn into F  ).
When I format the variable with value:rawfrm it returns exactly the same value as without the formatting.

[edit]
when I format with value:raw it returns nothing, meaning there is no raw value, so it must be a string.
[/edit]

[Mario]

000000000000000000000000000016cf is what the camera has written as a string. IMatch has no info about this tag and camera can write whatever they want. Why don't you just use a substr?

[herman]

I formatted the variable with |substrr:0,5
That works of course, but the result, 016cf, is still hexadecimal.
All other filenames are in decimal notation, I would like the filenames from this camera to be decimal too.

[P.Jones]

I formatted the variable with |substrr:0,5
That works of course, but the result, 016cf, is still hexadecimal.
All other filenames are in decimal notation, I would like the filenames from this camera to be decimal too.

In the script editor Val("&H0016cf") will give you 5839

[lenmerkel]

Herman, you can try this as a get-around. It assumes you're OK with temporarily setting an unused metatag in your file with the hex value converted to integer.

• Use the ECP to convert the hex string from ImageUniqueID to an integer value, and store it in an unused metatag.
• Use the Renamer to refer to the metatag above as a variable, and rename your file.
• Use the ECP to unset the metatag above.

ExifTool is written in Perl, and has the option to format the value of any metatag by any arbitrary Perl code you provide. Perl has a standard function to convert from hex to integer, so we can use that. Mario has kindly provided access to IPTC custom fields in IMatch 5.1.12. It's highly unlikely you would ever use these, so one would be perfect for temporarily holding the converted integer value.

Here's an ECP preset to convert ImageUniqueID to an integer value and store it in IPTC Custom Field 1. You might need to refer to it as EXIF:ImageUniqueID.

Code Select Expand


-IPTC:CustomField1<${ImageUniqueID;s/$_/substr $_,-6/e;s/$_/hex $_/e}
{Files}

Note that this only considers the last 6 characters of the hex value (-6 in the above code), to avoid any possible integer overflow on conversion. You can of course change this.

Now, you can refer to this integer value in a Renamer step by its variable name: {File.MD.IPTC::ApplicationRecord\200\CustomField1\0}. You can of course find this in the variable browser/finder.

Finally, you can reset the IPTC Custom Field 1 metatag with the following ECP preset:

Code Select Expand


-IPTC:CustomField1=
{Files}


Note: This will change your file (by setting, then unsetting the custom tag). Please make sure you're OK with that before proceeding. Also, I strongly recommend you test this out with a couple of test file, to make sure it's doing what you expect.

[Ferdinand]

Why doesn't ExifTool return a decimal value?  Have you asked Phil whether it's possible?

[herman]

Thank you all for responding, for thinking with me and sharing your thoughts, for your suggestions.

@lenmerkel
I am again impressed by the tools available in IMatch....
But as this work-around implies writing to the images I will not pursue this.
I would have no objections to write to derived files (versions), they can always be re-created.
There is no way I am going to modify my original files (masters).
But again, thank you for showing what can be achieved with IMatch!

@Ferdinand
Nope, I did not ask Phil.
I really doubt he can do anything about his.
I checked the EXIF Standard specification, it states that this tag is an ASCII string of 33 positions (see attachment).
So it can hold anything, not just numbers.
For some reason only known to the designers of this specific camera they decided to use this tag to store the shuttercount.
Perfectly "legal" of course, but a nuisance when you want to use the number contained in this tag.... 

@P.Jones
It seems that scripting could do the job, thank you for pointing this out.
I am a total scripting noob, it would be my first script, so it is not something I can do on a rainy Sunday afternoon.
Nevertheless I had the intention to familiarize myself with scripting one day, so this may be the right opportunity.

Now if I only could get some support for this feature request ..... 



[attachment deleted by admin]

[Ferdinand]

I'd still be inclined to ask Phil.  He's a nice guy and he can only say no in a polite way and explain his reasons.

I think what I would do in your situation is write a script that converted the shutter count to decimal and store it in an attribute and then use that in the renamer.  (I haven't experimented with attributes enough to know if a script could be avoided.)

[Mario]

The format and contents of this tag are not defined in any way. Some camera vendors write a serial number, shooting number, shutter count. Others write a GUID. You can see what's in that tag and if you see it's a hex number, you can use formatting functions as outlined above to somehow mangle and convert the format to your liking.

Adding an option like "interpret this as a hex number because I know it's hex (for a given camera model and firmware) to ExifTool is really not a good idea. ExifTool has already too many options.

Anyway, I've added this to IMatch 5.0.14. It's a small addition to the numformat formatting function. In addition to int and float we now have hex. If you use numformat:hex,1 you tell IMatch that the variable holds an integer in hexadecimal formatting, and IMatch interprets it as such. May be useful for other purposes as well.

[herman]

Anyway, I've added this to IMatch 5.0.14. It's a small addition to the numformat formatting function. In addition to int and float we now have hex.

Thank you!!
I am really glad you could solve this.
It was a low priority request, I could not hope to see it implemented in the next version.... 
This morning I started to write "pseudo code" for a script, I can stop that now.
A big thank you again, I am looking forward to the next build.

[Ferdinand]

Impressive!   

[Mario]

This was a 5 minute change. Only a few lines of code and one line added to the help. I'd wish all feature requests would be so quick to implement.

[lenmerkel]

Very nice. That's what I call agile development! 

[Erik]

I know the feature is implemented for the next version, but going back to the ECP option presented...

When a user doesn't want to write to their image files, a valuable feature of EXIFTool is the ability to write XMP data anywhere:

I needed to do some cleanup with my images when I moved my production to IM5 (from IM3.6).  I used the ECP to write XMP information to a dummy XMP file that was nowhere near the original file and would only be used by the ECP later to reread and process information to the actual XMP information.

So for the example presented earlier, one could have processed the example and written the info to an XMP field in a dummy XMP file and then reread it as needed... Although for renaming files, you'd have to somehow get the result into the actual XMP record since IM won't actually know about this dummy information.

[herman]

Mario,

Your change works like a charm in build 5.1.14
Thanks!