Needs work
Project:
Diff
Version:
8.x-1.x-dev
Component:
Diff builder plugins
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
8 Nov 2016 at 14:54 UTC
Updated:
20 May 2024 at 00:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
miro_dietikerComment #3
miro_dietikerComment #4
miro_dietikerImportant note, for media_entity_image, there is an API to extract exif. We should also integrate with that - could be a separate issue.
We should also check what wrapper it uses and not use a different one to keep common dependencies low.
Comment #5
johnchqueFirst try, trying to get as much info as we can. :)

Comment #7
johnchqueIMHO is better to add a text like (No title available) or something similar when wasn't set. So the diff can keep the same data in both sides. Just an idea. :) Fixing tests.
Comment #8
miro_dietiker"extra image data" => "image metadata"
See
https://en.wikipedia.org/wiki/Metadata#Photographs
Then this would apply to both title and alt.
You now explicitly pick the trivial metadata dimensions defined by the fileManager.
The File size should use the converter for human readability, see format_size().
This would be an intermediate state acceptable to commit and then continue in a follow-up with more detail, see below...
The link above contains a reference to exiftool on JPG.
Medias shows that instead, in PHP this would mean exif_read_data() like \Drupal\media_entity_image\Plugin\MediaEntity\Type\Image::getExifField implements.
It seems exif_read_data() is always present, while for Image type we should use the getExifField api (separate specific plugin).
Here two examples what this additionally contains, a png screenshot:
And a real JPG example from a cheap panasonic cam:
More modern cams would also add things like GPS coordinates.
But this leads to a huge amount of data. There's also overlap between exif and filemanager.
When a new image is added, all these lines would show up as +.
To avoid overload, i would ask, if we can put that extended information into a collapsible extended fieldset while keeping the field data itself minimalistic. This problem could apply to any embedded entity such as through entity reference:
On top level the entity label (added, changed, removed) might be fine.
On click, the user might want to see the target fields and its deltas resolved.
That could be already output and hidden in a fieldset (recursion?), or only resolved on button click via AJAX.
Comment #9
johnchqueChanges made based on comment above, will open a followup for implementing exif output.
Comment #11
johnchqueSorry, small leftover.
Comment #12
miro_dietikerShouldn't we use keys for the concepts such as size, type, width, height instead of simply []?
No tests yet? :-)
Comment #13
johnchqueChanges made, some tests added.
Comment #14
silvi.addweb commentedre-roll patch #13 without test file changes.
Comment #15
acbramley commentedPlease update to use an MR