[Hyrax v5] missing file details data

[briesenberg07]

Descriptive summary

less/missing metadata in works and files > file details -- compare:

• TIF files
  • fx719s951_content.tif(f*) -- ingested to v5 staging - VS - in OD prod
  • fx719s53h_content.tif(f*) -- in v5 staging - VS - in OD prod
  • fx719r696_content.tif(f*) -- in v5 staging - VS - in OD prod
• JPG files
  • file details for JPGs ingested in v5 staging
    • 20040620_pagoda.JPG
    • PXL_20260415_dancing_bears.jpg
    • PXL_20260418_forest_bridge.jpg
  • - VS - file details for JPGs in OD prod
    • df70tw112_content.jpeg
    • df67sb53z_content.jpeg
    • df67s0609_content.jpeg

*No chance difference in file-format extension could make a difference? Prod TIF files have .tiff, v5 uploads have .tif.

Expected behavior

desired file details are generated and/or read from embedded file data as expected

Related work

Reading embedded file data relates to #3637 and #3636

Accessibility Concerns

Exploring reading embedded file data to record alt text field value for file set in #3637 and #3636

[briesenberg07]

QA test 1

downloaded assets from production and ingested to v5 staging 6/10
comments below comparing FILE DETAILS > "Characterization" value (the 'blob')

file details in prod	in v5 staging	comments
fx719s951_content.tiff	fx719s951_content.tiff	staging has different order of information in Characterization blob; different values for Format Label, Date Created (formatting of value); missing Valid, Byte Order, Compression, Color Space, Orientation, Scanning Software; has Filename where prod does not
fx719s53h_content.tiff	fx719s53h_content.tiff	staging has different order of information in Characterization blob; different values for Format Label, Date Created (formatting of value); missing Compression, Color Space, Profile Name, Profile Version, Orientation, Scanning Software; has Well Formed where prod does not
df70tw112_content.jpeg	df70tw112_content.jpeg	staging has File Format where prod has Format Label, has Filename where prod does not; missing Valid, Exif Version, Byte Order, Compression, Color Space, Orientation, Capture Device, Scanning Software; different values for Date Created (formatting of value); different order of information in Characterization blob
df67sb53z_content.jpeg	df67sb53z_content.jpeg	staging has different order of information in Characterization blob; staging has File Format where prod has Format Label; staging missing Valid, Byte Order, Compression, Color Space
Ax234_b002_f015_099_100.pdf	Ax234_b002_f015_099_100.pdf	staging has different order of information in Characterization blob; missing Valid, Graphics Count; staging has File Format where prod does not
Coll263_b313_f001_060.pdf	Coll263_b313_f001_060.pdf	staging has different order of information in Characterization blob; staging has File Format where prod does not; different value for Date Created (formatting of value); missing Valid, Graphics Count

[CGillen]

If I could summarize your findings:

1. Characterization data in a new order
2. Some characterization data in a new format (particularly timestamps)
3. Additional (sometimes poorly formatted) characterization data

• New fields
• Extra data in existing fields

1. Removed characterization data fields

If I missed something let me know

Some of these seem like enhancements or "sum-zero" changes to me, but I want to know which you'd like fixed.
I planned to bring back any "removed" (it's still there, just not displayed thankfully) fields and values
I figured:

1. I'm not sure the order has/had significance. I don't think there's a ticket on the order
2. I'd be interested to see the data format on (regular) staging as a fresh ingest to see what format the data comes in. We may be extracting/presenting the data the "new" way now already. This may be a bigger issue, it may be a boon with more precise data, it could be nothing at all. That's in the eye of the Metadeity
3. More data == good? Not sure if the formatting or new info is good/bad
4. Definitely restoring lost display fields

[briesenberg07]

Hi @CGillen -- thanks for this ^^^

I have asked @KevinJonesMeta that this be added to an upcoming metadeities agenda for discussion...

...so this is not an answer (!), but rather, an educated guess about what might be important to the metadata team: I am guessing that the missing values are the main (only?) thing it'll be really important to fix.

As you say, I don't see large significance in order. The changed formatting of Date Created values looked (at a very casual glance) like it aligned with some date/time formatting rules; as long as we can confirm that this value formatting aligns with a reasonable syntax encoding scheme (what's the one that uses "Z" again?), that seems OK... More to come, thank you for following up, and for wading through my not-very-well-organized QA notes above!

CTD... oh, timestamps are probably in whatever format the software creating the image file puts them in, and OD just reads what's there...?

[CGillen]

That's a fantastic question and I bet it also depends on the software reading the metadata too (exiftool, imagemagick, ffmpeg, etc).

If I remember correctly, Z is used to specify it's off UTC time, ie. [Z]ero time offset

...A little curiosity digging later, it's the ISO 8601 standard for combined date/time stamps!
https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
probably the second most familiar computer-to-computer timestamp representation, behind the unix timestamp.

Fun: You can replace the Z with a +/-HH:MM offset to represent the timezone. It's interesting because some timezones can be offset by 15min intervals or "time locked" inside another timezone, so it gets confusing REALLY fast making time one of the oddly hard problems to solve

[CGillen]

That's a fantastic question and I bet it also depends on the software reading the metadata too (exiftool, imagemagick, ffmpeg, etc).

Which is actually making me think this could be related to just that. Somewhere along the line I got exiftool and mediainfo working again for hopefully even better characterization, and OD might be deciding to use one of their knew found fields. Maybe because it's more precise data?