We are using Omeka version 2.0.4. Before uploading a jpeg item to Omeka, our unique photo identifier is embedded in the file info using photoshop. We want to ensure that if a user “saves image as” that our identifier stays embedded with the file for tracking purposes. If the image is saved from the full jpeg view (once the image has been clicked and opens as the only thing on the page) the embedded information is saved with it. However, if the image is saved from the item page the embedded information is not saved along with the file. I’m not sure if anyone else embeds information into their jpeg files but, I’m wondering if there is a way to ensure that all thumbnails generated from the file we upload can maintain the embedded metadata?
Thank you,
Colleen
I'm pretty sure that stuff gets stripped out by ImageMagick when we have it generate the thumbnails.
Changing our call from -thumbnail to -resize might keep this embedded data intact, but that's not something you can easily change without diving into the code.
Thanks for the reply John. I thought that was the case, but figured it was worth inquiring about in case there was a fix that was on the easier side.
Colleen
Another solution would be to recreate the derivative images yourself in photoshop.
First you'll want to copy the folder that imagemagick created that stores the original version of the photos. In my installation that's archive/files folder. That way you'll have all the files with their correct Omeka File Names like 46fd15358bf4df11b3a08cab33acfaaf.jpg and also your embedded file information.
Then in photoshop run the File>Scripts>ImageProcessor to re-size these images to the size you are displaying on your item show pages.
After resizing the embedded file data should now be associated with smaller versions of the images, with the correct Omeka names.
Now all you should have to do is replace the archive/fullsize images(or whatever you are showing on the item show pages) with these images you created.
A couple of notes:
You should copy the Omeka fullsize folder to your computer, just so you have a backup in case anything goes wrong.
When I replace images in these folders I have to delete the old images first before copying the new images into place. It won't just let me to copy these new files over the old ones even though they have the same names.
Thanks Andy. I'm not sure that we will start doing this at the moment, but it is good to have it as an option.
Colleen
And older thread - but I just noticed this as well. I think it would be ideal if-resize is being used for fullsize and original, and thumbnail for square_thumbnails and thumbnails.
By taking a quick looks at it, all that would need to be done is passing $storageType to _getResizeCmdArgs() in Image/Creator.php and do some additional testing there.
Was there a particular reason you are using -thumnbnail only, apart from speed?
The basic idea is that "fullsize," despite the name, is just a somewhat-larger thumbnail, so having original metadata about physical size and capturing equipment or similar embedded data from the original doesn't any more belong there than on the "thumbnails."
A note: apart from the filename, which we do change, "original" really is original. We don't filter or process the originals at all, with -resize, -thumbnail, or otherwise.
Now, with Omeka 2.2 or later, it is somewhat more approachable to change how Omeka creates the derivative images, since you can now just write a "strategy" in a plugin and select it in config.ini instead of hacking the core as was previously required.
Thanks for explaining the understanding how Omeka uses fullsize.
For me, the reason to keep the metadata included is because we regularly write basic metadata into the file itself, and should somebody download an image, the metadata, unless they choose to strip it, stays with the image.
I will look into utilizing a plugin to change the derivative creation.