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

[julio]

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

Thanks. The following adaptation worked on PowerShell:

Code Select Expand

exiftool -if "`$make eq 'samsung' and `$OtherImageStart" -all= -UserComment="fixed IFD0-Error" -MWG:DateTimeOriginal<MakerNotes:TimeStamp -tagsfromfile "@" -all:all -unsafe -Trailer -icc_profile -overwrite_original "path/to/image.jpg"

[Max24]

Just to report that Samsung S25+ has the same issue - "Error reading OtherImageStart data in IFD0". The Gallery app has become so powerful and easy to use, lots of my this year's pictures have gone thru this app. Without analyzing the two threads related to this "bug" of Samsung, I wish ExifTool could add a switch that can bypass or fix this. It can be an optional one that we can add under File>Settings>ExifTool tab.

[Phil Harvey]

Could you provide a sample?  I don't want to have to dig through all my Samsung samples to see if I have one with this issue.

Thanks.

- Phil

[Max24]

Here are 3 pictures I took the other day in a library. They all exhibit this error.

Where's the option to upload pictures? The hosting site may remove the metadata.

[Phil Harvey]

It is best if you upload them to a file sharing service, but you can email them to me directly if they are small enough.  philharvey66 at gmail.com

- Phil

[StarGeek]

See this post and the one after it.

Alternatively, Google Drive, DropBox, and file (not image) hosting sites like mega.nz for files too big to post on the forums.

If you use Google Drive, make sure you set the link share to "Anyone with a link" instead of "Restricted". See this post.

[Max24]

Hi Phil, I just emailed you 3 sample files plus 1 screen shot of the error in a zip file. It's about 20MB.

[Max24]

This Samsung Galaxy mode came out in Feb. But the model may be irrelevant as the culprit is the Gallery app.

The ExifTool homepage recommends another Exif tool for Android which is called EXIF/XMP Tool. It has no problem parsing the three "OtherImage..." fields - OtherImageStart, OtherImageLength, and OtherImage. Does that indicate that ExifTool can simply ignore what Gallery app did to the file?

[Max24]

Found it.

See this post and the one after it.

Alternatively, Google Drive, DropBox, and file (not image) hosting sites like mega.nz for files too big to post on the forums.

If you use Google Drive, make sure you set the link share to "Anyone with a link" instead of "Restricted". See this post.

[Phil Harvey]

Wow, the metadata is a real mess in these files.  Here is one for example:

Code Select Expand

> exiftool 20250602_180153.jpg -validate -warning
Validate                        : 49 Warnings (14 minor)
Warning                         : Entries in IFD0 are out of order [x5]
Warning                         : Tag ID 0x0101 ImageHeight out of sequence in IFD0
Warning                         : [minor] Odd offset for GPS tag 0x0002 GPSLatitude
Warning                         : [minor] Odd offset for GPS tag 0x0006 GPSAltitude
Warning                         : Entries in GPS are out of order [x2]
Warning                         : Tag ID 0x0001 GPSLatitudeRef out of sequence in GPS
Warning                         : Tag ID 0x0003 GPSLongitudeRef out of sequence in GPS
Warning                         : [minor] Odd offset for GPS tag 0x0004 GPSLongitude
Warning                         : Tag ID 0x011b YResolution out of sequence in IFD0
Warning                         : Tag ID 0x011a XResolution out of sequence in IFD0
Warning                         : Tag ID 0x0100 ImageWidth out of sequence in IFD0
Warning                         : [minor] Odd offset for IFD0 tag 0x0131 Software
Warning                         : [minor] Odd offset for ExifIFD tag 0x9202 ApertureValue
Warning                         : Entries in ExifIFD are out of order [x14]
Warning                         : Non-standard format (string) for ExifIFD 0x9000 ExifVersion
Warning                         : [minor] Odd offset for ExifIFD tag 0x9000 ExifVersion
Warning                         : Tag ID 0x9000 ExifVersion out of sequence in ExifIFD
Warning                         : Tag ID 0x8822 ExposureProgram out of sequence in ExifIFD
Warning                         : Tag ID 0x9205 MaxApertureValue out of sequence in ExifIFD
Warning                         : Tag ID 0x9203 BrightnessValue out of sequence in ExifIFD
Warning                         : Tag ID 0x9003 DateTimeOriginal out of sequence in ExifIFD
Warning                         : Non-standard format (string) for ExifIFD 0xa000 FlashpixVersion
Warning                         : Tag ID 0x9291 SubSecTimeOriginal out of sequence in ExifIFD
Warning                         : [minor] Odd offset for ExifIFD tag 0x829a ExposureTime
Warning                         : Tag ID 0x829a ExposureTime out of sequence in ExifIFD
Warning                         : [minor] Odd offset for ExifIFD tag 0x9010 OffsetTime
Warning                         : Tag ID 0x829d FNumber out of sequence in ExifIFD
Warning                         : Non-standard format (string) for ExifIFD 0x9101 ComponentsConfiguration
Warning                         : Tag ID 0x9101 ComponentsConfiguration out of sequence in ExifIFD
Warning                         : Tag ID 0x9292 SubSecTimeDigitized out of sequence in ExifIFD
Warning                         : Tag ID 0x9004 CreateDate out of sequence in ExifIFD
Warning                         : Tag ID 0x9207 MeteringMode out of sequence in ExifIFD
Warning                         : Tag ID 0x9011 OffsetTimeOriginal out of sequence in ExifIFD
Warning                         : Tag ID 0x9208 LightSource out of sequence in ExifIFD
Warning                         : Tag ID 0x0128 ResolutionUnit out of sequence in IFD0
Warning                         : [minor] XMP is missing xpacket wrapper
Warning                         : ExifIFD tag 0xa404 DigitalZoomRatio requires ExifVersion 0220 or higher
Warning                         : ExifIFD tag 0xa405 FocalLengthIn35mmFormat requires ExifVersion 0220 or higher
Warning                         : ExifIFD tag 0xa420 ImageUniqueID requires ExifVersion 0220 or higher
Warning                         : ExifIFD tag 0x9010 OffsetTime requires ExifVersion 0231 or higher
Warning                         : ExifIFD tag 0x9011 OffsetTimeOriginal requires ExifVersion 0231 or higher
Warning                         : ExifIFD tag 0xa406 SceneCaptureType requires ExifVersion 0220 or higher
Warning                         : ExifIFD tag 0xa403 WhiteBalance requires ExifVersion 0220 or higher
Warning                         : Missing required JPEG GPS tag 0x0000 GPSVersionID
Warning                         : [minor] IFD0 tag 0x0100 ImageWidth is not allowed in JPEG
Warning                         : [minor] IFD0 tag 0x0101 ImageHeight is not allowed in JPEG
Warning                         : [minor] IFD0 tag 0x0103 Compression is not allowed in JPEG
Warning                         : [minor] IFD0 tag 0x0201 OtherImageStart is not allowed in JPEG
Warning                         : [minor] IFD0 tag 0x0202 OtherImageLength is not allowed in JPEG

The only option here would be to first rebuild the metadata for these files using a command such as given in an earlier post.  Here is the quoting for the cmd shell:

exiftool -if "$make eq 'samsung' and $OtherImageStart" -all= -tagsfromfile @ -all:all -unsafe -trailer -icc_profile -overwrite_original DIR

- Phil