IssueTracker

Thanks for reporting, i can use the example app to reproduce the problem. I saved the corrupted file and pulled it off the device and ran it through exiftool, which complained (it doesn't complain as loudly about the source file, just some technically out-of-order tags):

$ exiftool -v2 editedFile.jpg
  ExifToolVersion = 12.52
  FileName = editedFile.jpg
  Directory = .
  FileSize = 433785
  FileModifyDate = 1678109782
  FileAccessDate = 1678109782
  FileInodeChangeDate = 1678109782
  FilePermissions = 33184
  FileType = JPEG
  FileTypeExtension = JPG
  MIMEType = image/jpeg
  Warning = [minor] Skipped unknown 617 bytes after JPEG APP1 segment
JPEG APP1 (46 bytes):
  ExifByteOrder = II
  Warning = Short directory size for IFD0 (missing 150 bytes)
  | Warning = Bad IFD0 directory
  Warning = [minor] Skipped unknown 917 bytes after JPEG NULL segment
JPEG SOI
JPEG APP0 (14 bytes):
  + [BinaryData directory, 9 bytes]
  | JFIFVersion = 1 1
  | - Tag 0x0000 (2 bytes, int8u[2])
  | ResolutionUnit = 0
  | - Tag 0x0002 (1 bytes, int8u[1])
  | XResolution = 1
  | - Tag 0x0003 (2 bytes, int16u[1])
  | YResolution = 1
  | - Tag 0x0005 (2 bytes, int16u[1])
  | ThumbnailWidth = 0
  | - Tag 0x0007 (1 bytes, int8u[1])
  | ThumbnailHeight = 0
  | - Tag 0x0008 (1 bytes, int8u[1])
JPEG DQT (65 bytes):
JPEG DQT (65 bytes):
JPEG SOF0 (15 bytes):
  ImageWidth = 512
  ImageHeight = 384
  EncodingProcess = 0
  BitsPerSample = 8
  ColorComponents = 3
  YCbCrSubSampling = 2 1
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG SOS

The size of the JPEG APP1 segment looks wrong in the edited file (from exiftool):

JPEG APP1 (46 bytes):

Compared to the original file:

JPEG APP1 (65279 bytes):

In binary this difference is visible in the 5th/6th byte of each file (from hexdump -C). The first 4 bytes are a JPEG marker (0xFF), a JPEG SOI (start of image, 0xd8), another marker and an APP1 (0xe1), followed by 2 bytes indicating the size of the APP1 segment.

Edited image:

ff d8 ff e1 00 30

Original image:

ff d8 ff e1 ff 01

Looking into why ExifInterface is writing out the wrong APP1 size, I turned on debug logging:

$ adb shell setprop log.tag.ExifInterface VERBOSE

And now it becomes a bit more obvious (this logging is from here and here):

saveJpegAttributes starting with (inputStream: java.io.BufferedInputStream@4fba9e8, outputStream: java.io.BufferedOutputStream@e5c3801)
index: 0, offsets: 8, tag count: 15, data sizes: 81, total size: 65584

65584 (0x10030) is greater than the max 16-bit unsigned value (2^16 = 65536), so when we pass it to ByteOrderedDataOutputStream.writeUnsignedShort, the naive cast (writeShort((short) val)) truncates to the lower two bytes (0x0030) - and this gets written out to the file and then breaks everything.

I think this likely only affects files that are very close to the 2^16 threshold, and the act of 'copying' all the EXIF attributes over probably reformats some of them just enough to take up slightly more bytes.

I'm not sure what is supposed to happen when a JPEG APP1 segment gets larger than 2^16 bytes, I need to dig a bit further into that part.

Actually thinking about it more, it's not obvious to me why the APP1 segment of the original image is so large either - looking in exiftool it doesn't seem to contain any particularly enormous fields, so I can't really see where 65kB comes from.

re comment #5 about why the original APP1 segment is so large, I missed the thumbnail the first time, which takes up a significant chunk (64kB):

  + [IFD1 directory with 15 entries]
  | 0)  ImageHeight = 384
  |     - Tag 0x0101 (4 bytes, int32u[1]):
  |         0323: 80 01 00 00                                     [....]
  | 1)  Orientation = 6
  |     - Tag 0x0112 (2 bytes, int16u[1]):
  |         032f: 06 00                                           [..]
  | Warning = Tag ID 0x0103 Compression out of sequence in IFD1
  | 2)  Compression = 6
  |     - Tag 0x0103 (2 bytes, int16u[1]):
  |         033b: 06 00                                           [..]
  | 3)  ThumbnailOffset = 1273
  |     - Tag 0x0201 (4 bytes, int32u[1]):
  |         0347: f9 04 00 00                                     [....]
  | 4)  ThumbnailLength = 64000
  |     - Tag 0x0202 (4 bytes, int32u[1]):
  |         0353: 00 fa 00 00                                     [....]
  | Warning = Tag ID 0x010f Make out of sequence in IFD1

Wikipedia reckons we can't put Exif anywhere except APP1:

Exif metadata are restricted in size to 64 kB in JPEG images because according to the specification this information must be contained within a single JPEG APP1 segment.

Charcoal: Do you know if CameraX is deciding how large to make the thumbnail in this case, or is this happening lower down in the device? Taking up 64,000 bytes doesn't leave much space for the rest of the Exif data.

Related thread I found (also complaining about a Samsung device, but from 2013...): https://exiftool.org/forum/index.php?topic=5103.0

I experimented to see what exiftool does now when the APP1 segment gets too large, and it looks like they just add a second APP1 segment and call it 'multi-segment EXIF` (I have no idea how well supported this is):

$ exiftool -UserComment="abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" b-263747161_original.jpg
Warning: [minor] File contains multi-segment EXIF - b-263747161_original.jpg
    1 image files updated

$ exiftool -v3 b-263747161_original.jpg
  ExifToolVersion = 12.52
  FileName = b-263747161_original.jpg
  Directory = .
  FileSize = 434075
  FileModifyDate = 1678121141
  FileAccessDate = 1678121141
  FileInodeChangeDate = 1678121141
  FilePermissions = 33184
  FileType = JPEG
  FileTypeExtension = JPG
  MIMEType = image/jpeg
JPEG APP1 (65533 bytes):
    0006: 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 0d 00 [Exif..II*.......]
    0016: 00 01 04 00 01 00 00 00 a0 05 00 00 01 01 04 00 [................]
    0026: 01 00 00 00 38 04 00 00 0e 01 02 00 01 00 00 00 [....8...........]
    0036: 00 00 00 00 0f 01 02 00 08 00 00 00 aa 00 00 00 [................]
    0046: 10 01 02 00 09 00 00 00 b2 00 00 00 12 01 03 00 [................]
    0056: 01 00 00 00 06 00 00 00 1a 01 05 00 01 00 00 00 [................]
    0066: bc 00 00 00 1b 01 05 00 01 00 00 00 c4 00 00 00 [................]
    [snip 65421 bytes]
  Warning = [minor] File contains multi-segment EXIF
JPEG APP1 (71 bytes):
   10007: 45 78 69 66 00 00 00 00 00 00 00 00 00 00 00 00 [Exif............]
   10017: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10027: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10037: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10047: 00 00 00 00 00 00 00                            [.......]
  ExifByteOrder = II

Obviously the current ExifInterface behaviour is very problematic (corrupting the image completely), but I'm not actually sure the best way to improve it. Some options I came up with:

1. If the size of the APP1 segment is larger than 2^16 then just write the first 2^16 bytes and hope.
2. Implement the same 'split segment' support that exiftool has.
3. Add logic to ExifInterface to resize a thumbnail to free up space in the APP1 segment if it runs out (this seems too magical and could be very confusing for users).
4. Refuse to save a file in ExifInterface.saveAttributes if it results in APP1 being larger than 2^16, either by silently not writing out (confusing) or throwing an exception (disruptive).
5. Add prioritisation of Exif tags, so when we run out of space we drop tags lowest-priority-first (very unlikely we can predict the 'correct' prioritisation such that users aren't annoyed/confused by the tags we decide to drop).

Hi Ian,

Thanks for looking into the issue and provide the detailed analysis result.

About the question: Charcoal: Do you know if CameraX is deciding how large to make the thumbnail in this case, or is this happening lower down in the device? Taking up 64,000 bytes doesn't leave much space for the rest of the Exif data.

CameraX doesn't specify any thumbnail related capture request settings (CaptureRequest#JPEG_THUMBNAIL_SIZE, CaptureRequest#JPEG_THUMBNAIL_QUALITY) when capturing the image. It depends on OEM's implementation to decide what the default thumbnail size and quality should be.

I'm curious about why this issue only happens when setting a FUSED location data but does not happen when setting a GPS location data? Does the FUSED location data in Exif actually occupy a little bit more size than GPS location data? So it causes the different result?

I'm curious about why this issue only happens when setting a FUSED location data but does not happen when setting a GPS location data? Does the FUSED location data in Exif actually occupy a little bit more size than GPS location data? So it causes the different result?

Good question - I actually only got as far as playing with the image provided inside MyApplication-ExifLocationIssue.zip, I didn't look at CameraXBasic-WriteFusedLocation.zip, and as you noted in comment #1 both location providers cause a problem in the non-CameraX example app. My guess would be as you say, the Exif data ends up a tiny bit larger and causes the problem. If I have time I can dig in and show that more conclusively.

I've decided to go with option 4 from comment #7 and throw an exception from saveAttributes in order to avoid creating a corrupted image. I've filed a new issue to track the possibility of adding multi-segment support in the future: https://issuetracker.google.com/271999370

Are you sure it's an issue with the APP1 segment being too large with the FUSED location? I was thinking perhaps there's some issue with the length calculation that's happening as we were able to fix these images by just detecting the start of the jpeg image data and re-writing the length field based on that detection.

Are you sure it's an issue with the APP1 segment being too large with the FUSED location? I was thinking perhaps there's some issue with the length calculation that's happening as we were able to fix these images by just detecting the start of the jpeg image data and re-writing the length field based on that detection.

This fix is consistent with the current failure mode of ExifInterface when the APP1 segment gets 'too large' (before my change linked above in comment #11). The image ends up 'corrupt' because we have 0x10030 bytes to write to the APP1 segment, and ExifInterface does two things:

• When writing the length of the APP1 segment it truncates this to 0x0030
• It writes all those 0x10030 bytes out, and then it writes the rest of the image.

A JPEG parser (I assume) comes along and reads the length of the APP1 segment (0x30) and skips that many bytes, then expects to find JPEG data - but it's actually in the middle of the Exif and so it fails.

If you manually find the start of the JPEG data then you obviate both of the problems - and the image is 'fixed'.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.exifinterface:exifinterface:1.3.7

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.exifinterface:exifinterface:1.4.0-alpha01

Re #41 - as soon as the blocked by bug is solved and the blocked work still needed for this bug is complete.

See comment#42

All the work has completed with this effective complete rewrite of the internals of FragmentManager and how it handles animations and transitions. The new state manager is enabled by default for the Fragment 1.3.0-alpha08 release.

You can verify this by following the snapshot instructions with build id 6732061 and switching your fragment dependency to 1.3.0-SNAPSHOT.

We've filed b/162776418 to track removing the FragmentManager.enableNewStateManager() experimental API. Please file any regressions found with the new system as soon as possible.

This seems to work (the returnTransition) with the new state manager https://issuetracker.google.com/139536619#comment50 Guess it was an issue with Fragments and not with Transition