When you upload an image to WordPress it stores your original image and also generates three smaller copies of the image, largely for internal use. What your theme does with these images is another matter. Some themes make use of WordPress’s cropped images, some ask you to go into the Media settings and reset some of the crop sizes to dimensions that suit the theme’s layout, and some just ignore them altogether and create their own set of sizes in addition to WordPress’s defaults.
If your theme is responsive then it will include CSS media queries that detect various screen sizes and resolutions and deliver up resized images to match, or will utilise the nearest larger resized image stored in WordPress that the browser will then resize down.
If your theme is retina ready then you may well be uploading images that are four times the size (twice the size in each direction) that the theme will deliver up to high PPI devices, again utilising CSS media queries.
What this all amounts to is that for every image you upload to WordPress, several more images will be generated, which will be delivered up to visitors to your site in different contexts. The only time you can be sure that a site visitor will see the image you originally uploaded will be if that image is delivered to them with the HTML height and width set to exactly match the dimensions of the image.
WordPress does all this resizing for you and to do this it utilises a PHP graphics library called GD. In a normal setup when GD resizes an image it strips out any metadata present in the image.
If you don’t believe this then download one of your resized images from your WordPress site and open it in your image editing software. On viewing the information about the image you will find there is no EXIF, IPTC or ICC profile data present.
The logic behind this, if indeed it is intentional behaviour, is presumably to reduce file sizes. Storing all this metadata in an image uses up a little space and given the amount of space/bandwidth images use anyway many WordPress site developers are happy to lose this information.
As photographers we almost certainly are not. We go to varying lengths to make sure that we include IPTC metadata about our shots. As a photographer you will no doubt know that once we move beyond boilerplate stuff then adding information specific to each image is onerous.
Whilst it is irritating enough to find this painstakingly added information missing, the far more serious issue is that the boilerplate entries are gone too. Your images are out there in the wild missing your assertion of copyright, licensing information and contact details.
Whilst the loss of this metadata will do little to facilitate those who are determined to make illegal use of your images (because they can easily just remove this information if present anyway), it can obviously result in lost sales leads with potential legitimate clients who come across a copy of your image in the wild and may wish to license your image.
Another consequence that, I will concede, will be largely the concern of photographers and other image professionals only is that the ICC profile is stripped too. Whilst the ordinary user is unlikely to be aware of this, those of us with wide gamut displays notice the difference. Indeed it was just this that alerted me to the problem that all the metadata had been stripped in the first place. On one of my sites that is retina ready my full size images go up at 2280px wide and then get displayed at 1140px on my desktop monitor. I noticed after uploading a sunset image the tell tale signs of super saturated reds on my wide gamut monitor, but not on my laptop screen.
The question is, then, how big a problem is all this? In my opinion it is always a problem if your copyright is being stripped from your images but since the arrival of retina displays the problem has grown enormously. If we, as photographers, are trying to showcase our wares in the best possible way then we are moving to delivering images with massive resolutions to cater for retina displays. This has moved images into the realm of printable sizes, rather than images just suitable for web use. The plethora of screen sizes and devices available now means that very large resized images are being delivered up without any metadata attached.
Is there a solution? Fortunately, yes, even if it is suboptimal. GD is not the only open source graphics library, there is an alternative, which is ImageMagick. ImageMagick does not by default strip metadata from images when it resizes them. This can be implemented in WordPress using ImageMagick Engine. This plugin fulfils its function on my current installation (3.8.1) but it hasn’t been updated for over a year and a half, appears unsupported now, and its admin interface is flakey (bits of the screen turn blank after performing actions but can be restored on refresh). It does the job, metadata is preserved, copyright information is intact and images display normally on my wide gamut monitor. Once enabled it will process new images that are uploaded and has the option to reprocess all existing images too. As an incidental benefit the image resizing algorithm delivers better quality results than GD.
This is a fairly parlous state of affairs however and it is something that I firmly believe should be in the WordPress core.
It is probably too late now to simply remove GD and replace it with ImageMagick so my request would be that it should be present as an alternative. I have mooted this idea in WordPress forums but have been told that offering WordPress’s non technical user base such an alternative, however it is presented in the admin interface, would be to add an undesirable level of complexity.
Maybe so, but perhaps this issue has not been revisited for some time by WordPress’s core developers and I would argue that in the light of the appearance of retina displays, and consequently far larger image sizes, that it now deserves serious consideration.