Make WordPress Core

Opened 15 years ago

Last modified 5 years ago

#11877 reopened enhancement

Resized Images lose their EXIF data

Reported by: thee17's profile thee17 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Media Keywords: needs-patch
Focuses: Cc:


The thumbnail, and medium re-sized images do not keep EXIF data of the original image.

Change History (18)

#1 @scribu
15 years ago

  • Milestone Unassigned deleted
  • Resolution set to worksforme
  • Status changed from new to closed

The EXIF data is stored in the database, so you don't need to keep it in each image size.

See wp_get_attachment_metadata().

#2 @miqrogroove
15 years ago

I don't agree with scribu on this one, but since the PHP Exif library is read-only, there's really nothing that can be done reasonably to fix that bug.

#3 @markhowellsmead
10 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to feature request

That does, however, mean that when photographers protect their uploaded images by placing copyright information and flags in the EXIF/IPTC of the files, this information is lost when the images are resized. Is it not possible to copy the EXIF and IPTC data to the generated files when resizing?

#5 @ocean90
10 years ago

  • Milestone set to Awaiting Review
  • Type changed from feature request to enhancement

#6 @markoheijnen
10 years ago

What about a solution I created here: Which stores both data as IPTC. Till now I didn't found something that could do the same for EXIF.

If the target for this is photographers then I rather keep it closed as worksforme due the fact that we do now have Imagick support and that is exactly what they want: Better images with all the information still there. The only thing there is you need to check if your host does support it.

#7 @markhowellsmead
10 years ago

It's not just for photographers, but for anyone who works with images containing embedded data. It's good to see a workaround solution, but it's both a logical and performance issue if two separate handling processes need to be executed and maintained. It's hardly a custom, rare requirement that this information be retained, which is why I feel that it needs to be added to core.

#8 @markoheijnen
10 years ago

For WordPress and any PHP project it's a rare requirement that the information needs to be retained. In a way GD would have done a better job then and as far as I know there is no way in PHP itself to preserve EXIF data correctly.

If you look at the libraries in the link markjaquith provided then you do see that libraries aren't that small to do this. Because of that I don't see the benefit to include them by default. If you know a different way of doing this then please tell.

#9 @markhowellsmead
10 years ago

“For WordPress and any PHP project it's a rare requirement that the information needs to be retained”

Perhaps that's historically been the case, because few people using WordPress have both the technical know-how and the usage incentive to recognize the benefit of what I'll admit is an advanced feature. It's a detail which is overlooked by (or unimportant for) many, if not most, content creators.

However, (one of the more technically modern online image handlers) retain EXIF and IPTC, and I'll wager that Getty does too. These are both photographer environments, obviously. Online file protection is a global issue and it would be good if WordPress could step up to the mark on this and show that it supports (amongst other things) better copyright support.

Anyway: I've been using WordPress since its inception, so I guess it's time I stopped waffling and rolled up my sleeves to provide some submittable code. :) improved-gd-editor Is a step in the right direction, but I need to examine (non-WordPress) code I already have to see whether all of the requisite data is covered.

Last edited 10 years ago by markhowellsmead (previous) (diff)

#10 @markoheijnen
10 years ago

Don't get me wrong, I really would love to get this in. The problem is that the examples you are given control their environment and I'm sure they don't use GD. Also to me WordPress did step up by having Imagick support.

But yes, please let me know if my plugin can be improved and then we will see if we can include it in core :).

#11 @chriscct7
9 years ago

@dhshredder is looking into this

#12 @kirasong
9 years ago

We handle this properly with Imagick.
I'm still of the opinion that this is primarily a GD thing, but would be happy to consider a patch/fix.

#13 @markhowellsmead
8 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

A long time down the road! But: testing with 4.4 and 4.5.b1, the solution at - to force ImageMagick - seems to ensure that the EXIF data discussed here is retained. As mentioned in various places online, GD doesn't support EXIF retention when resizing images.

#14 @markoheijnen
8 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

As mentioned before, it can be done by storing the EXIF data as IPTC. So before closing this, I first would like to know if something like has a change to get into core. I think it's worth a shot since by default we do remove the meta data now anyway.

#15 @markhowellsmead
8 years ago

by default we do remove the meta data now anyway

Explicitly in WordPress? Or just because GDlib can't retain existing EXIF and IPTC?

Also, from the plugin description:

you will retain some of the data by storing it as IPTC data

Retaining “some” data isn't a complete solution, is this the case for a specific reason?

Moving “some” EXIF (or IPTC) data into a different data structure within the generated e file isn't a great idea. If the EXIF and IPTC data can't be maintained as-is when creating copies of the original image, the standardized data structure of the original file should be maintained when copying the data over manually.

Last edited 8 years ago by markhowellsmead (previous) (diff)

#16 @markoheijnen
8 years ago

Even in Imagick the decision is made to delete all the EXIF data by default and you can use a filter to enable it (see #28634).

It can retain all the information I believe. I just use those words so it can't be used against me. In this case it's moving EXIF data to IPTC which isn't perse a bad thing. Your expectations to have it the same as the original is just unrealistic for GD.

#17 @markhowellsmead
8 years ago

The plugin does good work. However, tests indicate that simply switching to ImageMagick (using default settings) means that the generated images contain all of the IPTC and EXIF of the original. The copyright issues and benefits of retaining embedded metadata outweigh the benefits of a slightly smaller file size.

#18 @aoxoacreative
8 years ago

Some shared hosting servers don't have imageMagick as an option. Retaining metadata and the color profile is important. Since GD doesn't support EXIF retention when resizing images, could we---at the least---assign a color profile to GD images after the resizing? A default of sRGB IEC61966-2.1 would be good.

Note: See TracTickets for help on using tickets.