Open DiegoPino opened 3 years ago
@DiegoPino I agree with your thinking that cleaner, better, simpler, smaller would work best for vast majority of uses cases. Knowing the EXIF is present, stored, and able to be reviewed in the object’s JSON should cover the needs for most users, projects.
Thanks @alliomeria, That makes it 2 votes in favor of less/smarter code. Also how many actual users in the world / know/care expect to see EXIF? I guess not many. There are for sure, but not that many!
Hi @DiegoPino and @alliomeria,
I wanted to mention that we (at California Revealed) use EXIF data to check-in and validate file deliverables from our vendors for audiovisual, text and image materials. This is done outside our current ISLD 7 instance, but being able to do this in Archipelago would be ideal for us. For reference the below are the Exif commands we currently use to do this work.
AV exif commands used:
exiftool -csv -r -comment -source -copyright -title -year -g4 [directoryOnHDD] >[csvName].csv
Text/Image commands used:
#exiftool -csv -r -FileType -Compression -PhotometricInterpretation -ColorSpaceData -XResolution -YResolution -BitsPerSample -Date -Description-en -Source -Title-en -Rights-en -G4 -csv -r -FileType -Compression -PhotometricInterpretation -ColorSpaceData -XResolution -YResolution -BitsPerSample -Date -Description-en -Source -Title-en -Rights-en -G4 [directoryOnHDD] >[csvName].csv
@mlohnash thanks for sharing your file EXIF processing! We plan on keeping the Display during upload option, as it is right now, but allowing this to be disabled more easily because it can add a bit of too much burden for end users. This is all just visual because once upload happens and final persistence happens we do another pass (on the stored file) with all the EXIF and that is standard. Your input is very helpful because I see we can allow some stripping to happen since we extract everything (which can be a lot really specially when dealing with Adobe added XMP and specific processing workflow data) but we should also plan on differentiated extraction depending on the file type (or even at a Pronom ID level?)
Will ask you for more info as i add those features. Thanks again!!!
Hi Diego,
Here is the information requested.
This is the exif tool formula run on incoming tif, jpg, and pdf files from our vendors: exiftool -csv -r -FileType -Compression -PhotometricInterpretation -ColorSpaceData -XResolution -YResolution -BitsPerSample -Date -Description-en -Source -Title-en -Rights-en -G4 [drive/folder]>[desination .csv file]
I have attached an example of how we use this information to verify files received ( winter18_HDD-164_techout.xlsx ) conform to our statement of work ( CA-R_SOW2020_PT(3).pdf - our requirements are laid out on page 3).
@mlohnash thanks (again). I will copy this last to strawberryfield (since the settings will go there) and mention you so can follow the issue. Thanks!
Hi, its me with another "bothering" feeling.
Right now we allow Images to be previewed and exif extracted and display after upload via a webform (attaching screenshot with an example where realtime loading can not happen)
There are toooo many cases where that makes no sense
Basically its almost an exception. So question. Should we just recode https://github.com/esmero/webform_strawberryfield/blob/1.0.0-RC1/webform_strawberryfield.module#L308 and make it simpler and less code-extensive?
The code actually acts on the theming layer and to do so needs a lot of 'non' OOP (Object Oriented programing) to do so. This was a request from the ESIE project and has never come up again by anyone else. Of course it can be disabled right now by changing the Preview option in the image element, but i feel it can be cleaner, better, simpler, smaller and with a LOT of limits
@giancarlobi @alliomeria what do you think???