Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Use Markdown for this comment
Set severity, which reflects how much the issue affects the use of the product
Assign issue to yourself
Pending code changes (auto-populated)
[ID: 84651]
Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Each team will estimate work on a slightly different scale, which means the values in this field are likely only meaningful to the team that owns the Buganizer component in which the issue resides.
See Atlassian's Agile Coach for more information on how to use story points for estimation: https://www.atlassian.com/agile/project-management/estimation [ID: 746686]
Set the version(s) of the product affected by this issue (comma-separated list)
Set the version(s) of the product in which the issue should be fixed (comma-separated list)
Set the version(s) of the product in which the issue fix was verified (comma-separated list)
Set if this issue occurs in production
[ID: 85206]
Set Reporter
Set Type
Set priority, which reflects how soon the issue should be fixed
Set Status
Set Assignee
Set Verifier
Remove item
View or edit staffing
View issue level access limits(Press Alt + Right arrow for more information)
Description
Exif data is stored in a JPEG
APP1segment which has max size of2^16 = 65536 bytes.Some devices (e.g. Samsung A32) create images with quite large embedded thumbnails that take up nearly all these bytes [1]. When we then try and save additional exif data we currently
saveAttributesinstead.When experimenting with
exiftoolto recreate the same problem, itAPP1segmentExifInterface. Before we do this we need to understand how well supported this file structure is across the ecosystem. It would also require significant rearchitecting ofExifInterfacebecause the logic it uses to lay out the structure of the theAPP1segment is quite complicated, and not 'aware' of splitting into multiple segments.[1] The Samsung A32 in particular seems to always create a 64,000 byte thumbnail, no matter what the content of the image is, whereas all other devices I tested (several other Samsungs & Pixel 5) produce different size thumbnails for different images (which makes sense, since jpeg compression is heavily content-dependent).