Samsung Gallery edits causing 'Error reading OtherImageStart'

[Jean-Pierre]

In reference to Bob_K "Samsung S22 Ultra: Samsung Gallery edits causing error reading OtherImageStart" let me add some observations with respect to editable tags  and  local time / time zone information in modified Samsung jpg pictures:

I am having a similar problem with a Samsung S20 FE Model SM-G781B/DS:
Whenever a jpg photo has been edited and restored using the "Samsung Gallery" app, applying ExifTool write commands causes an "Error reading OtherImageStart data in IFD0", at least if you try to add or change certain tags:

editing not possible:   DateTimeOriginal, (star)rating, description, title, creator, copyright
editing possible:          keywords, PersonInImage

The command described in FAQ 20 (as mentioned already by Bob_K) repairs the file (makes all tags editable) and keeps most existing tags; the misterious "OtherImage" tags disappear (this seems to solve the problem).

Okay, so I poked around on the forum and found my way to FAQ 20 to rebuild TagsFromFile:   

Code Select Expand

exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile DIR
That solved the immediate problem of updating my desired tags.

However the MakerNotes disappear as well.

In those Samsung photos (at least S20 and S22 behave the same way), the MakerNotes:TimeStamp seems to be the most reliable place where the complete local time information including time zone had been stored while the picture had been taken (at least the Time and TimeZone to which the camera was set at that time).

I want to keep this information, and it turned out, that this can be done by   

Code Select Expand

exiftool -all= -MWG:DateTimeOriginal<MakerNotes:TimeStamp -tagsfromfile @ -all:all -unsafe -icc_profile -overwrite_original FILENAME
I would also like to calculate and store CreateDate explicitly in UTC time. But it seems that I still need a little help how to calculate this efficiently from  DateTimeOriginal  in local time and using the tag  OffsetTimeOriginal  (as long as they are consistent to each other). I have (unsuccessfully) tried all kind of variants from this

Code Select Expand

exiftool -CreateDate<${DateTimeOriginal-OffsetTimeOriginal}Z FILENAME   ==>  does not work this way!!! <== in order to get the Z behind CreateDate (as marker that it is really in UTC), but I assume that some really working and more elegant way exists. Any idea ?

Jean-Pierre

[StarGeek]

Some Samsung Makernotes are stored as trailing data, after the actual image data. This is extremely fragile as it will be lost by any image editing.

You can use a command like this to copy the Makernotes
exiftool -TagsFromFile source.jpg -Trailer target.jpg
Or add
-Trailer
after your -TagsFromFile option.

I would also like to calculate and store CreateDate explicitly in UTC time.

Doing so directly is complicated. I would suggest instead copying the data to the GPS time stamps, as those need to be in UTC already and exiftool will handle the time change correctly.

For example, after copying -Trailer from a Samsung photo to my test photo

Code Select Expand

C:\>exiftool -G1 -a -s -makerNotes:all y:\!temp\Test4.jpg
[Samsung]       TimeStamp                       : 2023:08:10 16:51:17.167-07:00
[Samsung]       MCCData                         : United States / Guam (310)

C:\>exiftool -P -overwrite_original "-GPS*Stamp<TimeStamp" y:\!temp\Test4.jpg
    1 image files updated

C:\>exiftool -time:all --system:all -G1 -a -s y:\!temp\Test4.jpg
[GPS]           GPSTimeStamp                    : 23:51:17.167
[GPS]           GPSDateStamp                    : 2023:08:10
[Samsung]       TimeStamp                       : 2023:08:10 16:51:17.167-07:00
[Composite]     GPSDateTime                     : 2023:08:10 23:51:17.167Z
Then afterwords, you can copy the GPSDateTime into any other tag
exiftool "-CreateDate<GPSDateTime" y:\!temp\Test4.jpg

I think keeping the UTC in the GPS time stamps is better, as most programs will expect the CreateDate to be in local time.

While you're at it, you could also copy TimeStamp into the EXIF time zone tags with
"-OffsetTime*<TimeStamp"

I have (unsuccessfully) tried all kind of variants from this
exiftool -CreateDate<${DateTimeOriginal-OffsetTimeOriginal}Z FILENAME
... but I assume that some really working and more elegant way exists.

The actual way to do this is a bit messy.  You can see in this post what needs to be done to do the conversion. The two step solution is easier to understand and troubleshoot, IMO.

[Jean-Pierre]

Thanks a lot, Stargeek !
I am always impressed by your creative solutions to problems at which others get stuck!
The hint to use -Trailer is much more general than my solution.
And you are right - GPS is always (and very naturally) in UTC. Creating GPSDateTime (in UTC), if it does not exist, is a good idea.

It seems however, that CreateDate for videos is always in UTC. And for photos I have quite different examples, but you are right: the newer cameras tend to local time. And the Samsung smartphones have GPS-location data, but do not provide the GPS time stamp. (It is a pity that there is not the same logic for photos and videos !)

So I might think of reverting from CreateDate to GPSDateTime as the favorite place to store UTC time, at least for photos. And in addition I find it would be a good practice to place a Z behind the value of CreateDate, if it surely is in UTC.

Jean-Pierre

[StarGeek]

It seems however, that CreateDate for videos is always in UTC.

Yes, the main video timestamps are in UTC.  If your date/time includes a time zone like the Samsung:TimeStamp, then you can copy it directly to the Quicktime:CreateDate while including the -api QuickTimeUTC option and exiftool will automatically convert it to UTC.

And in addition I find it would be a good practice to place a Z behind the value of CreateDate, if it surely is in UTC.

This will depend upon what tag you are writing.  The EXIF date/time tags do not include a time zone, as that is held in a separate tag, so you won't be able to include the Z. This includes the GPS time stamps in the EXIF group as they (for some reason) are held in to separate tags, GPSDateStamp and GPSTimeStamp.  And the same goes for any of the integer based time stamps in videos.  See the Quicktime tags page and anything listed as int32u will not allow the Z. There are two video time stamps that are strings, Quicktime:DateTimeOriginal and Quicktime:CreationDate, but those are usually in local time.

The XMP time stamps are pretty much the only ones that you will be able to write with the Z.

[Jean-Pierre]

I have now quite stable results with the following code. I am checking for ($make eq 'samsung') and ($OtherImageStart), which filters out samsung pictures which have a second image (caused by the reversible picture editing of the Samsung Gallery app):

Code Select Expand

exiftool [imagePath] -if (($make eq 'samsung') and ($OtherImageStart)) -all= -UserComment=fixed IFD0-Error, see ExifTool FAQ20 -MWG:DateTimeOriginal<MakerNotes:TimeStamp -tagsfromfile @ -all:all -unsafe -Trailer -icc_profile -overwrite_original
The additional parameters  -MWG:DateTimeOriginal<MakerNotes:TimeStamp  and  -Trailer  make sure, that GPSDateTime, OffsetTimes and the original local time stamp (including its time zone) are also transferred into the repaired set of metadata.

The item  GPSDateTime  shows up with a Z indicating UTC time zone (this is by definition).
This command

Code Select Expand

exiftool [imagePath] -CreateDate<GPSDateTime -overwrite_originalcreates a  XMP:CreateDate  entry which also keeps the Z, clearly indicating UTC time  (just in case you care for  CreateDate  being in UTC).


Here is, why I care:
In my database I am aiming at sorting mixed photo and video files using 
   XMP:CreateDate             for sorting by  UTC time    and 
   XMP:DateTimeOriginal   for sorting by  local time.
(or are there better ways to do this ?)

Jean-Pierre