Unexpected Renamer behaviour

[herman]

I see something unexpected when working with the renamer.
I don't know if it is a bug or that it behaves just as designed, so let me describe what is going on.

As I changed  my workflow I needed to renumber my OOC Original files.
I wanted the files to be in the YYYYMMDD-HHMMSSss format, the last two digits representing 1/100 of a second.
Under normal conditions one would expect the renamed files to have 17 characters (16 digits plus the dash).
See the attached screenshot "Renamer" for the entries used.

It seems that files from my smartphone get an 18th character in the renaming process.
I used the ECP to view the raw metadata from a picture made by the phone.
The ECP shows that the composite date / time information has the extra digit, so in the sample image it actualy reads 553/1000 seconds.


Create Date                  : 2017:07:08 19:44:37.553
Date/Time Original           : 2017:07:08 19:44:37.553

The renamer apparently uses this last digit as well.

As far as I am concerned it is no major issue, it is easy enough to truncate the renamer output to 17 positions using an extra step (see screenshot Renamer-truncate).
It is a little unexpected though.....

FWIW: I am using IMatch 2017.6.10

The zipped unaltered OOC file used as example for this topic is available for download at
https://1drv.ms/u/s!AkFqYDSt0Ie1yqpuGVdDN1DOiIPnPg

[Mario]

ss represents the 1/100 seconds, which are in the range of 0 to 999. This means although the name of the Attribute is just ss, it returns between 1 and 3 digits. It has do, else it could return false data.

[herman]

ss represents the 1/100 seconds, which are in the range of 0 to 999.

I don't understand.....
According to the Renamer step I am using we are talking about 1/100 Second in SS format (00 - 99), which makes sense to me.
Adding a third digit would bring us to the 1/1000 seconds range, wouldn't it?
I am confused.....

[Mario]

ExifTool returns up to 3 digits for this value.

[herman]

ExifTool returns up to 3 digits for this value.

I know.

Let's put it another way.

In the example image ExifTool comes up with 19:44:37.553

If the 553 were 1/100 seconds it would translate to 553/100 = 5.53 seconds, which is obviously not right.

What I am trying to say is that in this example the last digit should not be shown in the 1/100 range, it is part of a 1/1000 range, so that the .553 stands for 553/1000.

Where the Renamer step is labelled 1/100 Second in SS format (00 - 99) I would therefore expect it to drop everything following the second digit.

[Mario]

The Exif standard says:

SubSec time. Records fractions of a second.

So this could also be 1/1000 of a second. ExifTool just names the tag 1/100 second.
135 means 0.135 seconds.

[herman]

I understand that.

What I find hard to understand is the notation in the Renamer where it reads  (00-99)
In this example image it reads (00-999), when camera electronics advances we may see something like (00-99999) in the future.
As I said, I find it unexpected behavior when the Renamer step is labelled 1/100 Second
That may be because I used to be an engineer in electronics, in Dutch we would call it "beroepsdeformatie" which may probably be translated as "professional deformation" 

[Mario]

I will change the 0-99 to 0-999 in the text for the next release. And may also change the /100 to Sub Seconds or Something. Then no confusion anymore.

[herman]

Thanks, that is probably the smartest thing to do.

When some sod like me wants just two digits in that position it is easy enough to have Renamer truncate to the desired length.