Samsung S22 Ultra: Samsung Gallery edits causing error reading OtherImageStart

Started by Bob_K, January 22, 2023, 07:11:54 PM

Previous topic - Next topic

Bob_K

I recently came back from a long trip with several thousand jpg photos taken with my new S22 Ultra and proceeded to xfer to my PC and use Exiftool to do my normal tweaking of Exif data:

exiftool -overwrite_original -r -m -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3  DIR

Result was Exiftool errored out on about 50 of the files: Error: Error reading OtherImageStart data in IFD0 ...

Which I'll refer to as the "OIS Error".

Okay, so I poked around on the forum and found my way to FAQ 20 to rebuild TagsFromFile:
   exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile DIR

That solved the immediate problem of updating my desired tags.

HOWEVER: Today I poked around on my phone & PC to try to figure out the origin / extent of the problem files. Here's what I found:

1. The problem is specific to photos that I edited (crop, straighten, rotate etc.) on the phone using the edit features of the Samsung Galaxy Gallery app.

2. When the Gallery app edits a photo it creates "Other Image" data and deletes the normal "Thumbnail Image data. More specifically you now have 1) OtherImage binary data, 2) OtherImageLength and 3) OtherImageStart and NO 1) ThumbnailImage binary data, 2) Thumbnail Length or 3) Thumbnail Start.

3. Strangely, it changes the ExifByteOrder to Big-endian at the same time, vs the usual Little-endian. That doesn't seem to cause any problem, but is seems to be a sure-fire indicator that the file has been edited onboard the S22.

4. Using the "Big-endian" tag as an indicator of files that had been edited, I determined that most, but not all of the edited files suffered from the OIS Error. (Supposition is that it may depend on the type of edit, but I haven't tried to isolate that.)

5. There are a few other Exif differences, but none that seem to be significant. I'm attaching a spreadsheet that highlights the EXIF differences between 3 different versions of the same photo:
   1) "Reverted" version – restored to "original" using the S22 Gallery's "Revert" feature. No OIS Error.
   2) "Edited" version – as I originally imported from phone to PC. Suffers from OIS Error.
   3) "Edited_TagsfromFile" version – after running the TagsfromFile fix. No OIS Error. (No OtherImage or Thumbnail)

I'm also attaching the three files above.

6. I presume that this behavior is related to the "Revert" feature of Samsung's editor. Asking myself: "How does the phone retain the original data?" lead me to investigate that. Short answer is: It's a mystery to me. I was originally thinking that perhaps it's somehow encoded in the "OtherImageBinary" – but that doesn't make sense since the file size shrinks in proportion to cropping. Then I looked for anything resembling an "original" version of the photo file in my S22's file structure – nothing. Finally I utilized the "TreeSize" windows app on my PC to monitor changes in the S22's file counts and memory usage as I took a photo, cropped it to half size, and then reverted it. Expecting to see some sort of "bulge" somewhere where the original might be stashed, NADA. No extra files and storage space shrunk and rose near exactly per the photo size. Hence: I'll just accept it as MAGIC.

7. None of the above seems to matter to actual use of the files. ACDSee, Ifranview and Google Photos are quite happy to work with any version of the file: Reverted(=original/No OIS error), Edited (OIS Error) or Edited_TagsfromFile (OIS Error fixed).

BOTTOMLINE:

I hope that sharing of my (inconclusive) findings on this error may be of help to other Samsung users.

Would welcome any other insights, e.g. What the heck is "OtherImage" data generally used for?

I'm still left wondering if the Exiftool "Error: Error reading OtherImageStart data in IFD0 ..." is really legit. If so (likely), it would "be nice" if there was someway to "get technical" about it and communicate it back to Samsung. Perhaps someone (Phil ?) could take a "get technical" look at the "Edited / OIS Error" file towards that end?

Bob_K

Just occurred to me: Perhaps a better future fix vs TagsFromFile would be to use Exiftool to delete just the OtherImage data? Since the TagsfromFile deletes it anyway, I presume it's not really necessary.

On 3rd thought, most likely that won't work since exiftool won't let me write any other tags as long as the OIS error exists.




StarGeek

Phil is currently away, so it'll be next week until he can take a look at the files.

Extracting the OtherImage results in an useless file
C:\>exiftool Y:\!temp\dd\20221207_153438_edited.jpg  -OtherImage -b >Y:\!temp\dd\20221207_153438_edited_other.jpg
Warning: [minor] OtherImage is not a valid JPEG image - Y:/!temp/dd/20221207_153438_edited.jpg

The edited file also exhibits a lot of warnings in the EXIF structured
C:\Programs\My_Stuff>exiftool -g1 -a -s -warning -validate Y:\!temp\dd\20221207_153438_edited.jpg
---- ExifTool ----
Warning                         : Entries in IFD0 are out of order
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
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 ExifIFD tag 0x9202 ApertureValue
Warning                         : Entries in ExifIFD are out of order
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                         : Tag ID 0xa402 ExposureMode 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                         : [minor] Odd offset for ExifIFD tag 0x829d FNumber
Warning                         : Tag ID 0x829d FNumber out of sequence in ExifIFD
Warning                         : [minor] Odd offset for ExifIFD tag 0x9292 SubSecTimeDigitized
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                         : ExifIFD tag 0x9010 OffsetTime requires ExifVersion 0231 or higher
Warning                         : ExifIFD tag 0x9011 OffsetTimeOriginal requires ExifVersion 0231 or higher
Warning                         : Missing required JPEG ExifIFD tag 0x9101 ComponentsConfiguration
Warning                         : Missing required JPEG ExifIFD tag 0xa000 FlashpixVersion
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
Validate                        : 43 Warnings (14 minor)

Basically, it appears that the Gallery App is trash when it comes to the metadata.

Quote from: Bob_K on January 22, 2023, 07:31:53 PMJust occurred to me: Perhaps a better future fix vs TagsFromFile would be to use Exiftool to delete just the OtherImage data? Since the TagsfromFile deletes it anyway, I presume it's not really necessary.

On 3rd thought, most likely that won't work since exiftool won't let me write any other tags as long as the OIS error exists.

Yep, it looks like the only fix is to re-write everything.  I tried multiple ways to remove just the OtherImage but nothing worked.  Take note that the FAQ 20 command also removes the Samsung trailer data
C:\>exiftool -G1 -a -s -samsung:all -U Y:\!temp\dd\20221207_153438_edited.jpg
[Samsung]       SamsungTrailer_0x0a01Name       : Image_UTC_Data
[Samsung]       TimeStamp                       : 2022:12:07 10:34:38.340-08:00
[Samsung]       SamsungTrailer_0x0bf0Name       : Remaster_Info
[Samsung]       SamsungTrailer_0x0bf0           : (Binary data 37 bytes, use -b option to extract)
[Samsung]       SamsungTrailer_0x0ba1Name       : PhotoEditor_Re_Edit_Data
[Samsung]       SamsungTrailer_0x0ba1           : (Binary data 943 bytes, use -b option to extract)
[Samsung]       SamsungTrailer_0x0ba1Name       : Original_Path_Hash_Key
[Samsung]       SamsungTrailer_0x0ba1           : (Binary data 72 bytes, use -b option to extract)
but this is probably not a big deal
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Bob_K

Thanks for your input. I found that the Gallery app has the ability to submit error reports, so I'll eventually follow up by attempting that, but wait until Phil can hopefully add his view.

For now I'm pondering how to streamline my "tagsfromfile" fix process for the future.

So far my "two off" process (my phone and wife's phone) was to:
1. Run my exiftool -overwrite_original -r -m -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3  DIR command
2. Note the # of files not updated due to OIS error.
3. Go into Windows 10 File Explorer and manually sort out the jpg files by FileModifyDate, check against "not updated" count.
4, Move all jpgs that were NOT MODIFIED TODAY into a separate "OIS" folder
5. Run the exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile DIR on that OIS folder.
6. Then run the Item 1 tag writing cmd on that OIS folder
7. Manually move the files back into the main folder

Obvious first order improvement is to avoid the manual file movement by using an IF condition on the tagsfromfile step, e.g.: exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile -if "$filemodifydate lt '2023:01:23'" DIR\*.jpg

That works and is probably good enough, but...

1. Would be nice if I didn't have to manually edit in the "today" value but have it a variable from the system. Don't believe that's possible within exiftool (?) but reckon a BAT or script could do it.

2. If going to the effort of a BAT or script (I have some experience with Powershell), I reckon I'd try to script the whole process. That brings up the question of: Is there better way to detect the files with the OIS error and single those out for tagsfromfile fixing? (My current "NOT MODIFIED TODAY" criteria isn't exactly foolproof.) Direct error output to a file and read back from it comes to mind, but very clunky and not within my experience.

Would welcome suggestions.



 

Bob_K

Just FYI: Second order improvement is to combine the tagsfromfile fix with the desired tag changes:

exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3 -if "$filemodifydate lt '2023:01:23'" DIR\*.jpg

Bob_K

I've worked up a Powershell script; it's in the debugging stage.

<# Samsung_S22_OIS_Error_Fix.ps1
Put description here.  #>
Write-Host "Script to process imported S22 photo files and correct any OtherImageStart errors."

#Disabled for debug ease
#$tgt_dir = Read-Host -Prompt "Enter the path to the target photo files directory"
#pause

$tgt_dir ="P:\Import Phone Pics HERE\Temp3" # Preset directory path for debug ease.
Write-Host "This script will process image files in this directory: "$tgt_dir

#Phase 1 - Run my normal tag settings on all image files (jpg & video).
exiftool -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3 $tgt_dir
.
#Phase 2 - Run "tagsfromfile fix on any jpg files that did not get modified in Phase 1 - likely due to "OtherImageStart" errors

$today = Get-Date -format yyyy:MM:dd
Write-Host "Today is $today" #Temporary debug aid

#Intended exiftool cmd as it works in CMD, not yet modified for variables
#exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3 -if "$filemodifydate lt '2024:01:23'" DIR

#Intended exiftool cmd adapted to use variables. IF condition always fails in PS. DISABLED FOR DEBUG EASE.
#exiftool -overwrite_original -all= -tagsfromfile @ -all:all -unsafe -icc_profile -OwnerName="(me)" -Artist="(me)" -Model="SM-S908U1 S22 Ultra - T-Mobile (2022)" -n -FileSource=3 -if "$filemodifydate lt '$today'" $tgt_dir

#Simplified exiftool command for debug of IF condition. Tried various ' and " variations without passing condition.
exiftool -filename -if "$filemodifydate lt '2024:01:23'" $tgt_dir
pause


But I'm stymied in getting the -if condition to work, hence the extraneous debugging stuff in it. At the moment the ACTIVE "if" command is at the very end with a hard-coded 2024 date in it to ensure that it SHOULD PASS. I'm pretty sure it's just a matter of getting the right combinations of 's and "s in there but my many tries at that haven't worked.

As it stands, my result is:

PS C:\Users\rober> C:\Users\rober\Documents\Batch_Scripts\PS_scripts\Samsung_S22_OIS_Error_Fix1.ps1
Script to process imported S22 photo files and correct any OtherImageStart errors.
This script will process image files in this directory:  P:\Import Phone Pics HERE\Temp3
    1 directories scanned
    9 image files updated
Today is 2023:01:23
    1 directories scanned
    9 files failed condition
    0 image files read
Press Enter to continue...:


Note that my target directory of 9 jpgs doesn't have any "bad" files in it at the moment, but it doesn't matter at this point since all are younger than my hard-coded lt 2024:01:23 date.

Phil Harvey

I'm thinking this may be a Powershell quoting issue.  I think you should use single quotes around arguments containing a "$".  (read here)

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

StarGeek

The trouble is than you can't just swap the quotes with PowerShell.  Something I just figured out.

So this will not work
-if "$filemodifydate lt '2023:01:23' "
and this will not work
-if '$filemodifydate lt "2023:01:23" '

The first treats $filemodifydate as a shell variable. The second end the parameter right after lt, so exiftool see this
-if '$filemodifydate lt ' '2023:01:23'
and look for a file named "2023:01:23"

I haven't figured out how to actually embed quotes in PS and google searches haven't provided useful results.

The only option that I've found that works is to put a backtick before the dollar sign
-if "`$filemodifydate lt '2023:01:23' "
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

StarGeek

Quote from: Phil Harvey on January 30, 2023, 11:02:15 AM(read here)

Annoyed because that page never showed up in my google searches. But to quote a PS command, use all single quotes and double up the interior quotes.
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Jean-Pierre

I have quite stable results with the following code. Instead of checking for file change dates 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):

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.

Jean-Pierre